Bug 62041

Summary:	bluetooth HID power_supply devices get duplicated on auto-suspend
Product:	Drivers	Reporter:	Martin Pitt (martin.pitt)
Component:	Input Devices	Assignee:	drivers_input-devices
Status:	NEW ---
Severity:	normal	CC:	richard
Priority:	P1
Hardware:	All
OS:	Linux
Kernel Version:	3.10.0	Subsystem:
Regression:	No	Bisected commit-id:
Attachments:	udevadm monitor of devices suspends/resumes

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.