Description of problem: I'm using Belkin USB flip KVM (2-port)to switch between CentOS and Fedora 12. Whenever I switch from my Fedora 12 box to other machine, Fedora 12 box hangs. I have been running fedora for a long time and I never saw this issue till after I upgraded to Fedora 12 2 days back. I saw the same issue with Ubuntu 9.10. I haven't triedn any other Ubuntu revisions. Version-Release number of selected component (if applicable): Fedora 12 How reproducible: Always Steps to Reproduce: 1. Connect Belkin USB (2-port) KVM to 2 machines with one running Fedora 12. 2. Flip to other machine once. Flip back to Fedora 12, no problem. 3. Flip to other machine again and then flip it back to Fedora 12, you'll find Fedora 12 machine in hung state. Actual results: Fedora 12 machine gets into hung state and there is no way to pull it back to life without rebooting the whole box. Expected results: Fedora 12 should not hang while switching between different machines connected to Belkin 2-port USB KVM switch. Additional info: Here is part of /var/log/messages file, which shows the logs from the 2 magic flips which leaves Fedora 12 in hung state: Nov 23 18:19:08 maliks-fedora11 kernel: usb 1-4.2.2: USB disconnect, address 7 Nov 23 18:19:08 maliks-fedora11 kernel: usb 1-4.2.2: new low speed USB device using ehci_hcd and address 10 Nov 23 18:19:08 maliks-fedora11 kernel: usb 1-4.2.2: New USB device found, idVendor=050d, idProduct=0102 Nov 23 18:19:08 maliks-fedora11 kernel: usb 1-4.2.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 Nov 23 18:19:08 maliks-fedora11 kernel: usb 1-4.2.2: Product: Flip KVM Nov 23 18:19:08 maliks-fedora11 kernel: usb 1-4.2.2: Manufacturer: Belkin Corporation Nov 23 18:19:08 maliks-fedora11 kernel: usb 1-4.2.2: configuration #1 chosen from 1 choice Nov 23 18:19:08 maliks-fedora11 kernel: input: Belkin Corporation Flip KVM as /devices/pci0000:00/0000:00:1a.7/usb1/1-4/1-4.2/1-4.2.2/1-4.2.2:1.0/input/input15 Nov 23 18:19:08 maliks-fedora11 kernel: generic-usb 0003:050D:0102.0006: input,hidraw0: USB HID v1.10 Mouse [Belkin Corporation Flip KVM] on usb-0000:00:1a.7-4.2.2/input0 Nov 23 18:19:08 maliks-fedora11 kernel: input: Belkin Corporation Flip KVM as /devices/pci0000:00/0000:00:1a.7/usb1/1-4/1-4.2/1-4.2.2/1-4.2.2:1.1/input/input16 Nov 23 18:19:08 maliks-fedora11 kernel: generic-usb 0003:050D:0102.0007: input,hidraw3: USB HID v1.10 Keyboard [Belkin Corporation Flip KVM] on usb-0000:00:1a.7-4.2.2/input1 Nov 23 18:19:08 maliks-fedora11 kernel: usb 1-4.2.4: USB disconnect, address 8 Nov 23 18:19:08 maliks-fedora11 ifdhandler[1391]: usb_bulk failed: No such device Nov 23 18:19:09 maliks-fedora11 kernel: usb 1-4.2.3: USB disconnect, address 9 Nov 23 18:20:40 maliks-fedora11 NetworkManager: <info> (wlan0): supplicant connection state: completed -> group handshake Nov 23 18:20:40 maliks-fedora11 NetworkManager: <info> (wlan0): supplicant connection state: group handshake -> completed Nov 23 18:22:17 maliks-fedora11 kernel: usb 1-4.2.2: USB disconnect, address 10 Nov 23 18:22:17 maliks-fedora11 kernel: usb 1-4.2.2: new low speed USB device using ehci_hcd and address 11 Nov 23 18:22:17 maliks-fedora11 kernel: usb 1-4.2.2: New USB device found, idVendor=050d, idProduct=3201 Nov 23 18:22:17 maliks-fedora11 kernel: usb 1-4.2.2: New USB device strings: Mfr=1, Product=3, SerialNumber=0 Nov 23 18:22:17 maliks-fedora11 kernel: usb 1-4.2.2: Product: Flip CC Nov 23 18:22:17 maliks-fedora11 kernel: usb 1-4.2.2: Manufacturer: Belkin Corporation Nov 23 18:22:17 maliks-fedora11 kernel: usb 1-4.2.2: configuration #1 chosen from 1 choice Nov 23 18:22:17 maliks-fedora11 kernel: input: Belkin Corporation Flip CC as /devices/pci0000:00/0000:00:1a.7/usb1/1-4/1-4.2/1-4.2.2/1-4.2.2:1.0/input/input17 Nov 23 18:22:17 maliks-fedora11 kernel: belkin 0003:050D:3201.0008: input,hiddev96,hidraw0: USB HID v1.10 Device [Belkin Corporation Flip CC] on usb-0000:00:1a.7-4.2.2/input0 Nov 23 18:22:17 maliks-fedora11 kernel: usb 1-4.2.4: new full speed USB device using ehci_hcd and address 12 Nov 23 18:22:17 maliks-fedora11 kernel: usb 1-4.2.4: New USB device found, idVendor=03f0, idProduct=1024 Nov 23 18:22:17 maliks-fedora11 kernel: usb 1-4.2.4: New USB device strings: Mfr=1, Product=2, SerialNumber=5 Nov 23 18:22:17 maliks-fedora11 kernel: usb 1-4.2.4: Product: HP USB Smart Card Keyboard Nov 23 18:22:17 maliks-fedora11 kernel: usb 1-4.2.4: Manufacturer: Hewlett-Packard Company Nov 23 18:22:17 maliks-fedora11 kernel: usb 1-4.2.4: SerialNumber: 08172375 Nov 23 18:22:17 maliks-fedora11 kernel: usb 1-4.2.4: configuration #1 chosen from 1 choice Nov 23 18:22:17 maliks-fedora11 kernel: input: Hewlett-Packard Company HP USB Smart Card Keyboard as /devices/pci0000:00/0000:00:1a.7/usb1/1-4/1-4.2/1-4.2.4/1-4.2.4:1.0/input/input18 Nov 23 18:22:17 maliks-fedora11 kernel: generic-usb 0003:03F0:1024.0009: input,hidraw1: USB HID v1.11 Keyboard [Hewlett-Packard Company HP USB Smart Card Keyboard] on usb-0000:00:1a.7-4.2.4/input0 Nov 23 18:22:17 maliks-fedora11 udevadm[2511]: the program '/bin/bash' called 'udevinfo', it should use 'udevadm info <options>', this will stop working in a future release Nov 23 18:22:18 maliks-fedora11 kernel: usb 1-4.2.3: new low speed USB device using ehci_hcd and address 13 Nov 23 18:22:18 maliks-fedora11 kernel: usb 1-4.2.3: New USB device found, idVendor=046d, idProduct=c018 Nov 23 18:22:18 maliks-fedora11 kernel: usb 1-4.2.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0 Nov 23 18:22:18 maliks-fedora11 kernel: usb 1-4.2.3: Product: Logitech USB Optical Mouse Nov 23 18:22:18 maliks-fedora11 kernel: usb 1-4.2.3: Manufacturer: Logitech Nov 23 18:22:18 maliks-fedora11 kernel: usb 1-4.2.3: configuration #1 chosen from 1 choice Nov 23 18:22:18 maliks-fedora11 kernel: input: Logitech Logitech USB Optical Mouse as /devices/pci0000:00/0000:00:1a.7/usb1/1-4/1-4.2/1-4.2.3/1-4.2.3:1.0/input/input19 Nov 23 18:22:18 maliks-fedora11 kernel: generic-usb 0003:046D:C018.000A: input,hidraw2: USB HID v1.11 Mouse [Logitech Logitech USB Optical Mouse] on usb-0000:00:1a.7-4.2.3/input0 Nov 23 18:27:40 maliks-fedora11 NetworkManager: <info> (wlan0): supplicant connection state: completed -> group handshake Nov 23 18:27:40 maliks-fedora11 NetworkManager: <info> (wlan0): supplicant connection state: group handshake -> completed Nov 23 18:31:29 maliks-fedora11 kernel: usb 1-4.2.2: USB disconnect, address 11 Nov 23 18:31:30 maliks-fedora11 kernel: usb 1-4.2.2: new low speed USB device using ehci_hcd and address 14 Nov 23 18:31:30 maliks-fedora11 kernel: usb 1-4.2.2: New USB device found, idVendor=050d, idProduct=0102 Nov 23 18:31:30 maliks-fedora11 kernel: usb 1-4.2.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 Nov 23 18:31:30 maliks-fedora11 kernel: usb 1-4.2.2: Product: Flip KVM Nov 23 18:31:30 maliks-fedora11 kernel: usb 1-4.2.2: Manufacturer: Belkin Corporation Nov 23 18:31:30 maliks-fedora11 kernel: usb 1-4.2.2: configuration #1 chosen from 1 choice Nov 23 18:31:30 maliks-fedora11 kernel: input: Belkin Corporation Flip KVM as /devices/pci0000:00/0000:00:1a.7/usb1/1-4/1-4.2/1-4.2.2/1-4.2.2:1.0/input/input20 Nov 23 18:31:30 maliks-fedora11 kernel: generic-usb 0003:050D:0102.000B: input,hidraw0: USB HID v1.10 Mouse [Belkin Corporation Flip KVM] on usb-0000:00:1a.7-4.2.2/input0 Nov 23 18:31:30 maliks-fedora11 kernel: input: Belkin Corporation Flip KVM as /devices/pci0000:00/0000:00:1a.7/usb1/1-4/1-4.2/1-4.2.2/1-4.2.2:1.1/input/input21 Nov 23 18:31:30 maliks-fedora11 kernel: generic-usb 0003:050D:0102.000C: input,hidraw3: USB HID v1.10 Keyboard [Belkin Corporation Flip KVM] on usb-0000:00:1a.7-4.2.2/input1 Nov 23 18:31:30 maliks-fedora11 kernel: usb 1-4.2.4: USB disconnect, address 12 Nov 23 18:31:30 maliks-fedora11 ifdhandler[2521]: usb_bulk failed: No such device Nov 23 18:31:31 maliks-fedora11 kernel: usb 1-4.2.3: USB disconnect, address 13
Created attachment 373194 [details] lsusb -vvv output
I have the same problem with a USB KVM. lsusb -vvv is below: - - - - - Bus 001 Device 002: ID 0aec:3260 Neodio Technologies Corp. 7-in-1 Card Reader Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x0aec Neodio Technologies Corp. idProduct 0x3260 7-in-1 Card Reader bcdDevice 1.00 iManufacturer 1 Generic iProduct 2 USB Storage Device iSerial 3 20040411114642260 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 32 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 98mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 8 Mass Storage bInterfaceSubClass 6 SCSI bInterfaceProtocol 80 Bulk (Zip) iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Device Qualifier (for other device speed): bLength 10 bDescriptorType 6 bcdUSB 2.00 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 bNumConfigurations 1 Device Status: 0x0000 (Bus Powered) Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 9 Hub bDeviceSubClass 0 Unused bDeviceProtocol 0 Full speed (or root) hub bMaxPacketSize0 64 idVendor 0x1d6b Linux Foundation idProduct 0x0002 2.0 root hub bcdDevice 2.06 iManufacturer 3 Linux 2.6.31.5-127.fc12.i686.PAE ehci_hcd iProduct 2 EHCI Host Controller iSerial 1 0000:00:1d.7 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 25 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xe0 Self Powered Remote Wakeup MaxPower 0mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 9 Hub bInterfaceSubClass 0 Unused bInterfaceProtocol 0 Full speed (or root) hub iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0004 1x 4 bytes bInterval 12 Hub Descriptor: bLength 11 bDescriptorType 41 nNbrPorts 8 wHubCharacteristic 0x000a No power switching (usb 1.0) Per-port overcurrent protection bPwrOn2PwrGood 10 * 2 milli seconds bHubContrCurrent 0 milli Ampere DeviceRemovable 0x00 0x00 PortPwrCtrlMask 0xff 0xff Hub Port Status: Port 1: 0000.0100 power Port 2: 0000.0100 power Port 3: 0000.0100 power Port 4: 0000.0503 highspeed power enable connect Port 5: 0000.0100 power Port 6: 0000.0100 power Port 7: 0000.0100 power Port 8: 0000.0100 power Device Status: 0x0003 Self Powered Remote Wakeup Enabled Bus 005 Device 004: ID 04b4:120f Cypress Semiconductor Corp. Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x04b4 Cypress Semiconductor Corp. idProduct 0x120f bcdDevice 1.00 iManufacturer 1 Cypress Semiconductor, Inc. iProduct 2 enCoReII Mouse RDK iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 34 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xa0 (Bus Powered) Remote Wakeup MaxPower 50mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 3 Human Interface Device bInterfaceSubClass 1 Boot Interface Subclass bInterfaceProtocol 2 Mouse iInterface 0 HID Device Descriptor: bLength 9 bDescriptorType 33 bcdHID 1.11 bCountryCode 33 US bNumDescriptors 1 bDescriptorType 34 Report wDescriptorLength 52 Report Descriptors: ** UNAVAILABLE ** Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0004 1x 4 bytes bInterval 10 Device Status: 0x0000 (Bus Powered) Bus 005 Device 003: ID 0d62:2106 Darfon Electronics Corp. Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x0d62 Darfon Electronics Corp. idProduct 0x2106 bcdDevice 4.50 iManufacturer 0 iProduct 1 USB Multimedia Keyboard iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 59 bNumInterfaces 2 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xa0 (Bus Powered) Remote Wakeup MaxPower 70mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 3 Human Interface Device bInterfaceSubClass 1 Boot Interface Subclass bInterfaceProtocol 1 Keyboard iInterface 0 HID Device Descriptor: bLength 9 bDescriptorType 33 bcdHID 1.10 bCountryCode 0 Not supported bNumDescriptors 1 bDescriptorType 34 Report wDescriptorLength 65 Report Descriptors: ** UNAVAILABLE ** Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0008 1x 8 bytes bInterval 10 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 3 Human Interface Device bInterfaceSubClass 0 No Subclass bInterfaceProtocol 0 None iInterface 0 HID Device Descriptor: bLength 9 bDescriptorType 33 bcdHID 1.10 bCountryCode 0 Not supported bNumDescriptors 1 bDescriptorType 34 Report wDescriptorLength 68 Report Descriptors: ** UNAVAILABLE ** Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0008 1x 8 bytes bInterval 10 Device Status: 0x0000 (Bus Powered) Bus 005 Device 002: ID 058f:9254 Alcor Micro Corp. Hub Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass 9 Hub bDeviceSubClass 0 Unused bDeviceProtocol 0 Full speed (or root) hub bMaxPacketSize0 8 idVendor 0x058f Alcor Micro Corp. idProduct 0x9254 Hub bcdDevice 3.12 iManufacturer 1 ALCOR iProduct 2 Generic USB Hub iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 25 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xe0 Self Powered Remote Wakeup MaxPower 100mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 9 Hub bInterfaceSubClass 0 Unused bInterfaceProtocol 0 Full speed (or root) hub iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0001 1x 1 bytes bInterval 255 Hub Descriptor: bLength 9 bDescriptorType 41 nNbrPorts 4 wHubCharacteristic 0x0009 Per-port power switching Per-port overcurrent protection bPwrOn2PwrGood 22 * 2 milli seconds bHubContrCurrent 100 milli Ampere DeviceRemovable 0x00 PortPwrCtrlMask 0xff Hub Port Status: Port 1: 0000.0303 lowspeed power enable connect Port 2: 0000.0303 lowspeed power enable connect Port 3: 0000.0100 power Port 4: 0000.0100 power Device Status: 0x0001 Self Powered Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass 9 Hub bDeviceSubClass 0 Unused bDeviceProtocol 0 Full speed (or root) hub bMaxPacketSize0 64 idVendor 0x1d6b Linux Foundation idProduct 0x0001 1.1 root hub bcdDevice 2.06 iManufacturer 3 Linux 2.6.31.5-127.fc12.i686.PAE uhci_hcd iProduct 2 UHCI Host Controller iSerial 1 0000:00:1d.3 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 25 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xe0 Self Powered Remote Wakeup MaxPower 0mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 9 Hub bInterfaceSubClass 0 Unused bInterfaceProtocol 0 Full speed (or root) hub iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0002 1x 2 bytes bInterval 255 Hub Descriptor: bLength 9 bDescriptorType 41 nNbrPorts 2 wHubCharacteristic 0x000a No power switching (usb 1.0) Per-port overcurrent protection bPwrOn2PwrGood 1 * 2 milli seconds bHubContrCurrent 0 milli Ampere DeviceRemovable 0x00 PortPwrCtrlMask 0xff Hub Port Status: Port 1: 0000.0103 power enable connect Port 2: 0000.0100 power Device Status: 0x0003 Self Powered Remote Wakeup Enabled Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass 9 Hub bDeviceSubClass 0 Unused bDeviceProtocol 0 Full speed (or root) hub bMaxPacketSize0 64 idVendor 0x1d6b Linux Foundation idProduct 0x0001 1.1 root hub bcdDevice 2.06 iManufacturer 3 Linux 2.6.31.5-127.fc12.i686.PAE uhci_hcd iProduct 2 UHCI Host Controller iSerial 1 0000:00:1d.2 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 25 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xe0 Self Powered Remote Wakeup MaxPower 0mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 9 Hub bInterfaceSubClass 0 Unused bInterfaceProtocol 0 Full speed (or root) hub iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0002 1x 2 bytes bInterval 255 Hub Descriptor: bLength 9 bDescriptorType 41 nNbrPorts 2 wHubCharacteristic 0x000a No power switching (usb 1.0) Per-port overcurrent protection bPwrOn2PwrGood 1 * 2 milli seconds bHubContrCurrent 0 milli Ampere DeviceRemovable 0x00 PortPwrCtrlMask 0xff Hub Port Status: Port 1: 0000.0100 power Port 2: 0000.0100 power Device Status: 0x0003 Self Powered Remote Wakeup Enabled Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass 9 Hub bDeviceSubClass 0 Unused bDeviceProtocol 0 Full speed (or root) hub bMaxPacketSize0 64 idVendor 0x1d6b Linux Foundation idProduct 0x0001 1.1 root hub bcdDevice 2.06 iManufacturer 3 Linux 2.6.31.5-127.fc12.i686.PAE uhci_hcd iProduct 2 UHCI Host Controller iSerial 1 0000:00:1d.1 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 25 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xe0 Self Powered Remote Wakeup MaxPower 0mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 9 Hub bInterfaceSubClass 0 Unused bInterfaceProtocol 0 Full speed (or root) hub iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0002 1x 2 bytes bInterval 255 Hub Descriptor: bLength 9 bDescriptorType 41 nNbrPorts 2 wHubCharacteristic 0x000a No power switching (usb 1.0) Per-port overcurrent protection bPwrOn2PwrGood 1 * 2 milli seconds bHubContrCurrent 0 milli Ampere DeviceRemovable 0x00 PortPwrCtrlMask 0xff Hub Port Status: Port 1: 0000.0100 power Port 2: 0000.0100 power Device Status: 0x0003 Self Powered Remote Wakeup Enabled Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass 9 Hub bDeviceSubClass 0 Unused bDeviceProtocol 0 Full speed (or root) hub bMaxPacketSize0 64 idVendor 0x1d6b Linux Foundation idProduct 0x0001 1.1 root hub bcdDevice 2.06 iManufacturer 3 Linux 2.6.31.5-127.fc12.i686.PAE uhci_hcd iProduct 2 UHCI Host Controller iSerial 1 0000:00:1d.0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 25 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xe0 Self Powered Remote Wakeup MaxPower 0mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 9 Hub bInterfaceSubClass 0 Unused bInterfaceProtocol 0 Full speed (or root) hub iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0002 1x 2 bytes bInterval 255 Hub Descriptor: bLength 9 bDescriptorType 41 nNbrPorts 2 wHubCharacteristic 0x000a No power switching (usb 1.0) Per-port overcurrent protection bPwrOn2PwrGood 1 * 2 milli seconds bHubContrCurrent 0 milli Ampere DeviceRemovable 0x00 PortPwrCtrlMask 0xff Hub Port Status: Port 1: 0000.0100 power Port 2: 0000.0100 power Device Status: 0x0003 Self Powered Remote Wakeup Enabled
I'll need to know what's going on when the box hangs. The best way is to setup the netconsole. Can you do it, or do you need detailed instructions? Another option is to find an extra monitor, and see if the problem reproduces with just the input side. If the monitor remains attached (directly), it might show something that can be captured with a camera. However, netconsole is better, because it can capture more than monitor's size (I expect a traceback actually).
I already have dual monitor and I have tested this thing out. It is not just the input which gets hang. The PC stops working completely. I tested that with running a dummy counting script on my 2nd monitor and than reproduced the issue using the steps mentioned earlier. I could see the my script running in the terminal window on the 2nd monitor hangs as soon as the problem is reproduced. As for the netconsole, I haven't done that before. If you could refer me to a how-to, I'll set that up for you. thanks.
Please do the same in text mode (switch with Alt-Ctrl-F1): - connect other monitor - Ctrl-Alt-F1 - Flip the KVM Please let me know if anything crops up on the text console. Also, do you have an extra keyboard?
Oh OK. I got confused with the terminology. Tried to reproduce again and found a new behavior. If I switch my KVM 2 - 3 times while on netconsole, nothing happens. I tried upto 10 times and my PC didn't hang at all. I switched to X (Alt+F7) and it hung on the second try. I believe what we see on netconsole is more or less same as /var/log/messages? I had my var/log/messages open with tail -f to check the behavior. I could not found any error message while the PC goes into this unresponsive state. I did capture the screen using my camera and attached to this ticket. I restarted my machine and tried to reproduce again and then I started seeing a new issue. Every time I switch machines using KVM, after 3 - 4 tries, my X dies and takes me back to gdm login screen. That is something I never noticed before. I reproduced it 5 times in a row. I have updated my kernel yesterday though but not sure if that has anything to do with this change of behavior. Kernel:2.6.31.6-162.fc12.i686.PAE I have also captured this X dying incident in the text file and attached to this ticket. Let me know if this helps you find a clue about what might be causing this. thank you.
Created attachment 376975 [details] screenshot of var_log_messages while PC hung
Created attachment 376976 [details] X died while switching KVM 3 times
I am seeing the same problem with the same Belkin USB KVM. I am running a dual head Fedora 12 system and switching just one of the monitors with the KVM between two machines. When switching away from the Fedora 12 machine I sometimes see on the 2nd head that the F12 machine gets logged out (back to the gdm login screen) - I can switch back and log in again. Other times X will hang completely on the F12 machine (running applications on the 2nd head just freeze). In this state however I can still ssh in from another machine. I am running kernel 2.6.31.6-162.fc12.x86_64 I have a Microsoft 6000 Wireless Keyboard & Mouse attached to the KVM. Let me know if there are any logs you require - I am more than willing to help with this one.
I'm experiencing the same problem and opened a bug for this quite a while ago https://bugzilla.redhat.com/show_bug.cgi?id=531039 Seems like xorg is crashing, you should still be able to ssh into your box after xorg froze and check the logs.
I've been seeing this problem for a while too. My KVM switch is a Zonet KVM3324W (4-port) and I'm using a Microsoft 3000 wireless keyboard and mouse attached to the KVM switch. I have a F11 box on the KVM switch too, and when an F12 freezes up I use it to ssh into the F12 box and restart the X server.
Exact same issue here - Belkin Flip 2 port USB KVM, connected to a winXP machine (on its own monitor) and a fedora 12 Dual Head machine (on its own two monitors - I only use the KVM to share keyboard and mouse). My fedora is currently hung, I have been ssh-ing in and killing Xorg to get the system responding again. Checked my /var/log/messages just there, and there doesn't seem to be any errors (press the button to connect at 11:16:02, check Xorg is hung, press again at 11:16:21 to return to WinXP): Dec 15 11:16:01 localhost kernel: usb 1-4.2: USB disconnect, address 47 Dec 15 11:16:01 localhost kernel: usb 1-4.2: new low speed USB device using ehci_hcd and address 48 Dec 15 11:16:01 localhost kernel: usb 1-4.2: New USB device found, idVendor=050d, idProduct=3201 Dec 15 11:16:01 localhost kernel: usb 1-4.2: New USB device strings: Mfr=1, Product=3, SerialNumber=0 Dec 15 11:16:01 localhost kernel: usb 1-4.2: Product: Flip CC Dec 15 11:16:01 localhost kernel: usb 1-4.2: Manufacturer: Belkin Corporation Dec 15 11:16:01 localhost kernel: usb 1-4.2: configuration #1 chosen from 1 choice Dec 15 11:16:01 localhost kernel: input: Belkin Corporation Flip CC as /devices/pci0000:00/0000:00:1d.7/usb1/1-4/1-4.2/1-4.2:1.0/input/input71 Dec 15 11:16:01 localhost kernel: belkin 0003:050D:3201.0045: input,hiddev96,hidraw0: USB HID v1.10 Device [Belkin Corporation Flip CC] on usb-0000:00:1d.7-4.2/input0 Dec 15 11:16:01 localhost kernel: usb 1-4.4: new low speed USB device using ehci_hcd and address 49 Dec 15 11:16:01 localhost kernel: usb 1-4.4: New USB device found, idVendor=04d9, idProduct=1603 Dec 15 11:16:01 localhost kernel: usb 1-4.4: New USB device strings: Mfr=1, Product=2, SerialNumber=0 Dec 15 11:16:01 localhost kernel: usb 1-4.4: Product: USB Keyboard Dec 15 11:16:01 localhost kernel: usb 1-4.4: Manufacturer: Dec 15 11:16:01 localhost kernel: usb 1-4.4: configuration #1 chosen from 1 choice Dec 15 11:16:01 localhost kernel: input: USB Keyboard as /devices/pci0000:00/0000:00:1d.7/usb1/1-4/1-4.4/1-4.4:1.0/input/input72 Dec 15 11:16:01 localhost kernel: generic-usb 0003:04D9:1603.0046: input,hidraw1: USB HID v1.10 Keyboard [ USB Keyboard] on usb-0000:00:1d.7-4.4/input0 Dec 15 11:16:01 localhost kernel: input: USB Keyboard as /devices/pci0000:00/0000:00:1d.7/usb1/1-4/1-4.4/1-4.4:1.1/input/input73 Dec 15 11:16:01 localhost kernel: generic-usb 0003:04D9:1603.0047: input,hidraw2: USB HID v1.10 Device [ USB Keyboard] on usb-0000:00:1d.7-4.4/input1 Dec 15 11:16:02 localhost kernel: usb 1-4.3: new low speed USB device using ehci_hcd and address 50 Dec 15 11:16:02 localhost kernel: usb 1-4.3: New USB device found, idVendor=1bcf, idProduct=0007 Dec 15 11:16:02 localhost kernel: usb 1-4.3: New USB device strings: Mfr=0, Product=2, SerialNumber=0 Dec 15 11:16:02 localhost kernel: usb 1-4.3: Product: USB Optical Mouse Dec 15 11:16:02 localhost kernel: usb 1-4.3: configuration #1 chosen from 1 choice Dec 15 11:16:02 localhost kernel: input: USB Optical Mouse as /devices/pci0000:00/0000:00:1d.7/usb1/1-4/1-4.3/1-4.3:1.0/input/input74 Dec 15 11:16:02 localhost kernel: generic-usb 0003:1BCF:0007.0048: input,hiddev97,hidraw3: USB HID v1.10 Mouse [USB Optical Mouse] on usb-0000:00:1d.7-4.3/input0 Dec 15 11:16:21 localhost kernel: usb 1-4.2: USB disconnect, address 48 Dec 15 11:16:21 localhost kernel: usb 1-4.2: new low speed USB device using ehci_hcd and address 51 Dec 15 11:16:21 localhost kernel: usb 1-4.2: New USB device found, idVendor=050d, idProduct=0102 Dec 15 11:16:21 localhost kernel: usb 1-4.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 Dec 15 11:16:21 localhost kernel: usb 1-4.2: Product: Flip KVM Dec 15 11:16:21 localhost kernel: usb 1-4.2: Manufacturer: Belkin Corporation Dec 15 11:16:21 localhost kernel: usb 1-4.2: configuration #1 chosen from 1 choice Dec 15 11:16:21 localhost kernel: input: Belkin Corporation Flip KVM as /devices/pci0000:00/0000:00:1d.7/usb1/1-4/1-4.2/1-4.2:1.0/input/input75 Dec 15 11:16:21 localhost kernel: generic-usb 0003:050D:0102.0049: input,hidraw0: USB HID v1.10 Mouse [Belkin Corporation Flip KVM] on usb-0000:00:1d.7-4.2/input0 Dec 15 11:16:21 localhost kernel: input: Belkin Corporation Flip KVM as /devices/pci0000:00/0000:00:1d.7/usb1/1-4/1-4.2/1-4.2:1.1/input/input76 Dec 15 11:16:21 localhost kernel: generic-usb 0003:050D:0102.004A: input,hidraw4: USB HID v1.10 Keyboard [Belkin Corporation Flip KVM] on usb-0000:00:1d.7-4.2/input1 Dec 15 11:16:21 localhost kernel: usb 1-4.4: USB disconnect, address 49 Dec 15 11:16:22 localhost kernel: usb 1-4.3: USB disconnect, address 50 Other than Xorg crashing, the system is fine - but I'm unaware of a way to restore connection other than killing and restarting Xorg... The Xorg.0.log stops at the time of the crash. I'm gonna try and do some tests today with extra logging in Xorg (if such a thing exists) to see If i can find an error anywhere....
Heyho, Finally got a proper error message in one of my logs. I removed the nvidia driver and let X configure itself (it chose VESA) to ensure the problem still exists (which it does). I also found the reproduction to be a bit iffy - I found if i switch back and forth quickly between the two systems on the KVM, it works fine, but If I work on the WinXP machine for a few mins, and then switch back, Xorg crashes. Heres the combined realtime tails on /messages and Xorg.0.log (with some comments by me): # COMMENT: Xorg had been running for a while, while I tried unsucessfully to reproduce a crash by switching back and forth every 5-10 seconds.... Switched to WinXP at 12:19:57 ==> messages <== Dec 15 12:19:57 localhost kernel: usb 1-4.3: USB disconnect, address 45 ==> Xorg.0.log <== (II) config/hal: removing device USB Optical Mouse (II) USB Optical Mouse: Close (II) UnloadModule: "evdev" (II) config/hal: removing device Belkin Corporation Flip KVM (II) Belkin Corporation Flip KVM: Close (II) UnloadModule: "evdev" # COMMENT: switched back to Fedora 12 at 12:21 ==> messages <== Dec 15 12:21:06 localhost kernel: usb 1-4.2: USB disconnect, address 46 ==> Xorg.0.log <== (II) config/hal: removing device Belkin Corporation Flip KVM (II) Belkin Corporation Flip KVM: Close (II) UnloadModule: "evdev" ==> messages <== Dec 15 12:21:07 localhost kernel: usb 1-4.2: new low speed USB device using ehci_hcd and address 47 Dec 15 12:21:07 localhost kernel: usb 1-4.2: New USB device found, idVendor=050d, idProduct=3201 Dec 15 12:21:07 localhost kernel: usb 1-4.2: New USB device strings: Mfr=1, Product=3, SerialNumber=0 Dec 15 12:21:07 localhost kernel: usb 1-4.2: Product: Flip CC Dec 15 12:21:07 localhost kernel: usb 1-4.2: Manufacturer: Belkin Corporation Dec 15 12:21:07 localhost kernel: usb 1-4.2: configuration #1 chosen from 1 choice Dec 15 12:21:07 localhost kernel: input: Belkin Corporation Flip CC as /devices/pci0000:00/0000:00:1d.7/usb1/1-4/1-4.2/1-4.2:1.0/input/input69 Dec 15 12:21:07 localhost kernel: belkin 0003:050D:3201.0043: input,hiddev96,hidraw0: USB HID v1.10 Device [Belkin Corporation Flip CC] on usb-0000:00:1d.7-4.2/input0 ==> Xorg.0.log <== (II) config/hal: Adding input device Belkin Corporation Flip CC (**) Belkin Corporation Flip CC: always reports core events (**) Belkin Corporation Flip CC: Device: "/dev/input/event3" (II) Belkin Corporation Flip CC: Found keys (II) Belkin Corporation Flip CC: Configuring as keyboard (II) XINPUT: Adding extended input device "Belkin Corporation Flip CC" (type: KEYBOARD) (**) Option "xkb_rules" "evdev" (**) Option "xkb_model" "evdev" (**) Option "xkb_layout" "us" Backtrace: 0: /usr/bin/Xorg (xorg_backtrace+0x3c) [0x80e587c] 1: /usr/bin/Xorg (0x8047000+0x5fb66) [0x80a6b66] 2: (vdso) (__kernel_rt_sigreturn+0x0) [0xa9140c] 3: /lib/libc.so.6 (0x148000+0x70ebd) [0x1b8ebd] 4: /lib/libc.so.6 (__libc_malloc+0x5e) [0x1ba1fe] 5: /usr/bin/Xorg (Xalloc+0x2a) [0x80a770a] 6: /usr/bin/Xorg (0x8047000+0xedb06) [0x8134b06] 7: /usr/bin/Xorg (0x8047000+0xee40b) [0x813540b] 8: /usr/bin/Xorg (0x8047000+0x271f7) [0x806e1f7] 9: /usr/bin/Xorg (0x8047000+0x1b8c5) [0x80628c5] 10: /lib/libc.so.6 (__libc_start_main+0xe6) [0x15ebb6] 11: /usr/bin/Xorg (0x8047000+0x1b4b1) [0x80624b1] Segmentation fault at address 0x4000088 Fatal server error: Caught signal 11 (Segmentation fault). Server aborting Please consult the The X.Org Foundation support at http://bodhi.fedoraproject.org/ for help. Please also check the log file at "/var/log/Xorg.0.log" for additional information. # system sees USB device connections, but Xorg is already dead.... ==> messages <== Dec 15 12:21:07 localhost kernel: usb 1-4.4: new low speed USB device using ehci_hcd and address 48 Dec 15 12:21:07 localhost kernel: usb 1-4.4: New USB device found, idVendor=04d9, idProduct=1603 Dec 15 12:21:07 localhost kernel: usb 1-4.4: New USB device strings: Mfr=1, Product=2, SerialNumber=0 Dec 15 12:21:07 localhost kernel: usb 1-4.4: Product: USB Keyboard Dec 15 12:21:07 localhost kernel: usb 1-4.4: Manufacturer: Dec 15 12:21:07 localhost kernel: usb 1-4.4: configuration #1 chosen from 1 choice Dec 15 12:21:07 localhost kernel: input: USB Keyboard as /devices/pci0000:00/0000:00:1d.7/usb1/1-4/1-4.4/1-4.4:1.0/input/input70 Dec 15 12:21:07 localhost kernel: generic-usb 0003:04D9:1603.0044: input,hidraw1: USB HID v1.10 Keyboard [ USB Keyboard] on usb-0000:00:1d.7-4.4/input0 Dec 15 12:21:07 localhost kernel: input: USB Keyboard as /devices/pci0000:00/0000:00:1d.7/usb1/1-4/1-4.4/1-4.4:1.1/input/input71 Dec 15 12:21:07 localhost kernel: generic-usb 0003:04D9:1603.0045: input,hidraw2: USB HID v1.10 Device [ USB Keyboard] on usb-0000:00:1d.7-4.4/input1 Dec 15 12:21:08 localhost kernel: usb 1-4.3: new low speed USB device using ehci_hcd and address 49 Dec 15 12:21:08 localhost kernel: usb 1-4.3: New USB device found, idVendor=1bcf, idProduct=0007 Dec 15 12:21:08 localhost kernel: usb 1-4.3: New USB device strings: Mfr=0, Product=2, SerialNumber=0 Dec 15 12:21:08 localhost kernel: usb 1-4.3: Product: USB Optical Mouse Dec 15 12:21:08 localhost kernel: usb 1-4.3: configuration #1 chosen from 1 choice Dec 15 12:21:08 localhost kernel: input: USB Optical Mouse as /devices/pci0000:00/0000:00:1d.7/usb1/1-4/1-4.3/1-4.3:1.0/input/input72 Dec 15 12:21:08 localhost kernel: generic-usb 0003:1BCF:0007.0046: input,hiddev97,hidraw3: USB HID v1.10 Mouse [USB Optical Mouse] on usb-0000:00:1d.7-4.3/input0 If its any help, heres my Xorg.conf
Created attachment 378496 [details] Abrtd saved files from Xorg Crash caused by this issue
Issue reproduceable with nvidia, nv, nouveau and vesa drivers. I attached the files that abrtd created last time it crashed. Interestingly, when the issue happens with the nouveau driver loaded, Xorg automatically restarts (no ssh from another box and Xorg kill required) === xorg.conf === Section "Files" ModulePath "/usr/lib/xorg/modules" EndSection Section "ServerFlags" Option "AIGLX" "on" EndSection Section "Device" Identifier "Videocard0" Driver "nouveau" EndSection Section "Extensions" Option "Composite" "Enable" EndSection
FWIW; I'm using radeon driver and I can confirm that if I reproduce the problem 10 times, 4 times it hangs my X and rest of the times it simply crashes. So, I'm seeing both symptoms with my driver. This is my exact video card: PCI:*(0:1:0:0) 1002:7188:103c:30c1 ATI Technologies Inc M64-S [Mobility Radeon X2300]
I'm reassigning the component to Xorg, so that Matej Cepl and Peter Hutterer can have a look at the problem. I remain on cc: and will pick up any fallout to kernel right away.
For what it's worth, this isn't specific to Belkin KVMs, and the crash is not always immediate. Just now, I had enough time to read a bunch of email and check up on some irc channels before X finally crashed.
Also, this and bug 531039 are dups of each other.
(In reply to comment #19) > Also, this and bug 531039 are dups of each other. Sure backtrace in comment 13 here and in bug 531039 comment 3 looks similar, both of them have something to do with memory allocation, but not sure they are identical. Rather leave it open.
Bug 531039 comment 3 is unrelated, this is the backtrace generated when the server is hung and doesn't process input events. The original comment in that bug looks the same though. 0: /usr/bin/Xorg (xorg_backtrace+0x3c) [0x80e587c] 1: /usr/bin/Xorg (0x8047000+0x5fb66) [0x80a6b66] 2: (vdso) (__kernel_rt_sigreturn+0x0) [0xa9140c] 3: /lib/libc.so.6 (0x148000+0x70ebd) [0x1b8ebd] 4: /lib/libc.so.6 (__libc_malloc+0x5e) [0x1ba1fe] 5: /usr/bin/Xorg (Xalloc+0x2a) [0x80a770a] 6: /usr/bin/Xorg (0x8047000+0xedb06) [0x8134b06] 7: /usr/bin/Xorg (0x8047000+0xee40b) [0x813540b] 8: /usr/bin/Xorg (0x8047000+0x271f7) [0x806e1f7] 9: /usr/bin/Xorg (0x8047000+0x1b8c5) [0x80628c5] 10: /lib/libc.so.6 (__libc_start_main+0xe6) [0x15ebb6] 11: /usr/bin/Xorg (0x8047000+0x1b4b1) [0x80624b1] 0x8134b06 is xkb/xkb.c:2999, XkbSendIndicatorMap, the first malloc call. The length field is calculated in a sensible manner and cannot really be an invalid value. Which indicates some other corruption happening. If this is reproducible, can you run X through valgrind and check for any outputs there?
(In reply to comment #21) > If this is reproducible, can you run X through valgrind and check for any > outputs there? Sure. Got instructions that show the best way to go about it?
yum install valgrind xterm init 3 echo "valgrind /usr/bin/Xorg" > $HOME/.xserverrc chmod -s /usr/bin/Xorg # valgrind doesn't like suid xinit -- This will start up X through valgrind and an xterm. Once you exit the xterm, the server terminates as well. Meanwhile, just do whatever you do to reproduce the issue. You might want to run the whole lot inside screen so you can reattach from another computer if the machine hangs and look at the log. Also note that valgrind slows down X by _a lot_, so it might appear hanging but it's still doing stuff in the background.
Created attachment 379590 [details] Valgrind output from Xorg crash
(In reply to comment #18) > For what it's worth, this isn't specific to Belkin KVMs, and the crash is not > always immediate. Just now, I had enough time to read a bunch of email and > check up on some irc channels before X finally crashed. It's always immediate in my case. When I switch over, the system is unresponsive. I can ssh into the computer and kill the X server and it returns to life. It doesn't always happen every second time. But I've noticed if I'm actively doing stuff it's fine. If I work on the other computer for an extended amount of time, say and hour or so, and then switch back it dies every time. It's almost like some sort of power management is kicking in and when it tries to start back up it dies.
Ubuntu derivatives also have the same problem but the behavior seems to be related to some power management bug. In Fedora, it is always every 2nd (or 3rd) attempt for me, no matter how fast or slow I switch between PCs. I have also seen this slow dying behavior as explained by Daniel but it is not as consistent as the immediate crash. Strange thing is, when I follow the instructions from Peter, my X doesn't crash. I'll post the output if I manage to reproduce the symptoms with Valgrind. Without Valgrind, it is very reliably reproduced.
Created attachment 381862 [details] X server configuration file
I seemed to have fixed this problem by editing my /etc/X11/xorg.conf file. I'm using a Belkin SOHO DVI KVM Switch, and I'm running Fedora 12 on both machines, so it was very easy to get one or the other locked up switching back and forth. My /var/log/Xorg.0.log file reports that I have a Microsoft Natural® Ergonomic Keyboard 4000 and a Logitech Optical USB Mouse. My keyboard has a Zoom lever in the center, and this or something else is showing up as a second mouse with one button and a scroll wheel. Fedora 12 doesn't come with a xorg.conf file, so I created one in runlevel 3 with Xorg -configure, and copied it to the default directory. The file it created had entries for Keyboard0 and Mouse0, but not the other "mouse" attached to the keyboard, so I had to add an entry for Mouse1. I changed the Driver for all three input devices to be evdev instead of kbd and mouse, and I added an Option "ReopenAttempts" "0". Apparently the default is 10, but setting this to zero for me seems to instruct the X server to attempt to reopen the devices indefinitely. Now, when I switch over after a long time, my Xorg.0.log file reports: (II) Keyboard0: Device reopened after 1139 attempts. (II) Mouse1: Device reopened after 1139 attempts. I used to get frozen screens or crashes all the time, and I haven't seen the problem repeat yet, after switching maybe 50 times over the last couple of hours. So, I'm submitting this configuration file fix for anyone interested. This is definitely a bug in X but this is a workaround until they get around to fixing it. The lines that I had to add to the configuration file are shown below in a diff between the Xorg -configure file and the one I edited, and below the diff output is a long listing of my /dev/input directory, from which I verified which event* device node corresponded to my mouse, keyboard, and "keyboard mouse". I've attached my xorg.conf file as well in the previous comment. ---- $ diff -U 4 -Naur xorg.conf.new /etc/X11/xorg.conf --- xorg.conf.new 2010-01-05 14:37:46.739496695 -0500 +++ /etc/X11/xorg.conf 2010-01-05 15:44:13.345433907 -0500 @@ -1,8 +1,9 @@ Section "ServerLayout" Identifier "X.org Configured" Screen 0 "Screen0" 0 0 InputDevice "Mouse0" "CorePointer" + InputDevice "Mouse1" "SendCoreEvents" InputDevice "Keyboard0" "CoreKeyboard" EndSection Section "Files" @@ -21,19 +22,32 @@ EndSection Section "InputDevice" Identifier "Keyboard0" - Driver "kbd" + #Driver "kbd" + Driver "evdev" + Option "ReopenAttempts" "0" + Option "Device" "/dev/input/event4" EndSection Section "InputDevice" Identifier "Mouse0" - Driver "mouse" + #Driver "mouse" + Driver "evdev" + Option "ReopenAttempts" "0" Option "Protocol" "auto" - Option "Device" "/dev/input/mice" + #Option "Device" "/dev/input/mice" + Option "Device" "/dev/input/event3" Option "ZAxisMapping" "4 5 6 7" EndSection +Section "InputDevice" + Identifier "Mouse1" + Driver "evdev" + Option "ReopenAttempts" "0" + Option "Device" "/dev/input/event5" +EndSection + Section "Monitor" #DisplaySize 380 310 # mm Identifier "Monitor0" VendorName "DEL" ---- $ ls -l /dev/input/* crw-r-----. 1 root root 13, 64 2010-01-05 09:55 /dev/input/event0 crw-r-----. 1 root root 13, 65 2010-01-05 09:55 /dev/input/event1 crw-r-----. 1 root root 13, 66 2010-01-05 09:55 /dev/input/event2 crw-r-----. 1 root root 13, 67 2010-01-05 16:58 /dev/input/event3 crw-r-----. 1 root root 13, 68 2010-01-05 16:58 /dev/input/event4 crw-r-----. 1 root root 13, 69 2010-01-05 16:58 /dev/input/event5 crw-r-----. 1 root root 13, 63 2010-01-05 09:55 /dev/input/mice crw-r-----. 1 root root 13, 32 2010-01-05 09:55 /dev/input/mouse0 crw-r-----. 1 root root 13, 33 2010-01-05 16:58 /dev/input/mouse1 crw-r-----. 1 root root 10, 223 2010-01-05 14:55 /dev/input/uinput /dev/input/by-id: total 0 lrwxrwxrwx. 1 root root 9 2010-01-05 16:58 usb-Logitech_Optical_USB_Mouse-event-mouse -> ../event3 lrwxrwxrwx. 1 root root 9 2010-01-05 16:58 usb-Logitech_Optical_USB_Mouse-mouse -> ../mouse1 lrwxrwxrwx. 1 root root 9 2010-01-05 16:58 usb-Microsoft_Natural®_Ergonomic_Keyboard_4000-event-if01 -> ../event5 lrwxrwxrwx. 1 root root 9 2010-01-05 16:58 usb-Microsoft_Natural®_Ergonomic_Keyboard_4000-event-kbd -> ../event4 /dev/input/by-path: total 0 lrwxrwxrwx. 1 root root 9 2010-01-05 16:58 pci-0000:00:1d.7-usb-0:3.1.1:1.0-event-mouse -> ../event3 lrwxrwxrwx. 1 root root 9 2010-01-05 16:58 pci-0000:00:1d.7-usb-0:3.1.1:1.0-mouse -> ../mouse1 lrwxrwxrwx. 1 root root 9 2010-01-05 16:58 pci-0000:00:1d.7-usb-0:3.1.2:1.0-event-kbd -> ../event4 lrwxrwxrwx. 1 root root 9 2010-01-05 16:58 pci-0000:00:1d.7-usb-0:3.1.2:1.1-event -> ../event5
I want to add that this has been working fine for me all day today too, with one caveat. It seems like for this workaround, a requirement is that the KVM switch be switched over to the workstation when it is starting the X server. For instance, I powered up both of my machines simultaneously today, and so only one of them had a keyboard and mouse when the X server started. That one worked fine, but the other one crashed. I rebooted that other one, but this time with the KVM switch connecting a keyboard and mouse, and now I haven't had a problem with either all day long with many KVM switches. So, it seems like you have to boot one system at a time, with the KVM switched to the workstation that is booting.
I can confirm that with the workaround provided by Aaron, my system has been stable for a day now as well (I have not rebooted it, so I cannot comment whether I have the same issues regarding booting) - Thanks Aaron.
No problem. Actually, I was going to discontinue using Fedora 12 until someone else fixed it, because I didn't want to dig into the X source and waste too much time. Someone else mentioned they saw it in Fedora 10, but I haven't seen it until now, and I install all new versions of Fedora. I actually got really lucky finding this workaround, because my thought was that it was these attempts to reopen the devices that was causing the crash, so I tried to explicitly disable the reopen by using a zero value. Seeing that the zero value caused the server to reopen indefinitely was unexpected and the opposite of what I intended, as was the resulting stability from continually trying to reopen. Maybe this can be a clue to someone who might be working on the real problem if they don't have it solved by now.
xorg-x11-drv-evdev-2.3.2-3.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/xorg-x11-drv-evdev-2.3.2-3.fc12
(In reply to comment #28) > [...] I changed the Driver for all three input devices to be evdev > instead of kbd and mouse, and I added an Option "ReopenAttempts" "0". > Apparently the default is 10, but setting this to zero for me seems to instruct > the X server to attempt to reopen the devices indefinitely. This was caused by a bad if condition in the evdev driver - fixed in 2.3.2-3 http://koji.fedoraproject.org/koji/taskinfo?taskID=1908637 The other issue might be fixed by an upstream patch in the way how XKB data is freed on device removal. It's part of 1.7.4. I'll push that out in a tick, please give it a try.
xorg-x11-server-1.7.4-1.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/xorg-x11-server-1.7.4-1.fc12
I removed the following packages: $ rpm -q xorg-x11-server-Xorg xorg-x11-server-common xorg-x11-drv-evdev xorg-x11-server-Xorg-1.7.1-7.fc12.i686 xorg-x11-server-common-1.7.1-7.fc12.i686 xorg-x11-drv-evdev-2.3.2-2.fc12.i686 Then I installed the following packages from your links: $ rpm -q xorg-x11-server-Xorg xorg-x11-server-common xorg-x11-drv-evdev xorg-x11-server-Xorg-1.7.4-1.fc12.i686 xorg-x11-server-common-1.7.4-1.fc12.i686 xorg-x11-drv-evdev-2.3.2-3.fc12.i686 This only disabled the workaround that was working for me before hand. I tried the new RPMs both with my modified xorg.conf file, and without a X configuration file, and both failed. The X server crashes and restarts with only a few KVM switches...not nice if you've become accustomed to working with a KVM switch. Now I've gone back to the original binary RPMs and am still using my workaround with good success. I wanted to ask, is there is a yum .repo file that I can put in /etc/yum.repos.d/ in order to pull updates from http://admin.fedoraproject.org/updates ? I just downloaded the packages individually, which wasn't too much work.
xorg-x11-server-1.7.4-1.fc12 has been pushed to the Fedora 12 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-server'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F12/FEDORA-2010-0317
(In reply to comment #35) > I wanted to ask, is there is a yum .repo file that I can put in > /etc/yum.repos.d/ in order to pull updates from > http://admin.fedoraproject.org/updates ? I just downloaded the packages > individually, which wasn't too much work. enable the updates-testing repository in /etc/yum.repos.d/fedora-updates-testing.repo. Note that this will get you _all_ testing packages next time you run updates. For a single package, you can use the command listed in Comment 36.
Created attachment 382952 [details] Xorg.conf Bug still reproducible with this xorg.conf on xorg-x11-server-1.7.4.fc12
Sorry to be more verbose on my last posting, I updated the following packages from 'updates-tesing': xorg-x11-server-Xorg-1.7.4-1.fc12.x86_64 xorg-x11-server-common-1.7.4-1.fc12.x86_64 xorg-x11-drv-evdev-2.3.2-3.fc12.x86_64 I removed my xorg.conf, and restarted the xserver. I ran nvidia-display to reapply my dual head settings (new xorg.cong attached in my posting above), and did not apply the workaround from Aaron. Switching away from that machine for about 30mins, the machine had locked up when I switched back.
I can confirm that this update does not fix the KVM switching problem. Also, this update disables the xorg.conf file workaround that was working with xorg-x11-server-Xorg-1.7.1-7.fc12. After two or three switches, the X server crashes and restarts. It appears to crash when the keyboard and mouse are switched back into the system. No error message is reported in the Xorg.0.log.old file, although I only crashed and checked a couple of times.
I am hitting this bug too, but with a rocketfish bluetooth keyboard waking up. running latest updates-testing with notrapsignals and ulimit unlimited collecting fresh coredumps. I'll start posting gdb backtraces from an unmodified install this evening. (II) config/hal: Adding input device Rocketfish Bluetooth Keyboard (**) Rocketfish Bluetooth Keyboard: always reports core events (**) Rocketfish Bluetooth Keyboard: Device: "/dev/input/event6" (II) Rocketfish Bluetooth Keyboard: Found absolute axes (II) Rocketfish Bluetooth Keyboard: Found keys (II) Rocketfish Bluetooth Keyboard: Configuring as mouse (II) Rocketfish Bluetooth Keyboard: Configuring as keyboard (II) XINPUT: Adding extended input device "Rocketfish Bluetooth Keyboard" (type: KEYBOARD) (**) Option "xkb_rules" "evdev" (**) Option "xkb_model" "pc105+inet" (**) Option "xkb_layout" "us" (**) Option "xkb_options" "terminate:ctrl_alt_bksp" (**) Rocketfish Bluetooth Keyboard: (accel) keeping acceleration scheme 1 (**) Rocketfish Bluetooth Keyboard: (accel) acceleration profile 0 (II) Rocketfish Bluetooth Keyboard: initialized for absolute axes.
(gdb) backtrace #0 0x0000003793c781c7 in _int_malloc (av=0x3793f74e80, bytes=<value optimized out>) at malloc.c:4633 #1 0x0000003793c78ffd in __libc_malloc (bytes=384) at malloc.c:3660 #2 0x00000000004e8f63 in XkbSendIndicatorMap (client=0x17f55c0, indicators=0x1698a40, rep=0x7fffda2d0720) at xkb.c:2999 #3 0x00000000004e97db in ProcXkbGetIndicatorMap (client=0x17f55c0) at xkb.c:3068 #4 0x000000000042c71c in Dispatch () at dispatch.c:439 #5 0x0000000000421d5a in main (argc=<value optimized out>, argv=<value optimized out>, envp=<value optimized out>) at main.c:285 (gdb) backtrace #0 0x0000003793c77300 in _int_free (av=0x3793f74e80, p=0xc78bc0, have_lock=0) at malloc.c:4954 #1 0x0000000000445c28 in dixFreePrivates (privates=0xc78bd0) at privates.c:220 #2 0x00007f32e1bd876a in fbDestroyPixmap (pPixmap=0x10d7e30) at fbpixmap.c:103 #3 0x00007f32e19b26bb in exaDestroyPixmap_mixed (pPixmap=0x10d7e30) at exa_mixed.c:267 #4 0x00000000004d4c9c in damageDestroyPixmap (pPixmap=0x10d7e30) at damage.c:1747 #5 0x00007f32e298b89d in XvDestroyPixmap (pPix=0x10d7e30) at xvmain.c:381 #6 0x0000000000449440 in FreeResource (id=79841528, skipDeleteFuncType=0) at resource.c:556 #7 0x0000000000428bba in ProcFreePixmap (client=0xced570) at dispatch.c:1502 #8 0x000000000042c71c in Dispatch () at dispatch.c:439 #9 0x0000000000421d5a in main (argc=<value optimized out>, argv=<value optimized out>, envp=<value optimized out>) at main.c:285
Core was generated by `/usr/bin/Xorg :0 -br -verbose -auth /var/run/gdm/auth-for-gdm-kK8PwE/database -'. Program terminated with signal 11, Segmentation fault. #0 XkbMaskForVMask (xkb=0x0, vmask=1) at xkbUtils.c:208 208 mask|= xkb->server->vmods[i]; #0 XkbMaskForVMask (xkb=0x0, vmask=1) at xkbUtils.c:208 #1 0x00000000004eb982 in _XkbSetIndicatorMap (client=0x1049c80, dev=0x0, which=-1, desc=0x10251b8) at xkb.c:3103 #2 0x00000000004ebbf2 in ProcXkbSetIndicatorMap (client=0x1049c80) at xkb.c:3173 #3 0x000000000042c71c in Dispatch () at dispatch.c:439 #4 0x0000000000421d5a in main (argc=<value optimized out>, argv=<value optimized out>, envp=<value optimized out>) at main.c:285 Core was generated by `/usr/bin/Xorg :0 -br -verbose -auth /var/run/gdm/auth-for-gdm-VD46Md/database -'. Program terminated with signal 6, Aborted. #0 0x0000003793c326c5 in raise (sig=<value optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 64 return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig); #0 0x0000003793c326c5 in raise (sig=<value optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #1 0x0000003793c33ea5 in abort () at abort.c:92 #2 0x0000003793c6f0f3 in __libc_message (do_abort=<value optimized out>, fmt=<value optimized out>) at ../sysdeps/unix/sysv/linux/libc_fatal.c:186 #3 0x0000003793c74a76 in malloc_printerr (action=3, str=0x3793d3e4e8 "double free or corruption (!prev)", ptr=<value optimized out>) at malloc.c:6264 #4 0x00000000004e8b84 in XkbSendMap (client=0x2148fe0, xkb=0x1fc4500, rep=0x7fffd40e4b60) at xkb.c:1408 #5 0x00000000004eec79 in ProcXkbGetMap (client=0x2148fe0) at xkb.c:1536 #6 0x000000000042c71c in Dispatch () at dispatch.c:439 #7 0x0000000000421d5a in main (argc=<value optimized out>, argv=<value optimized out>, envp=<value optimized out>) at main.c:285 Core was generated by `/usr/bin/Xorg :0 -br -verbose -auth /var/run/gdm/auth-for-gdm-Sw8N9H/database -'. Program terminated with signal 11, Segmentation fault. #0 0x000000000043fa67 in FreeGC (value=0x1c69300, gid=<value optimized out>) at gc.c:881 881 (* pGC->pScreen->DestroyPixmap)(pGC->tile.pixmap); #0 0x000000000043fa67 in FreeGC (value=0x1c69300, gid=<value optimized out>) at gc.c:881 #1 0x0000000000448f63 in FreeClientResources (client=<value optimized out>) at resource.c:806 #2 0x0000000000427e50 in CloseDownClient (client=0x1ed18a0) at dispatch.c:3631 #3 0x000000000042c5b0 in Dispatch () at dispatch.c:450 #4 0x0000000000421d5a in main (argc=<value optimized out>, argv=<value optimized out>, envp=<value optimized out>) at main.c:2
Upstream bug: http://bugs.freedesktop.org/show_bug.cgi?id=25640
Scratch package with the potential fix available for testing below: http://koji.fedoraproject.org/koji/taskinfo?taskID=1918062 Link to the patch: http://lists.freedesktop.org/archives/xorg-devel/2010-January/004908.html
12 hours so far and I have been unable to crash Xorg, with the added benefit of having the keyboard wake up time decreased.
xorg-x11-server-1.7.4-3.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/xorg-x11-server-1.7.4-3.fc12
This seems to be working now. Updating the xorg-x11-server-common and xorg-x11-server-Xorg packages results in no crashes/restarts or freezes. Thanks for the fix. $ rpm -q xorg-x11-drv-evdev xorg-x11-server-common xorg-x11-server-Xorg xorg-x11-drv-evdev-2.3.2-3.fc12.i686 xorg-x11-server-common-1.7.4-3.fc12.i686 xorg-x11-server-Xorg-1.7.4-3.fc12.i686
xorg-x11-server-1.7.4-3.fc12 has been pushed to the Fedora 12 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-server'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F12/FEDORA-2010-0645
xorg-x11-server-1.7.4-1.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.
*** Bug 550948 has been marked as a duplicate of this bug. ***
*** Bug 547004 has been marked as a duplicate of this bug. ***
*** Bug 556307 has been marked as a duplicate of this bug. ***
*** Bug 558474 has been marked as a duplicate of this bug. ***
*** Bug 545834 has been marked as a duplicate of this bug. ***
*** Bug 531039 has been marked as a duplicate of this bug. ***
As a data point, the update fixed my issue
I reported the bug was affecting me in https://bugzilla.redhat.com/show_bug.cgi?id=545834 I am using a KVM, but not one made by Belikn (I don't think that the KVM brand makes any difference). I am happy to say that the latest fix seems to be stable, with no problems. Many thanks to all concerned for finally nailing this extremely annoying bug!
I am still seem to be experiencing this behaviour after the updates. Only happens with Gnome not KDE. # rpm -qa | grep xorg-x11-server xorg-x11-server-utils-7.4-13.fc12.i686 xorg-x11-server-common-1.7.4-1.fc12.i686 xorg-x11-server-Xorg-1.7.4-1.fc12.i686 # rpm -qa | grep xorg-x11-drv-evdev xorg-x11-drv-evdev-2.3.2-2.fc12.i686 /var/log/messages: Jan 27 13:00:39 gghossegor kernel: usb 1-4.1: USB disconnect, address 64 Jan 27 13:00:39 gghossegor kernel: usb 1-4.1: new low speed USB device using ehci_hcd and address 67 Jan 27 13:00:39 gghossegor kernel: usb 1-4.1: New USB device found, idVendor=050d, idProduct=0102 Jan 27 13:00:39 gghossegor kernel: usb 1-4.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 Jan 27 13:00:39 gghossegor kernel: usb 1-4.1: Product: Flip KVM Jan 27 13:00:39 gghossegor kernel: usb 1-4.1: Manufacturer: Belkin Corporation Jan 27 13:00:39 gghossegor kernel: usb 1-4.1: configuration #1 chosen from 1 choice Jan 27 13:00:39 gghossegor kernel: input: Belkin Corporation Flip KVM as /devices/pci0000:00/0000:00:1d.7/usb1/1-4/1-4.1/1-4.1:1.0/input/input81 Jan 27 13:00:39 gghossegor kernel: generic-usb 0003:050D:0102.004F: input,hidraw0: USB HID v1.10 Mouse [Belkin Corporation Flip KVM] on usb-0000:00:1d.7-4.1/input0 Jan 27 13:00:39 gghossegor kernel: input: Belkin Corporation Flip KVM as /devices/pci0000:00/0000:00:1d.7/usb1/1-4/1-4.1/1-4.1:1.1/input/input82 Jan 27 13:00:39 gghossegor kernel: generic-usb 0003:050D:0102.0050: input,hidraw3: USB HID v1.10 Keyboard [Belkin Corporation Flip KVM] on usb-0000:00:1d.7-4.1/input1 Jan 27 13:00:40 gghossegor kernel: usb 1-4.4: USB disconnect, address 65 Jan 27 13:00:41 gghossegor kernel: usb 1-4.3: USB disconnect, address 66 /var/log/Xorg.0.log Backtrace: 0: /usr/bin/Xorg (xorg_backtrace+0x3c) [0x80e596c] 1: /usr/bin/Xorg (0x8047000+0x5fbd6) [0x80a6bd6] 2: (vdso) (__kernel_rt_sigreturn+0x0) [0x31d40c] 3: /lib/libc.so.6 (0xaa9000+0x71a71) [0xb1aa71] 4: /lib/libc.so.6 (__libc_malloc+0x5e) [0xb1b75e] 5: /usr/bin/Xorg (Xalloc+0x2a) [0x80a778a] 6: /usr/bin/Xorg (Xcalloc+0x26) [0x80a7af6] 7: /usr/bin/Xorg (0x8047000+0xed393) [0x8134393] 8: /usr/bin/Xorg (0x8047000+0xf3c23) [0x813ac23] 9: /usr/bin/Xorg (0x8047000+0x27267) [0x806e267] 10: /usr/bin/Xorg (0x8047000+0x1b905) [0x8062905] 11: /lib/libc.so.6 (__libc_start_main+0xe6) [0xabfbb6] 12: /usr/bin/Xorg (0x8047000+0x1b4f1) [0x80624f1] Segmentation fault at address 0x4000088 Fatal server error: Caught signal 11 (Segmentation fault). Server aborting
Get the updates from: http://koji.fedoraproject.org/koji/buildinfo?buildID=150827 http://admin.fedoraproject.org/updates/F12/FEDORA-2010-0645 You've got the wrong versions. Instead of "1.7.4-1" you need "1.7.4-3". $ rpm -q xorg-x11-server-common xorg-x11-server-Xorg xorg-x11-drv-evdev xorg-x11-server-common-1.7.4-3.fc12.i686 xorg-x11-server-Xorg-1.7.4-3.fc12.i686 xorg-x11-drv-evdev-2.3.2-3.fc12.i686
My mistake, I forgot to enable updates-testing. Using the updated packages I am now am able to switch to Fedora 12 Gnome without the lock-ups. It may be unrelated, but these updates seem to have broken KDE for me. After an attempted KDE log on, the Fedora splash screen starts with the animation showing increasing sized dots, then I am thrown back to the log on screen. This was stable and worked when switching back and forth using my KVM with the old versions of these packages, unlike Gnome. I can not find anything in the logs relating to this crash. I have tried deleting the .kde directory from my home directory but that didn't help. This is not a big problem for me as I tend to use Gnome, but I mention it in case it breaks KDE for some when the updated packages are released.
xorg-x11-drv-evdev-2.3.2-3.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.
*** Bug 552052 has been marked as a duplicate of this bug. ***
I am still getting the same misbehavior on the same machines. Someone on a nearby LUG suggested disabling all screensavers; I did, and got no joy. I suspected my oldest PC, since that has other problems; so I disconnected it from the KVM switch. That didn't help either, I'm stil getting the symptoms I described in Bug 556307. And that remains the case after running the Software Updater (gpk-update-viewer) just this morning.
Beartooth, Did you do: $ rpm -q xorg-x11-server-common xorg-x11-server-Xorg xorg-x11-drv-evdev And compare your values to Comment 61?
No. I hadn't seen it. I was going by the presumption that non-developers were encouraged to file bugs, even if they (id est we) were incapable of following the discussion that would ensue. I have now. Most of the comments here are hopelessly over my head; and I took Comment 63 (which I *had* seen somewhere) to mean that my fully updated F12 should now work. I does not. I get : rpm -q xorg-x11-server-common xorg-x11-server-Xorg xorg-x11-drv-evdev xorg-x11-server-common-1.7.4-1.fc12.i686 xorg-x11-server-Xorg-1.7.4-1.fc12.i686 xorg-x11-drv-evdev-2.3.2-3.fc12.i686 Does this mean that a Gamma Minus subtechnoid suddenly has any business enabling http://koji.fedoraproject.org/koji/buildinfo?buildID=150827 http://admin.fedoraproject.org/updates/F12/FEDORA-2010-0645 (which I take to be repositories for developers)?? And if Comment 63 does not mean that this bug should not appear in fully-updated but plain vanilla F12, what does it mean?
Beartooth, My guess is that Comment 63 means it has been pushed out. Now how long it takes to propagate to all the mirrors out there may vary. I would think that it should be fully propagated within 24 hours, but I have no idea how the mirror service works and how quickly things get synced up. When I look here: http://download.fedora.redhat.com/pub/fedora/linux/updates/12/x86_64/ It has not shown up as of this very moment.
Yeah, you still have the wrong versions. The bug fix is in version 1.7.4-3, and is broken in the prior version 1.7.4-1. I was confused by the yum update stuff earlier too, but until it comes out you have to get it directly from the links that the developers put in the comments. As of right now, it seems like version 1.7.4-6 is in the updates-testing repository. That should have your fix. How about this? yum --enablerepo=updates-testing install xorg-x11-server-Xorg xorg-x11-server-common xorg-x11-drv-evdev
That ended with Error: failure: repodata/ca3fdff1d903b5df555e091f54c2807c6e974c2f7a81a5fb504ea72806689889-primary.sqlite.bz2 from updates-testing: [Errno 256] No more mirrors to try. Maybe tomorrow's update will have it. Many thanks to all!
(In reply to comment #67) > rpm -q xorg-x11-server-common xorg-x11-server-Xorg xorg-x11-drv-evdev > xorg-x11-server-common-1.7.4-1.fc12.i686 > xorg-x11-server-Xorg-1.7.4-1.fc12.i686 > xorg-x11-drv-evdev-2.3.2-3.fc12.i686 This is what I have on my Fedora system. I noticed evdev-2.3.2-3 was pushed out on F12 yesterday. I applied it but the X server still crashed this morning. Instead of locking up, the screen seems responsive after the KVM switch and then after about 4 seconds, the screen fades to black and a login screen shows up. A core dump is generated. Here are some log messages: Feb 2 11:39:56 localhost kernel: usb 3-1.1: new full speed USB device using uhc i_hcd and address 8 Feb 2 11:39:56 localhost kernel: usb 3-1.1: New USB device found, idVendor=046d , idProduct=c513 Feb 2 11:39:56 localhost kernel: usb 3-1.1: New USB device strings: Mfr=1, Prod uct=2, SerialNumber=0 Feb 2 11:39:56 localhost kernel: usb 3-1.1: Product: USB Receiver Feb 2 11:39:56 localhost kernel: usb 3-1.1: Manufacturer: Logitech Feb 2 11:39:56 localhost kernel: usb 3-1.1: configuration #1 chosen from 1 choi ce Feb 2 11:39:56 localhost kernel: input: Logitech USB Receiver as /devices/pci00 00:00/0000:00:10.1/usb3/3-1/3-1.1/3-1.1:1.0/input/input13 Feb 2 11:39:56 localhost kernel: logitech 0003:046D:C513.000B: input,hidraw2: U SB HID v1.11 Keyboard [Logitech USB Receiver] on usb-0000:00:10.1-1.1/input0 Feb 2 11:39:56 localhost kernel: logitech 0003:046D:C513.000C: fixing up Logite ch keyboard report descriptor Feb 2 11:39:56 localhost kernel: input: Logitech USB Receiver as /devices/pci00 00:00/0000:00:10.1/usb3/3-1/3-1.1/3-1.1:1.1/input/input14 Feb 2 11:39:56 localhost kernel: logitech 0003:046D:C513.000C: input,hiddev96,h idraw3: USB HID v1.11 Mouse [Logitech USB Receiver] on usb-0000:00:10.1-1.1/inpu t1 Feb 2 11:40:03 localhost abrtd: Directory 'ccpp-1265128803-1445' creation detec ted Feb 2 11:40:03 localhost gnome-session[1584]: WARNING: Detected that screensave r has left the bus Feb 2 11:40:03 localhost abrtd: Lock file '/var/cache/abrt/ccpp-1265128803-1445 .lock' is locked by process 2829 Feb 2 11:40:03 localhost abrt[2829]: saved core dump of pid 1445 (/usr/bin/Xorg ) to /var/cache/abrt/ccpp-1265128803-1445/coredump (61440 bytes) I like the comment "screensaver has left the bus". Core dump is from: /usr/bin/Xorg :0 -nr -verbose -auth /var/run/gdm/auth-for-gdm-oAISIq/database - abrtd seems to have truncated the core file so no additional information can be gleaned from gdb. I noticed that earlier comments also seemed to indicate that the X server needs to be a 1.7.4-3 to fix a problem on that end. So my suspicion is that we need to wait on that new X server.
I'm still experiencing this, Rosewill USB KVM with both a 32 and 64 bit install of Fedora 12 on Intel MBs and > rpm -q xorg-x11-server-common xorg-x11-server-Xorg xorg-x11-drv-evdev > xorg-x11-server-common-1.7.4-6.fc12.i686 > xorg-x11-server-Xorg-1.7.4-6.fc12.i686 > xorg-x11-drv-evdev-2.3.2-3.fc12.i686
PackageKit updater brought lots and lots of new stuff today, all of which I installed. It did make a difference -- but not a welcome one. Now, the machines behind the KVM switch can boot and run, but not one of them shows any reaction to mouse nor keyboard. (You can ssh into them from another machine that's on the LAN but isn't behind the switch.)
Patch has not landed in rawhide and still crashes
(In reply to comment #74) > Patch has not landed in rawhide and still crashes Fixed, thanks for the reminder. http://koji.fedoraproject.org/koji/buildinfo?buildID=154840 (In reply to comment #73) > Now, the machines behind the KVM switch can boot and run, but not one of > them shows any reaction to mouse nor keyboard. (You can ssh into them from > another machine that's on the LAN but isn't behind the switch.) please attach your log, without it we cannot know whether it's the server or something else. this sounds like the devices don't get detected at all which cannot be triggered by this bug. It's likely that you're seeing a different bug.
What log? Where?
the /var/log/Xorg.0.log, usually. This should show if the devices are even detected by the server (e.g. I had a bug on a rawhide machine recently where hald crashed, leaving the server with no input devices).
It's almost 41K bytes -- and I disremember how to create an attachment; here's hoping this works!
*** Bug 538500 has been marked as a duplicate of this bug. ***
Fedora updated the X server about a week ago. This finally fixed the issue on my end.
My apologies for the late reply; I've been distracted by things ranging from major surgery to house guests. On the strength of Dan Vietor's report 80 above, I hooked all machines back up to the KVM switch. Three of them have now been working fine, including switching around among them, for a couple days. (The fourth, my oldest, has been having other troubles for months; I have now DBANned it and found a good home for it, where it will still outclass the machine it replaces, and yet need only do dialup.) Iow, for all practical purposes, the fix works here, too. Praised be the developers!
Thanks for testing again. I think this bug can be closed again now, no? Please reopen if you still see this issue with the latest updates applied, but by now I'm pretty sure that any crashes are a different bug :)
It is suddenly biting again, harder than ever, since yesterday's PackageKit update on F12. Now, if behind the Trendnet TK-407 USB KVM switch, none of the three machines sees keyboard, mouse, nor even a login display. (I found a good home for the fourth machine.) Yesterday having been a large occasion here, I have not yet tried to ssh into a machine behind the switch from one not behind it. Even before that, I want to make sure all machines still work normally when not behind the switch. (Time was when new releases had to be installed on machines not behind the KVM switches of that time.) I'll report more when I have any more, here or on gmane.linux.redhat.fedora.general -- and I suggest that be reopened. (I sent a copy of this post to the gmane address.) -- Beartooth Staffwright, Neo-Redneck Not Quite Clueless Power User I have precious (very precious!) little idea where up i
OOPS! Wrong bug! I established that all three machines run fine while out from behind the KVM switch, as expected. Next I tried rebooting them all, while back behind it, betting, on the assumption that this was indeed a recrudescence of the same bug, that that much would work. It did, with one small wrinkle from here : I let each finish booting before the next. Unexpectedly, all let me log in, and run my accustomed apps. What's more, once they were all up, I could (and still can) switch among them at will again. So it must be a different bug, right? The present situation is just like the one, several releases back, after installing or updating a release. Each machine had to have a direct connection, free of the KVM switch, to autoconfigure X. This has *not* been the case for the last half dozen or so releases -- the machines got whatever they needed *through* not only this KVM switch, but at least one before it, and a different brand (though also USB). So I could install or upgrade on one while still using the others normally. If some kindly developer can restore that situation, it would save a lot of hassle; but the trouble is no longer nearly so bad as at first it seemed. I've seldom been gladder to be wrong. <sheepish grin>
Please open a new bug for this (and link to this one), because this one is quite long already and I prefer short bugs over ones with hundreds of comments.
somebody screwed this up big time. With all the latest updates in my FC12, I don't even get to see my gdm screen. I just blindly enter the password and then I get the desktop without any wallpaper. That is, if I have external monitor connected and I remove 'nomodeset' from the kernel arguments. It is definitely worse then how it was before this bug. I don't know if it is new or old but external monitor is badly broken now. I am still wondering why Ubuntu has no issues with that. I might as well change the distro.
wrong update. please ignore. it was meant to be for 571046
I can open a new bug, yes, gladly. (And I agree about the length.) It's been a while since I've started one; maybe the instructions on how to link are obvious. If not, where are they?
> It's been a while since I've started one; maybe the instructions on how to > link are obvious. If not, where are they? just copy the URL of this bug into the first comment on the new one and the other way round :)
Did a new bug ever get filed? I don't see any "link" info since the 12apr10 post (maybe I am missing something?) I've been following this as KVM is a concern and wanted to at least know what the new bug is to see if it is also a concern for me Thanks, Paul
My bad. It didn't seem urgent, and lots of other recent stuff has. For the immediate fix, mine was simple. Shut all machines down; connect one at a time directly to the peripherals; run it through its paces for an hour or three; repeat with next machine. When all are working, put them back behind the switch. Done -- at least here.
Thanks. No problem and its not "my bad" as the explanation makes it clear why it isn't urgent (and, yes, there are a whole lotta of other more urgent issues). I'm just trying to keep track of KVM issues as I've found it to be a weak spot in my life. And its probably more of issues with hardware / BIOS on my end, but I still want to make sure I am not being tripped by something on the OS side. Paul