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

Date: Tue, 29 Jul 2014 15:00:07 -0400
From: Adam Jackson <ajax <at>>
To: xorg-devel <at>
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>>
     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 - 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)

321eniluap | 19 Jun 13:41 2014

Move Beyond TWM project proposal


I have been struggling with an attempt at changing the default Window Manager in the cross-build setup.  The Window Manager I am trying to add both have configure scripts, which seem to be the problem, but I could be wrong.  I have also tried pre-running the configure script to no avail.  I have tried both Golem and Fluxbox.  In would prefer to work with Golem, as I think it is a better fit than some others I have looked at.  Progress so far:  I have it integrated into my source tree well enough that it looks for files that should be built by the Window Manager but it does not find them.

Taylor R Campbell | 3 Apr 16:52 2014

HEADS UP: xf86-video-intel upgraded

Hi, folks!  FYI: Last night I upgraded xf86-video-intel in xsrc to

This is necessary to use Sandy Bridge or later Intel graphics.

This is a little premature because drm2, or DRM/KMS, is still flaky
and I've ported only the Intel support so far (notably, not radeon or
nouveau).  However, merging vendor imports on a branch rather than in
HEAD is too painful to do in CVS.

So, here's the state of affairs:

1. The new xf86-video-intel and drm2 are intended to work with any
Intel hardware, including pre-Sandy-Bridge.  It is still flaky,
though, and drm2 is in need of another update from upstream.  But you
can try it out with the amd64/DRMKMS kernel configuration.

2. The old xf86-video-intel does not work with drm2[*].

3. The new xf86-video-intel does not work with old drm, or DRM/UMS,
because upstream for xf86-video-intel dropped support for DRM/UMS.

[*] I believe the only issue is that there is no way to mmap a file
that is not a regular or device file, and drm2 uses a cloning device,
rather than a normal device as old drm did.  This may not be too hard
to sort out, but it requires a change to uvm like I discussed briefly
last year and never committed.  There could also be other issues

Cataldi Chaffins | 28 Mar 04:38 2014


m the w

Patrick Welche | 23 Mar 17:23 2014


I am having trouble building things like cairo which depend on

I think that the trouble stems from my
/usr/X11R7/lib/pkgconfig/fontconfig.pc file containing non-substituted
 <at>  variables, e.g.,

Cflags: -I${includedir}  <at> EXPAT_CFLAGS <at>   <at> FREETYPE_CFLAGS <at>   <at> ICONV_CFLAGS <at>   <at> LIBXML2_CFLAGS <at> 

The installed fontconfig.pc file has a recent timestamp, so must
be made by -x.

But where is it built?



$  grep -sr \\\.pc /usr/src/external/mit/xorg 
/usr/src/external/mit/xorg/lib/freetype/CVS/Entries:/ Mar 21 18:20:45 2014//
/usr/src/external/mit/xorg/share/fonts/Makefile.bdf:.SUFFIXES: .bdf .pcf${FONTSUFFIX}
/usr/src/external/mit/xorg/share/fonts/Makefile.bdf:PCFFILES+=  ${BDFFILES:S/.bdf$/.pcf${FONTSUFFIX}/}
/usr/src/external/mit/xorg/share/fonts/Makefile.bdf:CLEANFILES+=        ${BDFFILES:S/.bdf$/.pcf${FONTSUFFIX}.tmp/}

I can only see building references in the old /usr/src/x11 tree...