Mariusz Wawrzyniak | 4 Nov 19:56 2014
Picon

Radeon 6450 + Mesa 9.2.5 + compiz

Hi,

it's just "me too" post, (after Matthew Green's post from 17 Sep), 
but with different graphic card and maybe some differences 
in error output.I built fresh kernel (today's with radeondrmkms 
in GENERIC), made the same trick as Matthew with r600_dri.so in 
/usr/X11R7/lib/modules/dri/ and launched X's with compiz from pkgsrc.
 Everything runs almost fine (except some artifacts, color inverted small 
 areas on gtk apps, etc.) until I run more tabs in firefox.  
Computer reboots, dumps the core and later /var/log/messages look 
like this:

...

Nov  4 16:41:23 netbsd /netbsd: root file system type: ffs
Nov  4 16:41:23 netbsd /netbsd: drm: initializing kernel modesetting (CAICOS
0x1002:0x6779 0x1043:0x047B).
Nov  4 16:41:23 netbsd /netbsd: drm: register mmio base: 0xf5000000
Nov  4 16:41:23 netbsd /netbsd: drm: register mmio size: 131072
Nov  4 16:41:23 netbsd /netbsd: drm kern info: ATOM BIOS: 6779.13.12.0.41.AS09
Nov  4 16:41:23 netbsd /netbsd: radeon0: info: VRAM: 1024M
0x0000000000000000 - 0x000000003FFFFFFF (1024M used)
Nov  4 16:41:23 netbsd /netbsd: radeon0: info: GTT: 1024M 0x0000000040000000
- 0x000000007FFFFFFF
Nov  4 16:41:23 netbsd /netbsd: drm: Detected VRAM RAM=400M, BAR=256M
Nov  4 16:41:23 netbsd /netbsd: drm: RAM width 64bits DDR
Nov  4 16:41:23 netbsd /netbsd: Zone  kernel: Available graphics memory:
1427390 kiB
Nov  4 16:41:23 netbsd /netbsd: drm: radeon: 1024M of VRAM memory ready
Nov  4 16:41:23 netbsd /netbsd: drm: radeon: 1024M of GTT memory ready.
(Continue reading)

Mariusz Wawrzyniak | 4 Nov 18:34 2014
Picon

Radeon 6450 + Mesa 9.2.5 + compiz

Hi,

it's just "me too" post, (after Matthew Green's post from 17 Sep), 
but with different graphic card and maybe some differences 
in error output.I built fresh kernel (today's with radeondrmkms 
in GENERIC), made the same trick as Matthew with r600_dri.so in 
/usr/X11R7/lib/modules/dri/ and launched X's with compiz from pkgsrc.
 Everything runs almost fine (except some artifacts, color inverted small
areas on gtk apps, etc.) until I run more tabs in firefox.  
Computer reboots, dumps the core and later /var/log/messages look 
like this:

...

Nov  4 16:41:23 netbsd /netbsd: root file system type: ffs
Nov  4 16:41:23 netbsd /netbsd: drm: initializing kernel modesetting (CAICOS
0x1002:0x6779 0x1043:0x047B).
Nov  4 16:41:23 netbsd /netbsd: drm: register mmio base: 0xf5000000
Nov  4 16:41:23 netbsd /netbsd: drm: register mmio size: 131072
Nov  4 16:41:23 netbsd /netbsd: drm kern info: ATOM BIOS: 6779.13.12.0.41.AS09
Nov  4 16:41:23 netbsd /netbsd: radeon0: info: VRAM: 1024M
0x0000000000000000 - 0x000000003FFFFFFF (1024M used)
Nov  4 16:41:23 netbsd /netbsd: radeon0: info: GTT: 1024M 0x0000000040000000
- 0x000000007FFFFFFF
Nov  4 16:41:23 netbsd /netbsd: drm: Detected VRAM RAM=400M, BAR=256M
Nov  4 16:41:23 netbsd /netbsd: drm: RAM width 64bits DDR
Nov  4 16:41:23 netbsd /netbsd: Zone  kernel: Available graphics memory:
1427390 kiB
Nov  4 16:41:23 netbsd /netbsd: drm: radeon: 1024M of VRAM memory ready
Nov  4 16:41:23 netbsd /netbsd: drm: radeon: 1024M of GTT memory ready.
(Continue reading)

