Bug 62041 - bluetooth HID power_supply devices get duplicated on auto-suspend
Summary: bluetooth HID power_supply devices get duplicated on auto-suspend
Status: NEW
Alias: None
Product: Drivers
Classification: Unclassified
Component: Input Devices (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: drivers_input-devices
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-09-24 14:56 UTC by Martin Pitt
Modified: 2013-09-24 14:56 UTC (History)
1 user (show)

See Also:
Kernel Version: 3.10.0
Subsystem:
Regression: No
Bisected commit-id:


Attachments
udevadm monitor of devices suspends/resumes (56.00 KB, text/plain)
2013-09-24 14:56 UTC, Martin Pitt
Details

Description Martin Pitt 2013-09-24 14:56:37 UTC
Created attachment 109541 [details]
udevadm monitor of devices suspends/resumes

In https://launchpad.net/bugs/1112907/ and https://bugzilla.redhat.com/show_bug.cgi?id=962080 we get lots of reports of crashing upower when a bluetooth mouse or battery resumes from (what I presume) is auto-suspend, or a similar kind of reduced power state on inactivity. The upower crash is related to the fact that all of a sudden a second power_supply child on that device gets created, without the first one disappearing.

Initially, there are several devices associated with the mouse/keyboard:

/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.4/1-1.4:1.0/bluetooth/hci0/
   hci0:11 (bluetooth)
   hci0:11/input13 (input; plus its children like "event13" and "mouse2")
   hci0:11/0005:0D62:0558.0001 (hid)
   hci0:11/0005:0D62:0558.0001/hidraw/hidraw0 (hidraw)
   hci0:11/0005:0D62:0558.0001/power_supply/hid-00:0f:f6:6d:8e:c0-battery (power_supply)

When these devices get suspended, all of these get a "remove" uevent and go away, *except* the last one (power_supply). When the device resumes, they come back (with add uevents), except that "hci0:11" now becomes "hci0:12" for the hidraw device, and  the sequence number after the MAC increases (:0558.0001 -> :0558.0002) (but the hci0:NN stays the same (!) for power_supply).

So at that point you now have a new set of bluetooth/hid/event devices, which is fine:

  hci0:12 (bluetooth)
  hci0:12/input14
  hci0:12/0005:0D62:0558.0002 (hid)
  hci0:12/0005:0D62:0558.0002/hidraw/hidraw0 (hidraw)

But you have two power_supply devices:

  hci0:11/0005:0D62:0558.0001/power_supply/hid-00:0f:f6:6d:8e:c0-battery
  hci0:11/0005:0D62:0558.0002/power_supply/hid-00:0f:f6:6d:8e:c0-battery

On the next suspend/resume that goes on, so eventually you have a large number of these power_supply devices of which all but the most recent ones are dead. Also, presumably they ought to get attached to the new hci0:NN device instead of the old hci0:11 which already went away?

So the bug is that the old power_supply devices never get a remove event and  get cleaned up. I'm less sure about the seemingly wrong hci0:NN number, but that seems related and it would be odd to keep around the old hci0:11 when all other devices off it are already gone.

I attach a complete "udevadm monitor -e --udev" log which illustrates what's going on in detail.

Note that I don't have such a device myself, but I can relay requests for information etc. to the original downstream bugs and ask reporters.

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