After the latest dri update X11 reports a KMS error with a Radeon card which previously worked just fine.

Konstantin Belousov kostikbel at gmail.com
Sat Oct 18 13:43:47 UTC 2014


On Sat, Oct 18, 2014 at 02:40:00PM +0200, Tijl Coosemans wrote:
> On Sat, 18 Oct 2014 15:25:21 +0300 Jukka Ukkonen <jau789 at gmail.com> wrote:
> > Current version of pixman: 0.32.4
> >          Before reporting problems, check http://wiki.x.org
> >          to make sure that you have the latest version.
> > Markers: (--) probed, (**) from config file, (==) default setting,
> >          (++) from command line, (!!) notice, (II) informational,
> >          (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
> > (==) Log file: "/var/log/Xorg.0.log", Time: Sat Oct 18 14:25:50 2014
> > (==) Using config file: "/usr/local/lib/X11/xorg.conf"
> > (==) Using system config directory "/usr/local/share/X11/xorg.conf.d"
> > *(II) [KMS] drm report modesetting isn't supported.*
> > 
> > Fatal server error:
> > no screens found
> > 
> > Please consult the The X.Org Foundation support
> >           at http://wiki.x.org
> >   for help.
> > Please also check the log file at "/var/log/Xorg.0.log" for additional 
> > information.
> 
> Please try the attached patch for graphics/libdrm.  The library checks
> hw.dri.0.modesetting sysctl to see if KMS is available before loading
> the DRM kernel modules that provide that sysctl.

> Index: graphics/libdrm/Makefile
> ===================================================================
> --- graphics/libdrm/Makefile	(revision 371105)
> +++ graphics/libdrm/Makefile	(working copy)
> @@ -3,6 +3,7 @@
>  
>  PORTNAME=	libdrm
>  PORTVERSION=	2.4.58
> +PORTREVISION=	1
>  PORTEPOCH=	1
>  CATEGORIES=	graphics x11
>  MASTER_SITES=	http://dri.freedesktop.org/libdrm/
> @@ -32,6 +33,7 @@
>  .if ${ARCH} == "amd64" || ${ARCH} == "i386"
>  CONFIGURE_ARGS+=--enable-libkms
>  PLIST_SUB+=	KMS="" NOUVEAU=""
> +EXTRA_PATCHES+=	${FILESDIR}/extra-xf86drmMode.c
>  .else
>  CONFIGURE_ARGS+=--disable-libkms
>  PLIST_SUB+=	KMS="@comment " NOUVEAU="@comment "
> Index: graphics/libdrm/files/extra-xf86drmMode.c
> ===================================================================
> --- graphics/libdrm/files/extra-xf86drmMode.c	(revision 0)
> +++ graphics/libdrm/files/extra-xf86drmMode.c	(working copy)
> @@ -0,0 +1,42 @@
> +--- xf86drmMode.c.orig	2010-09-08 14:23:39.000000000 +0200
> ++++ xf86drmMode.c	2011-07-18 18:59:11.000000000 +0200
> +@@ -774,38 +774,7 @@
> + 	if (found)
> + 		return 0;
> + #elif defined (__FreeBSD__) || defined (__FreeBSD_kernel__)
> +-	char kbusid[1024], sbusid[1024];
> +-	char oid[128];
> +-	int domain, bus, dev, func;
> +-	int i, modesetting, ret;
> +-	size_t len;
> +-
> +-	ret = sscanf(busid, "pci:%04x:%02x:%02x.%d", &domain, &bus, &dev,
> +-	    &func);
> +-	if (ret != 4)
> +-		return -EINVAL;
> +-	snprintf(kbusid, sizeof(kbusid), "pci:%04x:%02x:%02x.%d", domain, bus,
> +-	    dev, func);
> +-
> +-	/* How many GPUs do we expect in the machine ? */
> +-	for (i = 0; i < 16; i++) {
> +-		snprintf(oid, sizeof(oid), "hw.dri.%d.busid", i);
> +-		len = sizeof(sbusid);
> +-		ret = sysctlbyname(oid, sbusid, &len, NULL, 0);
> +-		if (ret == -1) {
> +-			if (errno == ENOENT)
> +-				continue;
> +-			return -EINVAL;
> +-		}
> +-		if (strcmp(sbusid, kbusid) != 0)
> +-			continue;
> +-		snprintf(oid, sizeof(oid), "hw.dri.%d.modesetting", i);
> +-		len = sizeof(modesetting);
> +-		ret = sysctlbyname(oid, &modesetting, &len, NULL, 0);
> +-		if (ret == -1 || len != sizeof(modesetting))
> +-			return -EINVAL;
> +-		return (modesetting ? 0 : -ENOSYS);
> +-	}
> ++	return 0;
> + #elif defined(__DragonFly__)
> + 	return 0;
> + #endif

I confirm both the problem and diagnosis as well.  After the update,
I have to use something like 'kldload radeonkms && startx' to start
X server.

Re-applying the patch which pretends that KMS is supported unconditionally
looks as a step back for me.  The libdrm change was finally committed,
and this is what must be done by userspace to ensure backward binary
compatibilty with drm updates in kernel.

Obvious correct solution is to load module before the check, or require
the loaded module when X server starts.  I have no idea how hard to
implement option one is.


More information about the freebsd-x11 mailing list