Havard Eidnes | 9 Oct 20:21 2014
Picon

Re: Radeondrm w/RV370 / X300 SE on 7.0_BETA -- working?

>>>> It's possible I'll also re-install the system using netbsd-6
>>>> code, to see if twa(4) has any better chance of working on that
>>>> version.
>>>
>>> I think there were some locking changes made by riastradh <at>  to the new
>>> radeon drm driver after Sep 17, is there a newer kernel you can try?
>>
>>I can always make one.  Which branch should I try?  -current or -7?
>
> The locking changes are only for a DRMKMS kernel, maybe look at whatever
> is wrong with twa(4) first.

Well, I decided to do things in a slightly different order...
I first took out the twa card, and tried the DRMKMS kernel with
the Intel 965G graphics.  That worked about as well as before,
i.e. not at all -- I hit a kernel trap, and trying to access the
location %rip pointed to from DDB also caused a trap.

I then tried to change some of the BIOS settings related to the
graphics, but didn't find anything which enabled shared graphics
memory.

What I did notice, though, is that I also got spontaneous reboots
when trying to reboot with the GENERIC kernel.  I went back to
BIOS and loaded default settings, and made the changes I usually
do on this board (memory remapping on, boot device order etc.),
and at least it's up and running now again.

What I did notice was that the spontaneous reboots mostly come
during this phase of autoconf:
(Continue reading)

Havard Eidnes | 21 Sep 15:10 2014
Picon

Radeondrm w/RV370 / X300 SE on 7.0_BETA -- working?

Hi,

I've on and off tried to get a NetBSD/amd64 system running
7.0_BETA.  It is currently equipped with an old radeon graphics
card:

NetBSD 7.0_BETA (GENERIC) #1: Wed Sep 17 20:37:35 CEST 2014
        he <at> is.urc.uninett.no:/usr/obj/sys/arch/amd64/compile/GENERIC
...
vga0 at pci1 dev 0 function 0: vendor 0x1002 product 0x5b60 (rev. 0x00)
wsdisplay0 at vga0 kbdmux 1: console (80x25, vt100 emulation), using wskbd0
wsmux1: connecting to wsdisplay0
radeondrm0 at vga0: ATI Radeon RV370 X300 SE
radeondrm0: Initialized radeon 1.29.0 20080613
vendor 0x1002 product 0x5b70 (miscellaneous display) at pci1 dev 0 function 1 not configured
...

However, any attempts at starting the in-tree X server is met
with a kernel core dump, apparently after a kernel trap.

Unfortunately, I don't have a serial console on this host yet,
and it looks like inspection of the saved core dump via "crash"
isn't giving particularly beleivable results:

is# crash -M netbsd.2.core -N netbsd.2
Crash version 7.0_BETA, image version 7.0_BETA.
System panicked: trap
Backtrace from time of crash is available.
crash> tra
_KERNEL_OPT_NARCNET() at 0
(Continue reading)

matthew green | 17 Sep 09:21 2014
Picon

success with radeondrmkms + radeon hd 5450 + Mesa 9.2.5


hi folks.

i've been trying to get GL apps working with the hd 5450.  Taylor
has fixed a bunch of problems for me, and now (with the in-tree
Mesa), i have applications that crash or don't work instead of
kernel crashes.  after not getting much clue what was up, i followed
Piotr Meyer's idea (and instructions on how he built it) and tried a
newer Mesa.

i got Mesa 10.2.6 to build and run good enough for normal X11 and
Xvideo, and simple GL apps (eg, glxgears), though bzflag was still
crashing, with some very strange fault in memcpy() that didn't make
much sense to me.

i tried Mesa 9.2.5 instead.  this seems to work a lot better for
me.  bzflag runs fine, and i can run a couple of concurrent glxgears
and they work fine.

