Description of problem: Machine with X left running 10 minutes alone restarted its X server. Version-Release number of selected component (if applicable): xorg-x11-drv-evdev-2.1.1-1.fc10.x86_64 (other versions are 5 days old updated F10 - 5 days due to the uptime, I do not have an easy list of the package versions 5 days ago) How reproducible: Not reproducible, IIRC found it the first time in my F10 history. Actual results: Backtrace: 0: /usr/bin/Xorg(xorg_backtrace+0x26) [0x4e7a26] 1: /usr/bin/Xorg(xf86SigHandler+0x39) [0x47a679] 2: /lib64/libc.so.6 [0x3272a32f90] 3: /usr/lib64/xorg/modules/input//evdev_drv.so(EvdevMBEmuBlockHandler+0x15) [0x7f965e455075] 4: /usr/bin/Xorg(BlockHandler+0x85) [0x44a355] 5: /usr/bin/Xorg(WaitForSomething+0x161) [0x4e4eb1] 6: /usr/bin/Xorg(Dispatch+0x7f) [0x4465ef] 7: /usr/bin/Xorg(main+0x45d) [0x42cd1d] 8: /lib64/libc.so.6(__libc_start_main+0xe6) [0x3272a1e576] 9: /usr/bin/Xorg [0x42c0f9] Fatal server error: Caught signal 11. Server aborting Dump of assembler code for function EvdevMBEmuBlockHandler: 0x4060 <EvdevMBEmuBlockHandler+0>: mov %rbp,-0x8(%rsp) 0x4065 <EvdevMBEmuBlockHandler+5>: mov %rbx,-0x10(%rsp) 0x406a <EvdevMBEmuBlockHandler+10>: sub $0x18,%rsp 0x406e <EvdevMBEmuBlockHandler+14>: mov 0x68(%rdi),%rax 0x4072 <EvdevMBEmuBlockHandler+18>: mov %rsi,%rbp 0x4075 <EvdevMBEmuBlockHandler+21>: cmpb $0x0,0xa1(%rax) <################ 0x407c <EvdevMBEmuBlockHandler+28>: jne 0x4090 <EvdevMBEmuBlockHandler+48> 291 void EvdevMBEmuBlockHandler(pointer data, 292 struct timeval **waitTime, 293 pointer LastSelectMask) 294 { 295 InputInfoPtr pInfo = (InputInfoPtr) data; 296 EvdevPtr pEvdev= (EvdevPtr) pInfo->private; 297 int ms; 298 299 if (pEvdev->emulateMB.pending) <################### 300 { 301 ms = pEvdev->emulateMB.expires - GetTimeInMillis (); 302 if (ms <= 0) 303 ms = 0; 304 AdjustWaitForDelay (waitTime, ms); 305 } 306 } -rw-r--r-- 1 root root 159463 2009-01-30 19:55:47.000000000 +0100 /var/log/Xorg.0.log.old Jan 30 19:55:14 host0 kernel: hub 1-1:1.0: port 3 disabled by hub (EMI?), re-enabling... Jan 30 19:55:14 host0 kernel: usb 1-1.3: USB disconnect, address 5 Jan 30 19:55:14 host0 kernel: usb 1-1.3: new low speed USB device using ehci_hcd and address 12 Jan 30 19:55:14 host0 kernel: usb 1-1.3: configuration #1 chosen from 1 choice Jan 30 19:55:14 host0 kernel: input: Logitech USB-PS/2 Optical Mouse as /devices/pci0000:00/0000:00:1d.7/usb1/1-1/1-1.3/1-1.3:1.0/input/input104 Jan 30 19:55:14 host0 kernel: input,hidraw0: USB HID v1.10 Mouse [Logitech USB-PS/2 Optical Mouse] on usb-0000:00:1d.7-1.3 Jan 30 19:55:14 host0 kernel: usb 1-1.3: New USB device found, idVendor=046d, idProduct=c040 Jan 30 19:55:14 host0 kernel: usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0 Jan 30 19:55:14 host0 kernel: usb 1-1.3: Product: USB-PS/2 Optical Mouse Jan 30 19:55:14 host0 kernel: usb 1-1.3: Manufacturer: Logitech Jan 30 19:56:25 host0 acpid: client connected from 25102[0:0] Jan 30 19:56:38 host0 gdm-simple-greeter[25245]: WARNING: could not find item with id '__auto' to remove timer Jan 30 19:56:38 host0 gdm-simple-greeter[25245]: WARNING: Unable to query filesystem type for /home/android: Error getting filesystem info: No such file or directory Jan 30 19:56:40 host0 gnome-session[25305]: WARNING: Could not parse desktop file /home/lace/.config/autostart/gnome-volume-manager.desktop: Key file does not have key 'Exec' Expected results: No crash. Additional info: That message `disabled by hub (EMI?), re-enabling...' occasionally occurs here but so far there were no problems from it.
can you please attach the log file from this session. Looks like the device got removed and then the blockhandler got called after the removal. This shouldn't happen, but I don't quite see yet why it does.
Created attachment 330587 [details] /var/log/Xorg.0.log.old
Created attachment 331932 [details] /var/log/Xorg.0.log.old from another crash. I manually intentionally disconnected the USB hub in this case.
Created attachment 331979 [details] X crash with xorg-x11-drv-evdev-2.1.0-1 I have the same problem. Here's my X.org log. I've already downgraded from 2.1.1-1 to 2.1.0-1, but it didn't help. I'll downgrade further and check if it improves anything. I'll upload the session log in a second.
Created attachment 331980 [details] .xsession-errors for Xorg.0.log in 331979, xorg-x11-drv-evdev-2.1.0-1
(In reply to comment #3) > I manually intentionally disconnected the USB hub in this case. Is this a always reproducable test on your box? I tried disconnecting with and without hub in between to no avail.
(In reply to comment #6) > (In reply to comment #3) > > I manually intentionally disconnected the USB hub in this case. > > Is this a always reproducable test on your box? No, I also cannot reproduce it intentionally. (I used the word "intentionally" to express it was no hardware glitch but a normal USB disconnect.)
Created attachment 345068 [details] xorg log right after the crash The same here. xorg-x11-drv-evdev-2.1.3-1.fc10
Created attachment 349351 [details] /var/log/Xorg.0.log xorg-x11-drv-evdev-2.2.1-3.fc11.x86_64 Backtrace: 0: /usr/bin/Xorg(xorg_backtrace+0x26) [0x4e8a26] 1: /usr/bin/Xorg(xf86SigHandler+0x6f) [0x47d6af] 2: /lib64/libc.so.6 [0x39db233370] 3: /usr/lib64/xorg/modules/input//evdev_drv.so(EvdevMBEmuBlockHandler+0x15) [0x7f703b584cb5] 4: /usr/bin/Xorg(BlockHandler+0x85) [0x44af05] 5: /usr/bin/Xorg(WaitForSomething+0x141) [0x4e6551] 6: /usr/bin/Xorg(Dispatch+0x92) [0x446bf2] 7: /usr/bin/Xorg(main+0x3b5) [0x42d0d5] 8: /lib64/libc.so.6(__libc_start_main+0xfd) [0x39db21ea2d] 9: /usr/bin/Xorg [0x42c559] /var/log/messages (cut the columns): 08:37:29: hub 1-1:1.0: port 4 disabled by hub (EMI?), re-enabling... 08:37:29: usb 1-1.4: USB disconnect, address 26 08:37:30: usb 1-1.4: new low speed USB device using ehci_hcd and address 28 08:37:30: usb 1-1.4: New USB device found, idVendor=04f2, idProduct=0116 08:37:30: usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=0 08:37:30: usb 1-1.4: Product: USB Keyboard 08:37:30: usb 1-1.4: Manufacturer: CHICONY 08:37:30: usb 1-1.4: configuration #1 chosen from 1 choice 08:37:30: input: CHICONY USB Keyboard as /devices/pci0000:00/0000:00:1d.7/usb1/1-1/1-1.4/1-1.4:1.0/input/input14 08:37:30: generic-usb 0003:04F2:0116.0005: input,hidraw1: USB HID v1.10 Keyboard [CHICONY USB Keyboard] on usb-0000:00:1d.7-1.4/input0 08:37:39 ntpd: Deleting interface #10 tap0, 172.20.0.1#123, interface stats: received=0, sent=0, dropped=0, active_time=36090 secs -rw-r--r-- 1 root root 88439 2009-06-25 08:37:32.000000000 +0200 /var/log/Xorg.0.log-segv
Another crash but in this case no possibly-broken USB hub was connected. Keyboard/mouse were connected just to the internal Lenovo T60 USB port. hub 2-0:1.0: port 2 disabled by hub (EMI?), re-enabling... usb 2-2: USB disconnect, address 9 usb 2-2: new low speed USB device using uhci_hcd and address 10 usb 2-2: New USB device found, idVendor=046d, idProduct=c040 usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 usb 2-2: Product: USB-PS/2 Optical Mouse usb 2-2: Manufacturer: Logitech usb 2-2: configuration #1 chosen from 1 choice input: Logitech USB-PS/2 Optical Mouse as /devices/pci0000:00/0000:00:1d.0/usb2/2-2/2-2:1.0/input/input31 generic-usb 0003:046D:C040.0016: input,hidraw1: USB HID v1.10 Mouse [Logitech USB-PS/2 Optical Mouse] on usb-0000:00:1d.0-2/input0 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 064: ID 152d:2338 JMicron Technology Corp. / JMicron USA Technology Corp. JM20337 Hi-Speed USB to SATA & PATA Combo Bridge Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 002 Device 007: ID 04f2:0116 Chicony Electronics Co., Ltd KU-2971 German Keyboard Bus 002 Device 010: ID 046d:c040 Logitech, Inc. Corded Tilt-Wheel Mouse Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 005 Device 003: ID 0483:2016 SGS Thomson Microelectronics Fingerprint Reader Bus 005 Device 030: ID 0a5c:2110 Broadcom Corp. Bluetooth Controller
Created attachment 351382 [details] Unverified patch I am going to test. xorg-x11-server-Xorg-1.6.1.901-2.fc11.x86_64 xorg-x11-drv-evdev-2.2.2-1.fc11.x86_64 MALLOC_CHECK_=3 Core was generated by `/usr/bin/Xorg-orig -core :0 -br -verbose -auth /var/run/gdm/auth-for-gdm-miRPTl'. Program terminated with signal 6, Aborted. (gdb) bt #0 0x0000003398c332f5 in *__GI_raise (sig=<value optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #1 0x0000003398c34b20 in *__GI_abort () at abort.c:88 #2 0x0000000000465843 in ddxGiveUp () at xf86Init.c:1441 #3 0x00000000004f21fd in AbortServer () at log.c:397 #4 0x00000000004f28ee in FatalError (f=0x577700 "Caught signal %d. Server aborting\n") at log.c:522 #5 0x000000000047d6bf in xf86SigHandler (signo=11) at xf86Events.c:387 #6 <signal handler called> #7 EvdevMBEmuBlockHandler (data=0x35ed2d0, waitTime=0x7fff9fdb5028, LastSelectMask=0x7d0b20) at emuMB.c:299 #8 0x000000000044af05 in BlockHandler (pTimeout=0x7fff9fdb5028, pReadmask=0x7d0b20) at dixutils.c:388 #9 0x00000000004e6551 in WaitForSomething (pClientsReady=<value optimized out>) at WaitFor.c:215 #10 0x0000000000446bf2 in Dispatch () at dispatch.c:367 #11 0x000000000042d0d5 in main (argc=<value optimized out>, argv=0x7fff9fdb5258, envp=<value optimized out>) at main.c:397 (gdb) up 7 #7 EvdevMBEmuBlockHandler (data=0x35ed2d0, waitTime=0x7fff9fdb5028, LastSelectMask=0x7d0b20) at emuMB.c:299 299 if (pEvdev->emulateMB.pending) (gdb) l 294 { 295 InputInfoPtr pInfo = (InputInfoPtr) data; 296 EvdevPtr pEvdev= (EvdevPtr) pInfo->private; 297 int ms; 298 299 if (pEvdev->emulateMB.pending) 300 { 301 ms = pEvdev->emulateMB.expires - GetTimeInMillis (); 302 if (ms <= 0) 303 ms = 0; (gdb) p *(InputInfoPtr) data $1 = {next = 0x23fd680, name = 0x3398f69f98 "0\342~\3", flags = 20763600, device_control = 0x128590c, read_input = 0x341ae90, control_proc = 0xc00000000, close_proc = 0x35ed310, switch_mode = 0x100000000, conversion_proc = 0x89defae79f1e0000, reverse_conversion_proc = 0xaeea22000000000d, set_device_valuators = 0xacdc9451e39, fd = 28750336, atom = 167772160, dev = 0x42fc0d030080da, private = 0xd86f00000000, private_flags = 1376047, first = 0, last = 130113, old_x = 1376047, old_y = 0, type_name = 0x42fc0d "L\211l$\360H\201", <incomplete sequence \354\230>, always_core_feedback = 0x1b6b4000000d86f, conf_idev = 0x81da0a000000, drv = 0xc8441d38aeeb2400, module = 0xa120000002000ace, options = 0xd8ae0fae9, history_size = 381} (gdb) p *(EvdevPtr) ((InputInfoPtr) data)->private Cannot access memory at address 0xd86f00000000 (gdb) up #8 0x000000000044af05 in BlockHandler (pTimeout=0x7fff9fdb5028, pReadmask=0x7d0b20) at dixutils.c:388 388 (*handlers[i].BlockHandler) (handlers[i].blockData, (gdb) l 383 for (i = 0; i < screenInfo.numScreens; i++) 384 (* screenInfo.screens[i]->BlockHandler)(i, 385 screenInfo.screens[i]->blockData, 386 pTimeout, pReadmask); 387 for (i = 0; i < numHandlers; i++) 388 (*handlers[i].BlockHandler) (handlers[i].blockData, 389 pTimeout, pReadmask); 390 if (handlerDeleted) 391 { 392 for (i = 0; i < numHandlers;) (gdb) p i $4 = 13 (gdb) p numHandlers $5 = 14 (gdb) p handlers[i] $6 = {BlockHandler = 0x7fa8bbb64cc0 <EvdevMBEmuBlockHandler>, WakeupHandler = 0x7fa8bbb64fd0 <EvdevMBEmuWakeupHandler>, blockData = 0x2184550, deleted = 1} (gdb) p handlers[i].deleted $7 = 1 (gdb) p handlers[0] $8 = {BlockHandler = 0x44ae70 <NoopDDA>, WakeupHandler = 0x47d9a0 <xf86Wakeup>, blockData = 0x0, deleted = 0} (gdb) p handlers[1] $9 = {BlockHandler = 0x7fa8bdb2b360 <shadowBlockHandler>, WakeupHandler = 0x7fa8bdb2b260 <shadowWakeupHandler>, blockData = 0x13cd3d0, deleted = 0} (gdb) p handlers[2] $10 = {BlockHandler = 0x463c10 <block_handler>, WakeupHandler = 0x463d70 <wakeup_handler>, blockData = 0x7c6260, deleted = 0} (gdb) p handlers[3] $11 = {BlockHandler = 0x502720 <IdleTimeBlockHandler>, WakeupHandler = 0x502500 <IdleTimeWakeupHandler>, blockData = 0x0, deleted = 0} (gdb) p handlers[4] $12 = {BlockHandler = 0x7fa8bbb64cc0 <EvdevMBEmuBlockHandler>, WakeupHandler = 0x7fa8bbb64fd0 <EvdevMBEmuWakeupHandler>, blockData = 0x2476d20, deleted = 1} (gdb) p handlers[5] $13 = {BlockHandler = 0x7fa8bbb64cc0 <EvdevMBEmuBlockHandler>, WakeupHandler = 0x7fa8bbb64fd0 <EvdevMBEmuWakeupHandler>, blockData = 0x160c200, deleted = 1} (gdb) p handlers[6] $14 = {BlockHandler = 0x7fa8bbb64cc0 <EvdevMBEmuBlockHandler>, WakeupHandler = 0x7fa8bbb64fd0 <EvdevMBEmuWakeupHandler>, blockData = 0x160f8e0, deleted = 1} (gdb) p handlers[7] $15 = {BlockHandler = 0x7fa8bbb64cc0 <EvdevMBEmuBlockHandler>, WakeupHandler = 0x7fa8bbb64fd0 <EvdevMBEmuWakeupHandler>, blockData = 0x1657ab0, deleted = 1} (gdb) p handlers[8] $16 = {BlockHandler = 0x7fa8bbb64cc0 <EvdevMBEmuBlockHandler>, WakeupHandler = 0x7fa8bbb64fd0 <EvdevMBEmuWakeupHandler>, blockData = 0x165c6f0, deleted = 1} (gdb) p handlers[9] $17 = {BlockHandler = 0x7fa8bbb64cc0 <EvdevMBEmuBlockHandler>, WakeupHandler = 0x7fa8bbb64fd0 <EvdevMBEmuWakeupHandler>, blockData = 0x1660110, deleted = 1} (gdb) p handlers[10] $18 = {BlockHandler = 0x7fa8bbb64cc0 <EvdevMBEmuBlockHandler>, WakeupHandler = 0x7fa8bbb64fd0 <EvdevMBEmuWakeupHandler>, blockData = 0x1666f30, deleted = 1} (gdb) p handlers[11] $19 = {BlockHandler = 0x7fa8bbb64cc0 <EvdevMBEmuBlockHandler>, WakeupHandler = 0x7fa8bbb64fd0 <EvdevMBEmuWakeupHandler>, blockData = 0x1671580, deleted = 1} (gdb) p handlers[12] $20 = {BlockHandler = 0x7fa8bbb64cc0 <EvdevMBEmuBlockHandler>, WakeupHandler = 0x7fa8bbb64fd0 <EvdevMBEmuWakeupHandler>, blockData = 0x35ed2d0, deleted = 0} (gdb) p handlers[13] $21 = {BlockHandler = 0x7fa8bbb64cc0 <EvdevMBEmuBlockHandler>, WakeupHandler = 0x7fa8bbb64fd0 <EvdevMBEmuWakeupHandler>, blockData = 0x2184550, deleted = 1}
was the last crash from a server with this patch or without this patch? Patch itself looks good.
So far still running without the patch (it will get run after the next crash). "Unfortunately" sometimes it usually survives some ~10 HUB resets and crashes on the next one or so. MALLOC_CHECK_=3 may curiously make it _less_ crashing but I am not sure. Isn't it a bug there exist so many numHandlers at all? I have just one keyboard and just one mouse. The .deleted handlers should be cleaned up immediately in (BlockHandler <handlerDeleted>).
there seems to be a small window where a removal of a block handler during signal handling does not lead to the block handler being deleted. Maybe that's what this crash triggers? Also, looking at the evdev source code, the block handlers are registered for every device, not just mice. You'll have a few of those, hence the large number of handlers. It should correspond however to the the number of input devices (xinput --list --short). I've got a patch in the pipe to only register for mice.
Thanks, yes, "xinput --list --short" shows a corresponding number of devices: "Virtual core pointer" id=0 [XPointer] "Virtual core keyboard" id=1 [XKeyboard] "Synaptics" id=2 [XExtensionPointer] "ThinkPad Extra Buttons" id=3 [XExtensionKeyboard] "AT Translated Set 2 keyboard" id=4 [XExtensionKeyboard] "Macintosh mouse button emulation" id=5 [XExtensionPointer] "TPPS/2 IBM TrackPoint" id=6 [XExtensionPointer] "SynPS/2 Synaptics TouchPad" id=7 [XExtensionPointer] "Sleep Button (CM)" id=8 [XExtensionKeyboard] "Video Bus" id=9 [XExtensionKeyboard] "Power Button (FF)" id=10 [XExtensionKeyboard] "CHICONY USB Keyboard" id=11 [XExtensionKeyboard] "Logitech USB-PS/2 Optical Mouse" id=12 [XExtensionPointer] I no longer have the problem reproducible using the same software after a travel with my notebook. :-|
(In reply to comment #15) > I've got a patch in the pipe to only register for mice. This patch is part of evdev 2.2.3, pushed out today. https://admin.fedoraproject.org/updates/xorg-x11-drv-evdev-2.2.3-1.fc11
Upstream bug is http://bugs.freedesktop.org/show_bug.cgi?id=23048 but we don't have a test-case to reproduce it yet.
Created attachment 356478 [details] /var/log/Xorg.0.log.old
still happening here, see log attached to #19 xorg-x11-drv-evdev-2.2.3-1.fc11.i586
xorg-x11-drv-evdev-2.2.5-1.fc11.i586 still crashing, disconnects are due to broken mouse wire
I think I found the issue, please try the scratch build below and let me know if that stops the crashes. http://koji.fedoraproject.org/koji/taskinfo?taskID=1732091
http://koji.fedoraproject.org/koji/taskinfo?taskID=1732094 (bonus points for adding the right link)
xorg-x11-drv-evdev-2.2.6-1.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/xorg-x11-drv-evdev-2.2.6-1.fc11
xorg-x11-drv-evdev-2.2.6-1.fc11 has been pushed to the Fedora 11 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update xorg-x11-drv-evdev'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-10659
xorg-x11-drv-evdev-2.2.6-1.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.