Bug 483297 - X server crash on USB HUB random reset
X server crash on USB HUB random reset
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-evdev (Show other bugs)
11
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: Peter Hutterer
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-01-30 14:26 EST by Jan Kratochvil
Modified: 2009-11-18 09:14 EST (History)
3 users (show)

See Also:
Fixed In Version: 2.2.6-1.fc11
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-11-18 09:14:17 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
/var/log/Xorg.0.log.old (155.73 KB, text/plain)
2009-02-02 01:56 EST, Jan Kratochvil
no flags Details
/var/log/Xorg.0.log.old from another crash. (567.12 KB, text/plain)
2009-02-14 12:25 EST, Jan Kratochvil
no flags Details
X crash with xorg-x11-drv-evdev-2.1.0-1 (105.56 KB, text/plain)
2009-02-15 13:08 EST, Łukasz Lis
no flags Details
.xsession-errors for Xorg.0.log in 331979, xorg-x11-drv-evdev-2.1.0-1 (67.62 KB, text/plain)
2009-02-15 13:11 EST, Łukasz Lis
no flags Details
xorg log right after the crash (106.50 KB, text/plain)
2009-05-22 04:48 EDT, Armands Liepins
no flags Details
/var/log/Xorg.0.log (86.37 KB, text/plain)
2009-06-25 03:43 EDT, Jan Kratochvil
no flags Details
Unverified patch I am going to test. (1.09 KB, patch)
2009-07-12 05:38 EDT, Jan Kratochvil
no flags Details | Diff
/var/log/Xorg.0.log.old (40.77 KB, text/plain)
2009-08-06 05:39 EDT, Armands Liepins
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
FreeDesktop.org 23048 None None None Never

  None (edit)
Description Jan Kratochvil 2009-01-30 14:26:46 EST
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.
Comment 1 Peter Hutterer 2009-02-01 20:36:24 EST
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.
Comment 2 Jan Kratochvil 2009-02-02 01:56:42 EST
Created attachment 330587 [details]
/var/log/Xorg.0.log.old
Comment 3 Jan Kratochvil 2009-02-14 12:25:21 EST
Created attachment 331932 [details]
/var/log/Xorg.0.log.old from another crash.

I manually intentionally disconnected the USB hub in this case.
Comment 4 Łukasz Lis 2009-02-15 13:08:53 EST
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.
Comment 5 Łukasz Lis 2009-02-15 13:11:21 EST
Created attachment 331980 [details]
.xsession-errors for Xorg.0.log in 331979, xorg-x11-drv-evdev-2.1.0-1
Comment 6 Peter Hutterer 2009-02-15 18:33:42 EST
(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.
Comment 7 Jan Kratochvil 2009-02-15 18:42:23 EST
(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.)
Comment 8 Armands Liepins 2009-05-22 04:48:26 EDT
Created attachment 345068 [details]
xorg log right after the crash

The same here.
xorg-x11-drv-evdev-2.1.3-1.fc10
Comment 9 Jan Kratochvil 2009-06-25 03:43:34 EDT
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
Comment 10 Jan Kratochvil 2009-07-07 15:26:20 EDT
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
Comment 12 Jan Kratochvil 2009-07-12 05:38:24 EDT
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}
Comment 13 Peter Hutterer 2009-07-14 00:09:58 EDT
was the last crash from a server with this patch or without this patch? Patch itself looks good.
Comment 14 Jan Kratochvil 2009-07-14 01:16:02 EDT
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>).
Comment 15 Peter Hutterer 2009-07-20 00:55:59 EDT
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.
Comment 16 Jan Kratochvil 2009-07-28 15:10:59 EDT
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. :-|
Comment 17 Peter Hutterer 2009-07-30 00:33:22 EDT
(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
Comment 18 Peter Hutterer 2009-08-02 20:46:26 EDT
Upstream bug is http://bugs.freedesktop.org/show_bug.cgi?id=23048 but we don't have a test-case to reproduce it yet.
Comment 19 Armands Liepins 2009-08-06 05:39:01 EDT
Created attachment 356478 [details]
/var/log/Xorg.0.log.old
Comment 20 Armands Liepins 2009-08-06 05:42:11 EDT
still happening here, see log attached to #19

xorg-x11-drv-evdev-2.2.3-1.fc11.i586
Comment 21 Armands Liepins 2009-09-29 07:59:09 EDT
xorg-x11-drv-evdev-2.2.5-1.fc11.i586

still crashing, disconnects are due to broken mouse wire
Comment 22 Peter Hutterer 2009-10-06 21:14:36 EDT
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
Comment 23 Peter Hutterer 2009-10-06 21:17:02 EDT
http://koji.fedoraproject.org/koji/taskinfo?taskID=1732094

(bonus points for adding the right link)
Comment 24 Fedora Update System 2009-10-19 00:00:24 EDT
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
Comment 25 Fedora Update System 2009-10-20 20:50:30 EDT
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
Comment 26 Fedora Update System 2009-11-18 09:14:10 EST
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.

Note You need to log in before you can comment on or make changes to this bug.