for both Mesa 9 and 10, i had to make two weird changes while building
the tree, besides random dependancies:

	- i had to patch the generated libtool to make it stop not
	  creating .so files instead of just libtool archives (.la+.a),
	  which was kinda annoying as it needs to happen after you run
	  gmake the first time, and autoconf stuff gets regenerated.
	  my hack is to simply ignore that test for "-lgcc".

	- i had to patch src/gallium/winsys/radeon/drm/radeon_drm_bo.c
	  to use drmMap() instead of os_mmap().  i was happily
(Continue reading)

Robert Swindells | 8 Sep 13:47 2014
Picon

intel drmkms


I'm still getting a blank console display at boot with i386 on a 915GM,
sources from today.

Part of the dmesg for it is:

agp0 at pchb0: i915-family chipset
agp0: detected 7932k stolen memory
agp0: aperture at 0xd0000000, size 0x10000000
i915drmkms0 at pci0 dev 2 function 0: vendor 0x8086 product 0x2592 (rev. 0x04)
drm: Memory usable by graphics device = 256M
drm: Supports vblank timestamp caching Rev 2 (21.10.2013).
drm: Driver supports precise vblank timestamp query.
drm: failed to find VBIOS tables
i915drmkms0: interrupting at ioapic0 pin 16 (i915)
drm: initialized overlay support
intelfb0 at i915drmkms0
i915drmkms0: info: registered panic notifier
i915drmkms0: unable to map VGA registers: 35
intelfb0: framebuffer at 0xda4b0000, size 640x480, depth 32, stride 2560
DRM error in intel_pipe_config_compare: mismatch in adjusted_mode.flags(DRM_MODE
_FLAG_PHSYNC) (expected 0, found 1)
warning: ../../../../external/bsd/drm2/dist/drm/i915/intel_display.c:9891: pipe
state doesn't match!

followed by:

drm: GMBUS [i915 gmbus vga] timed out, falling back to bit banging on pin 2

Robert Swindells
(Continue reading)

Robert Swindells | 18 Aug 22:30 2014
Picon

drmkms intel


As an experiment I tried removing the BUS_SPACE_MAP_PREFETCHABLE flag
from calls to bus_space_map() in the intel drmkms code.

Stuff that uses render calls still doesn't work properly but it does
look slightly better, if I do a directory listing with using a TrueType
font some characters are correct.

Maybe there is still a difference in cacheable status of pages from
what they would be under Linux.

Robert Swindells

Piotr Meyer | 14 Aug 19:09 2014
Picon

amd64 DRMKMS (ivy bridge) results, 14 Jun 2014

Ivy Bridge integrated GPU, fresh sources:

1. Now, I got valid resolution on console and in X (1280x1024). 
   Much better. ;)

2. glxgears leads to panic, after ddb.onpanic=1 I got:

drm: stuck in render ring
panic: kernel diagnostic assertion "spin_is_locked(interlock)" failed:
file "/usr/src/sys/external/bsd/drm2/include/drm/drm_wait_netbsd.h",
line 89
fatal breakpoint trap in supervisor mode
trap type 1 code 0 rip ffffffff8028bc5d cs 8 rflags 246 cr2 7f7ff7b0d020
ilevel 2 rsp fffffe80cefffd28
curlwp 0xfffffe811e143860 pid 0.5 lowest kstack 0xfffffe80ceffc2c0
Stopped in pid 0.5 (system) at netbsd:breakpoint+0x5: leave

Regards,
--

-- 
Piotr 'aniou' Meyer

Chavdar Ivanov | 8 Aug 14:53 2014
Picon

More amd64 drmkms radeon

Hi,

