* usb device removed from sysfs before input children devices
@ 2013-01-09 19:27 Karl Relton
2013-01-15 20:27 ` Karl Relton
0 siblings, 1 reply; 5+ messages in thread
From: Karl Relton @ 2013-01-09 19:27 UTC (permalink / raw)
To: linux-usb, linux-bluetooth
On coming out of suspend my usb bluetooth adaptor is being reset by the
system.
In linux 3.7 the usb devices are being removed from the sysfs tree
first, and then the various 'child' devices (like my bluetooth mouse &
keyboard related devices) afterwards. This is causing the udev events
for the input devices to have 'orphaned' sysfs paths in the udev events.
This in turn means the Xorg evdev driver does not recognise the events,
and so doesn't see the removal of the input devices.
This has been picked by some downstream distributions, e.g. see this
thread by Google Chrome developers:
http://code.google.com/p/chromium-os/issues/detail?id=33813
Back on linux 3.2 this was not the case. The usb adaptor was reset, but
device removal was orderly: first the input devices (will full paths in
the udev events), then the usb devices walking up the tree.
To illustrate the issue, here is the output of 'udevadm monitor' in 3.7:
udevadm monitor
monitor will print the received events for:
KERNEL - the kernel uevent
KERNEL[2203.173080] remove /devices/pci0000:00/0000:00:1a.0/usb3/3-2/3-2:1.0/bluetooth/hci0/rfkill2 (rfkill)
KERNEL[2203.173148] remove /devices/pci0000:00/0000:00:1a.0/usb3/3-2/3-2:1.0/bluetooth/hci0 (bluetooth)
KERNEL[2203.173420] remove /devices/pci0000:00/0000:00:1a.0/usb3/3-2/3-2:1.0 (usb)
KERNEL[2203.173451] remove /devices/pci0000:00/0000:00:1a.0/usb3/3-2/3-2:1.1 (usb)
KERNEL[2203.173475] remove /devices/pci0000:00/0000:00:1a.0/usb3/3-2/3-2:1.2 (usb)
KERNEL[2203.173693] remove /devices/pci0000:00/0000:00:1a.0/usb3/3-2 (usb)
KERNEL[2213.152339] remove /hci0/hci0:46/input14/mouse2 (input)
KERNEL[2213.160374] remove /hci0/hci0:46/input14/event10 (input)
KERNEL[2213.168366] remove /hci0/hci0:46/input14 (input)
KERNEL[2213.169058] remove /hci0/hci0:46/0005:050D:0031.0005/hidraw/hidraw0 (hidraw)
KERNEL[2213.169198] remove /hci0/hci0:46/0005:050D:0031.0005 (hid)
KERNEL[2213.169242] remove /hci0/hci0:46 (bluetooth)
KERNEL[2218.176527] remove /hci0/hci0:49/input13/event11 (input)
KERNEL[2218.180403] remove /hci0/hci0:49/input13 (input)
KERNEL[2218.180481] remove /hci0/hci0:49/0005:05AC:0256.0004/hidraw/hidraw1 (hidraw)
KERNEL[2218.180538] remove /hci0/hci0:49/0005:05AC:0256.0004 (hid)
KERNEL[2218.182005] remove /hci0/hci0:49 (bluetooth)
See how the usb devices are moved first, and then the input/bluetooth related stuff
with path-heads removed (paths are now /hci0/... instead of /devices/...)
Here is the equiv sequence back in 3.2:
KERNEL[158.378301] remove /devices/pci0000:00/0000:00:1a.0/usb3/3-2/3-2:1.0/bluetooth/hci0/hci0:49/input11/mouse2 (input)
KERNEL[158.388283] remove /devices/pci0000:00/0000:00:1a.0/usb3/3-2/3-2:1.0/bluetooth/hci0/hci0:49/input11/event11 (input)
KERNEL[158.409885] remove /devices/pci0000:00/0000:00:1a.0/usb3/3-2/3-2:1.0/bluetooth/hci0/hci0:49/input11 (input)
KERNEL[158.411565] remove /devices/pci0000:00/0000:00:1a.0/usb3/3-2/3-2:1.0/bluetooth/hci0/hci0:49/0005:050D:0031.0002/hidraw/hidraw1 (hidraw)
KERNEL[158.411598] remove /devices/pci0000:00/0000:00:1a.0/usb3/3-2/3-2:1.0/bluetooth/hci0/hci0:49/0005:050D:0031.0002 (hid)
KERNEL[158.411621] remove /devices/pci0000:00/0000:00:1a.0/usb3/3-2/3-2:1.0/bluetooth/hci0/hci0:49 (bluetooth)
KERNEL[158.436894] remove /devices/pci0000:00/0000:00:1a.0/usb3/3-2/3-2:1.0/bluetooth/hci0/hci0:46/input10/event10 (input)
KERNEL[158.452211] remove /devices/pci0000:00/0000:00:1a.0/usb3/3-2/3-2:1.0/bluetooth/hci0/hci0:46/input10 (input)
KERNEL[158.452628] remove /devices/pci0000:00/0000:00:1a.0/usb3/3-2/3-2:1.0/bluetooth/hci0/hci0:46/0005:05AC:0256.0001/hidraw/hidraw0 (hidraw)
KERNEL[158.452662] remove /devices/pci0000:00/0000:00:1a.0/usb3/3-2/3-2:1.0/bluetooth/hci0/hci0:46/0005:05AC:0256.0001 (hid)
KERNEL[158.452752] remove /devices/pci0000:00/0000:00:1a.0/usb3/3-2/3-2:1.0/bluetooth/hci0/hci0:46 (bluetooth)
KERNEL[158.629847] remove /devices/pci0000:00/0000:00:1a.0/usb3/3-2/3-2:1.0/bluetooth/hci0/rfkill2 (rfkill)
KERNEL[158.629920] remove /devices/pci0000:00/0000:00:1a.0/usb3/3-2/3-2:1.0/bluetooth/hci0 (bluetooth)
KERNEL[158.635562] remove /devices/pci0000:00/0000:00:1a.0/usb3/3-2/3-2:1.0 (usb)
KERNEL[158.635701] remove /devices/pci0000:00/0000:00:1a.0/usb3/3-2/3-2:1.1 (usb)
KERNEL[158.635807] remove /devices/pci0000:00/0000:00:1a.0/usb3/3-2/3-2:1.2 (usb)
KERNEL[158.637238] remove /devices/pci0000:00/0000:00:1a.0/usb3/3-2 (usb)
The end result (for the user) is that even when the bluetooth
mouse/keyboard is re-added, Xorg ignores it - thinking it is some hoax
duplicate device. The keyboard/mouse is then non-operational.
Karl
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: usb device removed from sysfs before input children devices
2013-01-09 19:27 usb device removed from sysfs before input children devices Karl Relton
@ 2013-01-15 20:27 ` Karl Relton
2013-01-24 13:58 ` Karl Relton
0 siblings, 1 reply; 5+ messages in thread
From: Karl Relton @ 2013-01-15 20:27 UTC (permalink / raw)
To: linux-usb, linux-bluetooth
On Wed, 2013-01-09 at 19:27 +0000, Karl Relton wrote:
> On coming out of suspend my usb bluetooth adaptor is being reset by the
> system.
>
> In linux 3.7 the usb devices are being removed from the sysfs tree
> first, and then the various 'child' devices (like my bluetooth mouse &
> keyboard related devices) afterwards. This is causing the udev events
> for the input devices to have 'orphaned' sysfs paths in the udev events.
>
> This in turn means the Xorg evdev driver does not recognise the events,
> and so doesn't see the removal of the input devices.
>
> This has been picked by some downstream distributions, e.g. see this
> thread by Google Chrome developers:
>
> http://code.google.com/p/chromium-os/issues/detail?id=33813
>
> Back on linux 3.2 this was not the case. The usb adaptor was reset, but
> device removal was orderly: first the input devices (will full paths in
> the udev events), then the usb devices walking up the tree.
>
>
> To illustrate the issue, here is the output of 'udevadm monitor' in 3.7:
>
> udevadm monitor
> monitor will print the received events for:
> KERNEL - the kernel uevent
> KERNEL[2203.173080] remove /devices/pci0000:00/0000:00:1a.0/usb3/3-2/3-2:1.0/bluetooth/hci0/rfkill2 (rfkill)
> KERNEL[2203.173148] remove /devices/pci0000:00/0000:00:1a.0/usb3/3-2/3-2:1.0/bluetooth/hci0 (bluetooth)
> KERNEL[2203.173420] remove /devices/pci0000:00/0000:00:1a.0/usb3/3-2/3-2:1.0 (usb)
> KERNEL[2203.173451] remove /devices/pci0000:00/0000:00:1a.0/usb3/3-2/3-2:1.1 (usb)
> KERNEL[2203.173475] remove /devices/pci0000:00/0000:00:1a.0/usb3/3-2/3-2:1.2 (usb)
> KERNEL[2203.173693] remove /devices/pci0000:00/0000:00:1a.0/usb3/3-2 (usb)
> KERNEL[2213.152339] remove /hci0/hci0:46/input14/mouse2 (input)
> KERNEL[2213.160374] remove /hci0/hci0:46/input14/event10 (input)
> KERNEL[2213.168366] remove /hci0/hci0:46/input14 (input)
> KERNEL[2213.169058] remove /hci0/hci0:46/0005:050D:0031.0005/hidraw/hidraw0 (hidraw)
> KERNEL[2213.169198] remove /hci0/hci0:46/0005:050D:0031.0005 (hid)
> KERNEL[2213.169242] remove /hci0/hci0:46 (bluetooth)
> KERNEL[2218.176527] remove /hci0/hci0:49/input13/event11 (input)
> KERNEL[2218.180403] remove /hci0/hci0:49/input13 (input)
> KERNEL[2218.180481] remove /hci0/hci0:49/0005:05AC:0256.0004/hidraw/hidraw1 (hidraw)
> KERNEL[2218.180538] remove /hci0/hci0:49/0005:05AC:0256.0004 (hid)
> KERNEL[2218.182005] remove /hci0/hci0:49 (bluetooth)
>
> See how the usb devices are moved first, and then the input/bluetooth related stuff
> with path-heads removed (paths are now /hci0/... instead of /devices/...)
>
>
> Here is the equiv sequence back in 3.2:
>
> KERNEL[158.378301] remove /devices/pci0000:00/0000:00:1a.0/usb3/3-2/3-2:1.0/bluetooth/hci0/hci0:49/input11/mouse2 (input)
> KERNEL[158.388283] remove /devices/pci0000:00/0000:00:1a.0/usb3/3-2/3-2:1.0/bluetooth/hci0/hci0:49/input11/event11 (input)
> KERNEL[158.409885] remove /devices/pci0000:00/0000:00:1a.0/usb3/3-2/3-2:1.0/bluetooth/hci0/hci0:49/input11 (input)
> KERNEL[158.411565] remove /devices/pci0000:00/0000:00:1a.0/usb3/3-2/3-2:1.0/bluetooth/hci0/hci0:49/0005:050D:0031.0002/hidraw/hidraw1 (hidraw)
> KERNEL[158.411598] remove /devices/pci0000:00/0000:00:1a.0/usb3/3-2/3-2:1.0/bluetooth/hci0/hci0:49/0005:050D:0031.0002 (hid)
> KERNEL[158.411621] remove /devices/pci0000:00/0000:00:1a.0/usb3/3-2/3-2:1.0/bluetooth/hci0/hci0:49 (bluetooth)
> KERNEL[158.436894] remove /devices/pci0000:00/0000:00:1a.0/usb3/3-2/3-2:1.0/bluetooth/hci0/hci0:46/input10/event10 (input)
> KERNEL[158.452211] remove /devices/pci0000:00/0000:00:1a.0/usb3/3-2/3-2:1.0/bluetooth/hci0/hci0:46/input10 (input)
> KERNEL[158.452628] remove /devices/pci0000:00/0000:00:1a.0/usb3/3-2/3-2:1.0/bluetooth/hci0/hci0:46/0005:05AC:0256.0001/hidraw/hidraw0 (hidraw)
> KERNEL[158.452662] remove /devices/pci0000:00/0000:00:1a.0/usb3/3-2/3-2:1.0/bluetooth/hci0/hci0:46/0005:05AC:0256.0001 (hid)
> KERNEL[158.452752] remove /devices/pci0000:00/0000:00:1a.0/usb3/3-2/3-2:1.0/bluetooth/hci0/hci0:46 (bluetooth)
> KERNEL[158.629847] remove /devices/pci0000:00/0000:00:1a.0/usb3/3-2/3-2:1.0/bluetooth/hci0/rfkill2 (rfkill)
> KERNEL[158.629920] remove /devices/pci0000:00/0000:00:1a.0/usb3/3-2/3-2:1.0/bluetooth/hci0 (bluetooth)
> KERNEL[158.635562] remove /devices/pci0000:00/0000:00:1a.0/usb3/3-2/3-2:1.0 (usb)
> KERNEL[158.635701] remove /devices/pci0000:00/0000:00:1a.0/usb3/3-2/3-2:1.1 (usb)
> KERNEL[158.635807] remove /devices/pci0000:00/0000:00:1a.0/usb3/3-2/3-2:1.2 (usb)
> KERNEL[158.637238] remove /devices/pci0000:00/0000:00:1a.0/usb3/3-2 (usb)
>
>
> The end result (for the user) is that even when the bluetooth
> mouse/keyboard is re-added, Xorg ignores it - thinking it is some hoax
> duplicate device. The keyboard/mouse is then non-operational.
>
Instrumenting the code suggests that the issue arises in a race between:
hidp_session() in bluetooth/hidp/core.c
and
hci_unregister_dev() in bluetooth/hci_core.c
Basically hci_unregister_dev() does a hci_dev_do_close() which in turn
shuts down the hidp connection. This causes hidp_session() running in
another thread to go into its cleanup phase, which is where the input
children devices are unregistered.
HOWEVER:
1) For some reason input_unregister_device() seems to stall some 3-5
seconds on my system before removing the input device
2) In parallel hci_unregister_dev() ploughs on, and progresses to remove
its hdev (hci<n> device) regardless, without waiting for hidp_session()
to complete.
I can't figure out why there is such a delay for
input_unregister_device().
But even if it didn't have the delay, there would still be a race
between the two threads (hci_unregister_dev vs hidp_session). No attempt
seems to be made to wait for the latter, so conceivably it could still
progress on even if hidp_session wasn't unnecessarily held up?
Question: What are the symantics of the wake_...() functions? Does the
function(thread) calling wake_... not move on until all the threads
woken by the call have completed or gone back to sleep. Or can the
calling thread() start progressing in parallel on a multi-processor
system?
I ask because if the calling function has to wait for the woken threads,
that would give the appropriate 'wait' on hci_unregister_dev ... but
ONLY IF hidp_session doesn't sleep again for some reason (e.g. while
waiting on a mutex inside input_unregister_device() perhaps ...)
Karl
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: usb device removed from sysfs before input children devices
2013-01-15 20:27 ` Karl Relton
@ 2013-01-24 13:58 ` Karl Relton
2013-01-24 16:09 ` Karl Relton
0 siblings, 1 reply; 5+ messages in thread
From: Karl Relton @ 2013-01-24 13:58 UTC (permalink / raw)
To: linux-usb, linux-bluetooth
On Tue, 2013-01-15 at 20:27 +0000, Karl Relton wrote:
> > The end result (for the user) is that even when the bluetooth
> > mouse/keyboard is re-added, Xorg ignores it - thinking it is some
> hoax
> > duplicate device. The keyboard/mouse is then non-operational.
> >
>
> Instrumenting the code suggests that the issue arises in a race
> between:
>
> hidp_session() in bluetooth/hidp/core.c
>
> and
>
> hci_unregister_dev() in bluetooth/hci_core.c
>
>
> Basically hci_unregister_dev() does a hci_dev_do_close() which in turn
> shuts down the hidp connection. This causes hidp_session() running in
> another thread to go into its cleanup phase, which is where the input
> children devices are unregistered.
>
> HOWEVER:
> 1) For some reason input_unregister_device() seems to stall some 3-5
> seconds on my system before removing the input device
> 2) In parallel hci_unregister_dev() ploughs on, and progresses to
> remove
> its hdev (hci<n> device) regardless, without waiting for
> hidp_session()
> to complete.
>
> I can't figure out why there is such a delay for
> input_unregister_device().
The power_supply system seems to be triggering a lookup of battery
'capacity' in the input device. This calls into the driver, which deep
down invokes more code in the 'hidp' module: hidp_get_raw_report()
This function tries to communicate with the bluetooth device (keyboard
in my case), but because the device is being 'torn down' such
communication fails. Accordingly hidp_get_raw_report has a 5 second
timeout ... so this function stalls for 5 seconds until that timeout
occurs.
I would guess that for some reason, removing the 'hid' or associated
'input' device is leading to the power_supply code wanting to lookup the
battery capacity which introduces a 5 second wait. This would delay
hidp_session by 5 seconds ... in the mean time allowing
hci_unregister_dev() to win the race and hence the hci device is removed
before the input & hid devices.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: usb device removed from sysfs before input children devices
2013-01-24 13:58 ` Karl Relton
@ 2013-01-24 16:09 ` Karl Relton
0 siblings, 0 replies; 5+ messages in thread
From: Karl Relton @ 2013-01-24 16:09 UTC (permalink / raw)
To: linux-usb, linux-bluetooth
On Thu, 2013-01-24 at 13:58 +0000, Karl Relton wrote:
> On Tue, 2013-01-15 at 20:27 +0000, Karl Relton wrote:
> > > The end result (for the user) is that even when the bluetooth
> > > mouse/keyboard is re-added, Xorg ignores it - thinking it is some
> > hoax
> > > duplicate device. The keyboard/mouse is then non-operational.
> > >
> >
> > Instrumenting the code suggests that the issue arises in a race
> > between:
> >
> > hidp_session() in bluetooth/hidp/core.c
> >
> > and
> >
> > hci_unregister_dev() in bluetooth/hci_core.c
> >
> >
...
> >
> > I can't figure out why there is such a delay for
> > input_unregister_device().
>
>
> The power_supply system seems to be triggering a lookup of battery
> 'capacity' in the input device. This calls into the driver, which deep
> down invokes more code in the 'hidp' module: hidp_get_raw_report()
>
> This function tries to communicate with the bluetooth device (keyboard
> in my case), but because the device is being 'torn down' such
> communication fails. Accordingly hidp_get_raw_report has a 5 second
> timeout ... so this function stalls for 5 seconds until that timeout
> occurs.
>
>
> I would guess that for some reason, removing the 'hid' or associated
> 'input' device is leading to the power_supply code wanting to lookup the
> battery capacity which introduces a 5 second wait. This would delay
> hidp_session by 5 seconds ... in the mean time allowing
> hci_unregister_dev() to win the race and hence the hci device is removed
> before the input & hid devices.
>
device_del is done on the battery device, called from
hidinput_cleanup_battery in hid-input.c.
This will generate a uevent which has the power_supply attributes added,
which invokes power_supply_show_property for 'capacity' which invokes
the hidp_get_raw_report (which stalls for 5 seconds).
Back in the days of linux 3.2, hid-input.c did not have any support for
batteries, so this chain of calls was never made, hence the race was won
by hidp_session() because it didn't have the 5 second delay injected.
Now with battery support added, the problem is manifest.
--
I think hidp_get_raw_report should abort if the devices is being 'torn
down' (and so not go into the 5 second wait). But also the race between
the two functions needs sorting, since sooner or later someone else will
get unlucky.
^ permalink raw reply [flat|nested] 5+ messages in thread
* usb device removed from sysfs before input children devices
@ 2013-01-08 14:33 Karl Relton
0 siblings, 0 replies; 5+ messages in thread
From: Karl Relton @ 2013-01-08 14:33 UTC (permalink / raw)
To: linux-usb, linux-bluetooth
On coming out of suspend my usb bluetooth adaptor is being reset by the
system.
In linux 3.7 the usb devices are being removed from the sysfs tree
first, and then the various 'child' devices (like my bluetooth mouse &
keyboard related devices) afterwards. This is causing the udev events
for the input devices to have 'orphaned' sysfs paths in the udev events.
This in turn means the Xorg evdev driver does not recognise the events,
and so doesn't see the removal of the input devices.
This has been picked by some downstream distributions, e.g. see this
thread by Google Chrome developers:
http://code.google.com/p/chromium-os/issues/detail?id=33813
Back on linux 3.2 this was not the case. The usb adaptor was reset, but
device removal was orderly: first the input devices (will full paths in
the udev events), then the usb devices walking up the tree.
To illustrate the issue, here is the output of 'udevadm monitor' in 3.7:
udevadm monitor
monitor will print the received events for:
KERNEL - the kernel uevent
KERNEL[2203.173080] remove /devices/pci0000:00/0000:00:1a.0/usb3/3-2/3-2:1.0/bluetooth/hci0/rfkill2 (rfkill)
KERNEL[2203.173148] remove /devices/pci0000:00/0000:00:1a.0/usb3/3-2/3-2:1.0/bluetooth/hci0 (bluetooth)
KERNEL[2203.173420] remove /devices/pci0000:00/0000:00:1a.0/usb3/3-2/3-2:1.0 (usb)
KERNEL[2203.173451] remove /devices/pci0000:00/0000:00:1a.0/usb3/3-2/3-2:1.1 (usb)
KERNEL[2203.173475] remove /devices/pci0000:00/0000:00:1a.0/usb3/3-2/3-2:1.2 (usb)
KERNEL[2203.173693] remove /devices/pci0000:00/0000:00:1a.0/usb3/3-2 (usb)
KERNEL[2213.152339] remove /hci0/hci0:46/input14/mouse2 (input)
KERNEL[2213.160374] remove /hci0/hci0:46/input14/event10 (input)
KERNEL[2213.168366] remove /hci0/hci0:46/input14 (input)
KERNEL[2213.169058] remove /hci0/hci0:46/0005:050D:0031.0005/hidraw/hidraw0 (hidraw)
KERNEL[2213.169198] remove /hci0/hci0:46/0005:050D:0031.0005 (hid)
KERNEL[2213.169242] remove /hci0/hci0:46 (bluetooth)
KERNEL[2218.176527] remove /hci0/hci0:49/input13/event11 (input)
KERNEL[2218.180403] remove /hci0/hci0:49/input13 (input)
KERNEL[2218.180481] remove /hci0/hci0:49/0005:05AC:0256.0004/hidraw/hidraw1 (hidraw)
KERNEL[2218.180538] remove /hci0/hci0:49/0005:05AC:0256.0004 (hid)
KERNEL[2218.182005] remove /hci0/hci0:49 (bluetooth)
See how the usb devices are moved first, and then the input/bluetooth related stuff
with path-heads removed (paths are now /hci0/... instead of /devices/...)
Here is the equiv sequence back in 3.2:
KERNEL[158.378301] remove /devices/pci0000:00/0000:00:1a.0/usb3/3-2/3-2:1.0/bluetooth/hci0/hci0:49/input11/mouse2 (input)
KERNEL[158.388283] remove /devices/pci0000:00/0000:00:1a.0/usb3/3-2/3-2:1.0/bluetooth/hci0/hci0:49/input11/event11 (input)
KERNEL[158.409885] remove /devices/pci0000:00/0000:00:1a.0/usb3/3-2/3-2:1.0/bluetooth/hci0/hci0:49/input11 (input)
KERNEL[158.411565] remove /devices/pci0000:00/0000:00:1a.0/usb3/3-2/3-2:1.0/bluetooth/hci0/hci0:49/0005:050D:0031.0002/hidraw/hidraw1 (hidraw)
KERNEL[158.411598] remove /devices/pci0000:00/0000:00:1a.0/usb3/3-2/3-2:1.0/bluetooth/hci0/hci0:49/0005:050D:0031.0002 (hid)
KERNEL[158.411621] remove /devices/pci0000:00/0000:00:1a.0/usb3/3-2/3-2:1.0/bluetooth/hci0/hci0:49 (bluetooth)
KERNEL[158.436894] remove /devices/pci0000:00/0000:00:1a.0/usb3/3-2/3-2:1.0/bluetooth/hci0/hci0:46/input10/event10 (input)
KERNEL[158.452211] remove /devices/pci0000:00/0000:00:1a.0/usb3/3-2/3-2:1.0/bluetooth/hci0/hci0:46/input10 (input)
KERNEL[158.452628] remove /devices/pci0000:00/0000:00:1a.0/usb3/3-2/3-2:1.0/bluetooth/hci0/hci0:46/0005:05AC:0256.0001/hidraw/hidraw0 (hidraw)
KERNEL[158.452662] remove /devices/pci0000:00/0000:00:1a.0/usb3/3-2/3-2:1.0/bluetooth/hci0/hci0:46/0005:05AC:0256.0001 (hid)
KERNEL[158.452752] remove /devices/pci0000:00/0000:00:1a.0/usb3/3-2/3-2:1.0/bluetooth/hci0/hci0:46 (bluetooth)
KERNEL[158.629847] remove /devices/pci0000:00/0000:00:1a.0/usb3/3-2/3-2:1.0/bluetooth/hci0/rfkill2 (rfkill)
KERNEL[158.629920] remove /devices/pci0000:00/0000:00:1a.0/usb3/3-2/3-2:1.0/bluetooth/hci0 (bluetooth)
KERNEL[158.635562] remove /devices/pci0000:00/0000:00:1a.0/usb3/3-2/3-2:1.0 (usb)
KERNEL[158.635701] remove /devices/pci0000:00/0000:00:1a.0/usb3/3-2/3-2:1.1 (usb)
KERNEL[158.635807] remove /devices/pci0000:00/0000:00:1a.0/usb3/3-2/3-2:1.2 (usb)
KERNEL[158.637238] remove /devices/pci0000:00/0000:00:1a.0/usb3/3-2 (usb)
The end result (for the user) is that even when the bluetooth
mouse/keyboard is re-added, Xorg ignores it - thinking it is some hoax
duplicate device. The keyboard/mouse is then non-operational.
Karl
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2013-01-24 16:09 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-01-09 19:27 usb device removed from sysfs before input children devices Karl Relton
2013-01-15 20:27 ` Karl Relton
2013-01-24 13:58 ` Karl Relton
2013-01-24 16:09 ` Karl Relton
-- strict thread matches above, loose matches on Subject: below --
2013-01-08 14:33 Karl Relton
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).