first of all, this happens with xorg-server 1.2 and 1.1.1 and was reproduced with the following drivers drivers: nvidia 97xx, nvidia 96xx, nv, vesa. kernel 2.6.19.2 works fine with all of them. when i start the x server, it crashes instantly. with nvidia drivers, i see the logo and then it crashes. i get this output on the console: // begin log X Window System Version 7.2.0 Release Date: 22 January 2007 X Protocol Version 11, Revision 0, Release 7.2 Build Operating System: UNKNOWN Current Operating System: Linux borgel 2.6.20-ARCH #1 SMP PREEMPT Tue Feb 6 10:39:12 CET 2007 i686 Build Date: 01 February 2007 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Module Loader present 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: Fri Feb 9 14:50:09 2007 (==) Using config file: "/etc/X11/xorg.conf" The XKEYBOARD keymap compiler (xkbcomp) reports: > Warning: Multiple names for keycode 211 > Using <I211>, ignoring <AB11> expected keysym, got XF86AudioEject: line 2232 of inet Errors from xkbcomp are not fatal to the X server The XKEYBOARD keymap compiler (xkbcomp) reports: > Warning: Type "ONE_LEVEL" has 1 levels, but <RALT> has 2 symbols > Ignoring extra symbols Errors from xkbcomp are not fatal to the X server Backtrace: 0: X(xf86SigHandler+0x84) [0x80d0284] 1: [0xffffe420] 2: X(main+0x6ad) [0x806e7ed] 3: /lib/libc.so.6(__libc_start_main+0xd8) [0xb7d717c8] 4: X(FontFileCompleteXLFD+0xa1) [0x806d8f1] Fatal server error: Caught signal 11. Server aborting waiting for X server to begin accepting connections giving up. xinit: Connection reset by peer (errno 104): unable to connect to X server xinit: No such process (errno 3): Server error. // end log I rebuilt xorg-server 1.2.0 with --enable-debug which didn't give me any additional output. When i added Option "NoTrapSignals" "true" to my xorg.conf, the system froze after starting the x server, so i can't get any coredump. i only have this one pc, so logging in via ssh is not possible for me, sorry. Without that option, X just crashes. My distro is Arch Linux and I have a nvidia geforce 6800gt.
i think i got it. when i use evdev for my mouse, X segfaults at startup. when i use "mouse", it works. i have xf86-input-evdev 1.1.5
Sorry about the phenomenal bug spam, guys. Adding xorg-team@ to the QA contact so bugs don't get lost in future.
btw, other people using arch and evdev had the same problem after the upgrade to 2.6.20. seems like the event devices switched and when the device which was specified in the xorg.conf wasn't the correct one anymore, it produced a segfault. a solution is to switch to /dev/input/mice so you don't have to specify the exact device, or use the "name" option from evdev, which does not change. I really hope such problems will be gone once autodetection of input devices will come to xorg *sigh*
I'm seeing the same segmentation fault and a nearly identical backtrace using kernel 2.6.20 with Xorg 6.9 on Slackware. However, unlike the original reporter, this is not due to mouse events; in my case, the mouse device is set to /dev/input/mice. (Using the even more vanilla /dev/psaux makes no difference.) At an even more basic level, "X -probeonly" also suffers the segfault. The smoking gun I see are these lines dumped to the console: (EE) end of block range 0x177 < begin 0x3f0 (EE) end of block range 0x177 < begin 0x3f0 (WW) ****INVALID IO ALLOCATION**** b: 0x14d0 e: 0x14d7 correcting Those lines don't show up for prior Linux kernel versions. Lastly, this bug doesn't show up on an old ISA-bus computer with a Mach64 framebuffer, all other things being equal.
I found the trigger of the crash-on-startup with kernel 2.6.20, though I'm not sure whether the cause is rightly in userspace or in the kernel. On 2006-10-04, Alan Cox made a commit to the Linux kernel that changed the way the PCI bus is initialized ("quirks mode") changing DECLARE_PCI_FIXUP_HEADER to DECLARE_PCI_FIXUP_EARLY if the chip architecture is Intel 82801 and/or Serverworks. My HP dc5000S workstation has the 82801 chipset and thus generates a segfault and backtrace substantially similar to the one originally reported here. Anyway, the Linux Kernel commit (git identifier) is: 368c73d4f689dae0807d0a2aa74c61fd2b9b075f Perhaps my particular issue needs to be filed as a new bug altogether...
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.