A few days ago one of my systems running -current (updated roughly
twice a week) refused to start Xorg with a message about a missing
global; this has been fixed since and the machine is working fine with
GENERIC and radeondrm. At that moment I decided to try DRMKMS there
and got:
---
...
drm: initializing kernel modesetting (RV350 0x1002:0x4154 0x1002:0x0002).
drm: register mmio base: 0xd0000000
drm: register mmio size: 65535
DRM error in radeon_get_bios: Unable to locate a BIOS ROM
drm: Using generic clock info
radeon0: info: GTT: 256M 0xE0000000 — 0xEFFFFFFF
drm: Generation 2 PCI interface, using max accessible memory
radeon0: info: VRAM: 128M 0x00000000D8000000 — 0x00000000DFFFFFFF (128M used)
drm: Detected VRAM RAM=80M, BAR=128M
drm: RAM width 128bits DDR
Zone kernel: Available graphics memory: 1065632 kiB
drm: radeon: 128M of VRAM memory ready
drm: radeon: 256M of GTT memory ready.
drm: radeon: 1 quad pipes, 1 Z pipes initialized.
fatal protection fault in supervisor mode
trap type 4 code 0 rip ffffffff8022eb64 cs 8 rflags 10246 cr2 0 ileuel
0 rsp fffffe8045b23a50
curlwp 0xfffffe80a83a81e0 pid 0.62 lowest kstack 0xfffffe8045b202c0
kernel: protection fault trap, code=0
Stopped in pid 8.62 (system) at netbsd:bus_dmamap_load_raw+0x34= movq
$0,40(%r14)
(Continue reading)

Dave Tyson | 5 Aug 17:43 2014
Picon

NetBSD current [AMD64] on a T400 laptop

Installed a 30th July snapshot of Current [AMD64] on a Lenovo T400. All 
went OK till I ran:

X -configure

which resulted in an immediate panic. CVSing up to todays sources and 
building/loading a new kernel gave exactly the same panic. Crash dmesg 
from 30th July version follows, the drm_addmap failure message may be 
significant. I can put the crash dump on an ftp server if requested.

t400root(t400)crash$ crash -M netbsd.0.core  -N netbsd.0
Crash version 6.99.49, image version 6.99.49.
System panicked: trap
Backtrace from time of crash is available.
crash> dmesg
Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
     2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014
     The NetBSD Foundation, Inc.  All rights reserved.
Copyright (c) 1982, 1986, 1989, 1991, 1993
     The Regents of the University of California.  All rights reserved.

NetBSD 6.99.49 (GENERIC.201407300840Z) #0: Wed Jul 30 09:31:48 UTC 2014
builds <at> b45.netbsd.org:/home/builds/ab/HEAD/amd64/201407300840Z-obj/home/source/ab/HEAD/src/sys/arch/amd64/compile/GENERIC
total memory = 2968 MB
avail memory = 2865 MB
timecounter: Timecounters tick every 10.000 msec
timecounter: Timecounter "i8254" frequency 1193182 Hz quality 100
LENOVO 7434AZ9 (ThinkPad T400)
mainbus0 (root)
ACPI: RSDP 0xf6440 000024 (v02 LENOVO)
(Continue reading)

Thomas Klausner | 29 Jul 22:25 2014
Picon

[xorg] Xserver pre-pciaccess cleanup

This looks like it might affect NetBSD too, so if you have time,
please take a look at and comment on the changeset; thread starts at
http://lists.x.org/archives/xorg-devel/2014-July/043343.html

Thanks,
 Thomas

----- Forwarded message from Adam Jackson <ajax <at> redhat.com> -----

Date: Tue, 29 Jul 2014 15:00:07 -0400
From: Adam Jackson <ajax <at> redhat.com>
To: xorg-devel <at> lists.x.org
Subject: [PATCH 00/12] Clean up yet more pre-pciaccess garbage

This series removes most of the remaining OS awareness in the PCI code,
delegating the hard work to pciaccess; phrased another way, struct
VidMemInfo is gone, and good riddance.

This has a bit more external impact than the last dead-code series, but
still not a huge amount.  Dropping xf86{Map,Unmap}VidMem means fixing up
geode, sis, xgi, neomagic, and newport.  Dropping xf86LinearVidMem means
a small fixup to mach64, and also means the pre-BWX alpha support is now
formally Somebody Else's Problem.  Finally, OpenBSD's pciaccess backend
requires that you pass in the /dev/mem fd from above, which is asymmetric
from how every other OS does it, so pciaccess will need an adjustment too.

Again, I'm happy to fix up all of the above before this is merged.  I
assume the OpenBSD fixup will basically be moving that code down into
pciaccess, but I'm open to suggestions.

(Continue reading)


Gmane