Bug 472965 - X Server dies when connecting USB audio: Too many input devices
X Server dies when connecting USB audio: Too many input devices
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: hal (Show other bugs)
10
All Linux
medium Severity high
: ---
: ---
Assigned To: Richard Hughes
Fedora Extras Quality Assurance
:
: 483511 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-11-25 15:34 EST by Felix Kaechele
Modified: 2018-04-11 09:43 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-11-18 17:11:24 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)
Xorg.0.log of the whole session (41.37 KB, text/plain)
2008-11-25 15:34 EST, Felix Kaechele
no flags Details
Last Session failure (29.84 KB, text/plain)
2009-02-13 05:53 EST, Leonidas Georgopoulos
no flags Details
Logfile (153.00 KB, application/octet-stream)
2009-02-13 05:56 EST, Leonidas Georgopoulos
no flags Details

  None (edit)
Description Felix Kaechele 2008-11-25 15:34:57 EST
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.
Comment 2 Matěj Cepl 2008-11-25 17:12:06 EST
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
Comment 3 Peter Hutterer 2008-11-25 18:09:17 EST
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.
Comment 4 Felix Kaechele 2008-12-03 16:11:20 EST
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.
Comment 5 Matěj Cepl 2008-12-03 19:11:25 EST
Peter, could we official update package, so that we can close this?
Comment 6 Peter Hutterer 2008-12-03 21:03:30 EST
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.
Comment 7 Leonidas Georgopoulos 2009-02-08 12:18:49 EST
*** Bug 483511 has been marked as a duplicate of this bug. ***
Comment 8 Leonidas Georgopoulos 2009-02-13 05:53:40 EST
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.
Comment 9 Leonidas Georgopoulos 2009-02-13 05:56:41 EST
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
Comment 10 Peter Hutterer 2009-02-15 18:13:58 EST
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.
Comment 11 Felix Kaechele 2009-02-27 04:59:52 EST
I recently installed rawhide and since then never had this issue again. So it seems to be fixed for me.
Comment 12 Bug Zapper 2009-11-18 02:59:08 EST
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
Comment 13 Peter Hutterer 2009-11-18 17:11:24 EST
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.

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