Bug 472965
| Summary: | X Server dies when connecting USB audio: Too many input devices | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Felix Kaechele <felix> | ||||||||
| Component: | hal | Assignee: | Richard Hughes <richard> | ||||||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||
| Severity: | high | Docs Contact: | |||||||||
| Priority: | medium | ||||||||||
| Version: | 10 | CC: | georgopl, mcepl, peter.hutterer, richard, xgl-maint | ||||||||
| Target Milestone: | --- | ||||||||||
| Target Release: | --- | ||||||||||
| Hardware: | All | ||||||||||
| OS: | Linux | ||||||||||
| Whiteboard: | |||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||
| Doc Text: | Story Points: | --- | |||||||||
| Clone Of: | Environment: | ||||||||||
| Last Closed: | 2009-11-18 22:11:24 UTC | Type: | --- | ||||||||
| Regression: | --- | Mount Type: | --- | ||||||||
| Documentation: | --- | CRM: | |||||||||
| Verified Versions: | Category: | --- | |||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||
| Embargoed: | |||||||||||
| Attachments: |
|
||||||||||
This is probably quite interesting part of the log: (EE) ThinkPad Bluetooth Laser Mouse: Read error: No such device (EE) ThinkPad Bluetooth Laser Mouse: Failed to reopen device after 10 attempts. (EE) Burr-Brown from TI USB Audio CODEC: Read error: No such device (EE) IR-receiver inside an USB DVB receiver: Read error: No such device (EE) ThinkPad Bluetooth Laser Mouse: Read error: No such device (EE) ThinkPad Bluetooth Laser Mouse: Failed to reopen device after 10 attempts. (EE) ThinkPad Bluetooth Laser Mouse: Read error: No such device (EE) ThinkPad Bluetooth Laser Mouse: Failed to reopen device after 10 attempts. (EE) ThinkPad Bluetooth Laser Mouse: Read error: No such device [... snip ...] (EE) ThinkPad Bluetooth Laser Mouse: Failed to reopen device after 10 attempts. (EE) Burr-Brown from TI USB Audio CODEC: Read error: No such device (EE) IR-receiver inside an USB DVB receiver: Read error: No such device (EE) ThinkPad Bluetooth Laser Mouse: Read error: No such device (EE) ThinkPad Bluetooth Laser Mouse: Failed to reopen device after 10 attempts. [... snip ...] (EE) ThinkPad Bluetooth Laser Mouse: Failed to reopen device after 10 attempts. (EE) ThinkPad Bluetooth Laser Mouse: Read error: No such device (EE) ThinkPad Bluetooth Laser Mouse: Failed to reopen device after 10 attempts. [... snip ...] (EE) ThinkPad Bluetooth Laser Mouse: Failed to reopen device after 10 attempts. (EE) ThinkPad Bluetooth Laser Mouse: Read error: No such device (EE) ThinkPad Bluetooth Laser Mouse: Read error: No such device (EE) ThinkPad Bluetooth Laser Mouse: Failed to reopen device after 10 attempts. (EE) ThinkPad Bluetooth Laser Mouse: Read error: No such device (EE) ThinkPad Bluetooth Laser Mouse: Failed to reopen device after 10 attempts. [... snip ...] (EE) ThinkPad Bluetooth Laser Mouse: Failed to reopen device after 10 attempts. (EE) ThinkPad Bluetooth Laser Mouse: Read error: No such device The problem is the imbalance between add and remove events we get from HAL. ATM, if a read error occurs on a device, we disable it. If (after suspend or a VT switch) the device is available again, we can thus enable it again and avoid losing the settings for the specific device. If a device has actually been removed, HAL should send us a message and then we'll remove it properly. This doesn't seem to happen, so I shove this bug to HAL for now. Felix: As an intermediate fix, please test the packages from http://koji.fedoraproject.org/scratch/whot/task_951820/ They contain a two-line fix, removing the device on read errors instead of just disabling them. Looks good so far. Even after excessive suspending/resuming and plugging/unplugging of evdev devices the X server is yet to crash. However rarely the X Server dies on suspending. But this is probably not related to this issue. From my perspective this bug is fixed. Peter, could we official update package, so that we can close this? sorry, I'll have to pass that back to HAL. The root of the issue is that we don't get remove events from HAL. The fix above is good enough for Felix because it doesn't kill his server anymore, but it's the wrong fix and causes a few other issues. I need to hear from hughsie first. *** Bug 483511 has been marked as a duplicate of this bug. *** Created attachment 331821 [details]
Last Session failure
This seems to happen every time when having more than one bluetooth devices connected. There are two ways to reproduce this.
1. Connect bluetooth devices
2. Suspend
3. Resume
4. Move the mouse / keyboard
The other way is
1. Connect bluetooth devices
2. Let the computer idle for some period of time (probably equal to the timeout of one of the bluetooth devices)
3. Act on the device, i.e. if it was the keyboard press a button
Result is the same: session fails and X server restarts.
Created attachment 331822 [details]
Logfile
This includes messages from all sources, i.e. is generated by adding in rsyslog.conf the line *.* /var/log/all.log
FWIW, the X server crash on "too many devices" has been fixed with server 1.6 (in rawhide). But it required an API/ABI break and no backport is available for 1.5. I recently installed rawhide and since then never had this issue again. So it seems to be fixed for me. This message is a reminder that Fedora 10 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 10. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '10'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 10's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 10 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping Closing with CURRENTRELEASE - as pointed out in Comments #10, the server crash is fixed in server 1.6 (Fedora 11) and doesn't seem to trigger anymore (Comment #11). If you're experiencing this bug with Fedora 11 or Fedora 12, please file a new bugreport. |
Created attachment 324666 [details] Xorg.0.log of the whole session Description of problem: X Server dies when plugging in USB audio device. Log message: Fatal server error: Too many input devices Version-Release number of selected component (if applicable): [felix@polaris ~]$ rpm -qa | grep xorg xorg-x11-xinit-1.0.9-4.fc10.i386 xorg-x11-xkb-utils-7.2-7.fc10.i386 xorg-x11-drv-nvidia-libs-177.82-1.fc10.i386 xorg-x11-server-Xorg-1.5.3-5.fc10.i386 xorg-x11-drv-keyboard-1.3.0-3.fc9.i386 xorg-x11-filesystem-7.3-2.fc10.noarch xorg-x11-drivers-7.3-9.fc10.i386 xorg-x11-xauth-1.0.2-5.fc10.i386 xorg-x11-apps-7.3-5.fc10.i386 xorg-x11-proto-devel-7.4-4.fc10.noarch xorg-x11-utils-7.4-3.fc10.i386 xorg-x11-drv-evdev-2.0.7-3.fc10.i386 xorg-x11-drv-nvidia-177.82-1.fc10.i386 xorg-x11-font-utils-7.2-6.fc10.i386 xorg-x11-server-utils-7.4-3.fc10.i386 xorg-x11-drv-synaptics-0.15.2-1.fc10.i386 xorg-x11-server-common-1.5.3-5.fc10.i386 xorg-x11-drv-mouse-1.3.0-2.fc9.i386 How reproducible: sometimes Steps to Reproduce: 1. Use laptop in everyday use scenario. 2. Probably suspend and resume a few times. 3. Wake your Bluetooth mouse up when it became inactive. 4. At home plug in your USB audio device that is connected to your HiFi to enjoy music Actual results: X Server crashes and everything within the session is probably lost. Expected results: The X Server runs normally and USB audio is working. Additional info: The X server successfully restarts and everything (including USB audio) works as desired. I assume everytime the Bluetooth mouse goes into sleep mode and then wakes up again a new input device is created. Finally when plugging in the USB audio device it is recognized as input device as well. Furthermore a DVB Stick is plugged into the same USB hub as the USB audio and thus is recognized at the same time. That DVB-T stick has an IR sensor probably also being registered as an input device. That most likely confuses X and it wants to die. Please enjoy the fine Xorg.0.log I attached. It happened only twice the last 3 weeks.