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.