Created attachment 24989 [details] log file Running Debian unstable, with: xserver 1.6.1 intel driver 2.7.0 libdrm 2.4.9 mesa 7.4 linux 2.6.29.1 (with KMS enabled) When starting X with no configuration file, it seems to try to load a number of drivers all at once, and then fails because the fbdev driver fails. Note that with a minimal configuration file, it only loads the intel driver, but fails for another reason, probably unrelated (bug# 21307)
I forgot to mention, this is with a 945GM (white macbook)
So this is not intel driver bug. Please report this issue to Debian.
For the record, the Debian bug is http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=508476
> --- Comment #2 from Gordon Jin <gordon.jin@intel.com> 2009-04-21 17:50:24 PST --- > So this is not intel driver bug. Please report this issue to Debian. > eh, what? this may be a Driver/fbdev or DDX/xorg bug, but it's certainly not debian specific, so NOTOURBUG isn't appropriate here.
(In reply to comment #4) > > --- Comment #2 from Gordon Jin <gordon.jin@intel.com> 2009-04-21 17:50:24 PST --- > > So this is not intel driver bug. Please report this issue to Debian. > > > eh, what? this may be a Driver/fbdev or DDX/xorg bug, but it's > certainly not debian specific, so NOTOURBUG isn't appropriate here. > "OUR" here means Intel driver, which I don't see related to this failure. I don't object you filing to Driver/fbdev bug. Note the summary indicates a distribution issue, though I don't think it's a bug.
(In reply to comment #5) > (In reply to comment #4) > > > --- Comment #2 from Gordon Jin <gordon.jin@intel.com> 2009-04-21 17:50:24 PST --- > > > So this is not intel driver bug. Please report this issue to Debian. > > > > > eh, what? this may be a Driver/fbdev or DDX/xorg bug, but it's > > certainly not debian specific, so NOTOURBUG isn't appropriate here. > > > > "OUR" here means Intel driver, which I don't see related to this failure. I > don't object you filing to Driver/fbdev bug. > > Note the summary indicates a distribution issue, though I don't think it's a > bug. > To me the real bug seems to be that X continue trying to other drivers even after the best choice (intel) was successful. So maybe a bug in the server? I'll move it there
> "OUR" here means Intel driver no, OUR here means bugs.freedesktop.org (and i don't see anything distro specific in the summary). anyway, moving to the server since that's where the FatalError comes from.
As I wrote in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=508476#24 here's my understanding: - the intel (or whatever) driver gets loaded, its PciProbe hook is called by probe_devices_from_device_sections(), and it claims the pci device - then fbdev gets loaded. Since the device is already claimed, xf86CheckPciSlot() in probe_devices_from_device_sections() returns 0, so xf86CallDriverProbe() calls the Probe hook instead of PciProbe. When there's no BusId, and /dev/fb0 exists, fbdev's Probe hook calls xf86ClaimFbSlot() - finally, in xf86PostProbe() both fbSlotClaimed and pciSlotClaimed are true, so we FatalError() I guess FBDevProbe should somehow check that its device doesn't correspond to an already claimed pci device. One possible option suggested by Michel Dänzer would be for the autoconfig path to add a bus id to the fbdev device section. ajax, any idea how this should be fixed?
the fedora patch at http://cvs.fedoraproject.org/viewvc/devel/xorg-x11-server/xserver-1.5.0-bad-fbdev-thats-mine.patch?revision=1.2&view=markup fixes this.
*** Bug 11172 has been marked as a duplicate of this bug. ***
(In reply to comment #9) > the fedora patch at > http://cvs.fedoraproject.org/viewvc/devel/xorg-x11-server/xserver-1.5.0-bad-fbdev-thats-mine.patch?revision=1.2&view=markup > fixes this. It does, but it's a hack. The problem iirc is that drivers "claim" the device entity early in preinit, but then have no way to unclaim it later when they discover they can't really drive the device.
The patch was pushed as xserver commit aef6b904ebf0d7de6259058606c7c04ea177bda3 .
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.