Havard Eidnes | 9 Oct 20:21 2014

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

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

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


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

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
(Continue reading)

matthew green | 17 Sep 09:21 2014

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

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

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

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


Piotr 'aniou' Meyer

Chavdar Ivanov | 8 Aug 14:53 2014

More amd64 drmkms radeon


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
(Continue reading)

Dave Tyson | 5 Aug 17:43 2014

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

[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


----- 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)

Manuel Bouyer | 20 Jul 19:10 2014

environnement for touch screen ?

so, I have X11 running on a beaglebone with a 12" touchscreen LCD.
What environnement would be appropriate for a touchscreen ?
(I could also connect a USB keyboard and mouse but it's less fun :)

I looks like deforaos could provide some components here, but
I couldn't find any window manager in meta-pkgs/deforaos-desktop and
I don't know which one to use (and I don't want to build the whole
deforaos-desktop for now, the beaglebone isn't stable enough).


Manuel Bouyer <bouyer <at> antioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la difference

Piotr Meyer | 28 Jun 18:25 2014

amd64 DRMKMS results, 28 Jun 2014

Today I got working console and X (stable, as I assume - Firefox works
without troubles) on 6.99.44. I noticed problems with glxinfo, although
working X was most important target.

Graphics card: HD Graphics 2500 embedded into Pentium G2030 (Ivy Bridge).

Full log (uname, dmesg, Xorg.0.log, xorg.conf, error from glxgears) is
available from http://smutek.pl/netbsd/drmkms-ok-report.txt - short
excerpt below:

cpu0 at mainbus0 apid 0: Intel(R) Pentium(R) CPU G2030  <at>  3.00GHz, id 0x306a9

i915drmkms0 at pci0 dev 2 function 0WARNING: module error: vfs load failed for `pciverbose', error 45
WARNING: module error: vfs load failed for `pciverbose', error 45
: vendor 0x8086 product 0x0152 (rev. 0x09)
drmkms0 at i915drmkms0
drm: Memory usable by graphics device = 2048M
drm: MTRR allocation failed.  Graphics performance may suffer.
drm: Supports vblank timestamp caching Rev 1 (10.10.2010).
drm: Driver supports precise vblank timestamp query.
drmkms0: interrupting at ioapic0 pin 16 (i915)
i915drmkms0: framebuffer at 0xffff8000453d5000, size 1920x1080, depth 32, stride 7680
wsdisplay0 at i915drmkms0 kbdmux 1: console (default, vt100 emulation)
wsmux1: connecting to wsdisplay0
drmkms0: info: registered panic notifier

Message from glxinfo, glxgears:

name of display: :0
Unrecognized deviceID 152
(Continue reading)