Created attachment 583333 [details] dmesg output showing oops Description: A kernel oops can be provoked by: 1. Associating with a Bluetooth mouse (via Blueman). 2. Opening the mouse's back cover, forcibly disconnecting the battery. 3. Attaching the cover again, reconnecting the battery. Don't know if there are any more-generic circumstances to generate this, but the above is repeatable on my machine. Various warnings are generated, followed by an oops: [ 195.959372] WARNING: at fs/sysfs/dir.c:481 sysfs_add_one+0xca/0x100() [ 195.959377] Hardware name: A15A/HE/HC [ 195.959381] sysfs: cannot create duplicate filename '/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.0/bluetooth/hci0/hci0:21' [ 195.959921] kobject_add_internal failed for hci0:21 with -EEXIST, don't try to register things with the same name in the same directory. [ 195.960237] Bluetooth: Failed to register connection device [ 200.705653] power_supply hid-00:12:A1:68:7D:2C-battery: driver failed to report `capacity' property: -5 [ 205.697963] power_supply hid-00:12:A1:68:7D:2C-battery: driver failed to report `capacity' property: -5 [ 205.722100] BUG: unable to handle kernel NULL pointer dereference at 0000000000000079 [ 205.722283] IP: [<ffffffff811ed2d5>] sysfs_create_dir+0x35/0xc0 The Bluetooth mouse no longer works until reboot. Full session dmesg attached. Package versions: kernel-3.3.5-2.fc17.x86_64 (-- will test with earlier kernel shortly) bluez-4.99-1.fc17.x86_64
Can confirm same results with 3.3.4-4.fc17.x86_64. Don't need to pop the batteries to generate this. Simply power cycling the mouse with its switch causes the oops.
Additional notes: - Can reproduce on another machine running i686 version of the kernel. Both machines have ath3k Bluetooth dongle. - CANNOT reproduce on a Fedora 16 box with kernel-3.3.4-3.fc16.x86_64 bluez-4.96-3.fc16.x86_64 that has a Cambridge Silicon dongle.
(In reply to comment #2) > Additional notes: > > - Can reproduce on another machine running i686 version of the kernel. > Both machines have ath3k Bluetooth dongle. > > - CANNOT reproduce on a Fedora 16 box with > kernel-3.3.4-3.fc16.x86_64 This is probably due to F17 having CONFIG_HID_BATTERY_STRENGTH enabled, whereas it is disabled for f15 and f16. Seems the code isn't particularly robust at the moment.
Jeremy, have you seen something like this while working on the HID_BATTERY_STRENGTH stuff?
No, I've not seen this, but clearly there's some problem with managing the sysfs entries. Would the power supply links be preventing the sysfs entry from being removed on poweroff, causing the duplicate entry when it comes back? (I've seen the "driver failed to report `capacity' property: -5" messages before; it seems fetching the capacity can be quite flakey, but I don't think they're related to the rest.)
(In reply to comment #5) > Would the power supply links be preventing the sysfs entry from > being removed on poweroff, causing the duplicate entry when it comes back? To be specific, could the reporter check to see if the entries are removed after turning off the device, before turning it back on?
(In reply to comment #6) > To be specific, could the reporter check to see if the entries are removed > after turning off the device, before turning it back on? Sure -- can you confirm which paths (with patterns if necessary) I should check?
Well, /sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.0/bluetooth/hci0/hci0:21 (from the message) would be a good start, though its possible it might be different if your devices move around a bit after reboot or something. You could 1) get a full listing of /sys/devices before you connect the mouse, 2) connect it and check to see what changed, 3) disconnect it, and see how it differs from step 1 and 2.
Right, getting that data. One extra note: I think it depends on switching off and on quickly enough, like within 1-2 seconds.
OK, so: 1. Mouse initially not connected: hci0/hci0:21 not there. 2. Mouse connected: hci0/hci0:21 appears. 3. Mouse switched off. <1s later, hci0/hci0:21 is still there. 4. Mouse quickly switched back on again as above, oops happens. (Presumably hci0/hci0:21 still there at this point.) hci0/hci0:21 no longer there.
Seems this, or something similar, has been known about since at least November: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/888828 which mentions some discussion and patches: http://www.spinics.net/lists/linux-bluetooth/msg15564.html http://www.spinics.net/lists/linux-bluetooth/msg15598.html http://www.spinics.net/lists/linux-bluetooth/msg16303.html
*** Bug 818791 has been marked as a duplicate of this bug. ***
Any further movement on this? I think this has been reported in upstream kernel bugzilla: [1] looks similar (but has been around since August last year). [1] https://bugzilla.kernel.org/show_bug.cgi?id=41632
I'm currently using a kernel based on the kernel-3.4.2-4.fc17 sources from Koji and am no longer able to reproduce this bug. Can anyone else?
This bug has reappeared in kernel-3.5.0-2.fc17.x86_64 which seems to re-enable reporting of BT mouse battery status. dmesg attached.
Created attachment 602234 [details] dmesg output following power-cycling bluetooth mouse
Disabling CONFIG_HID_BATTERY_STRENGTH and rebuilding prevents this bug... seems that all is not well with this, any chance it could be disabled again until it sits nicely with Bluetooth?
Jeremy, have you seen any sort of regression with the battery strength stuff upstream? We've had it enabled on F17 the entire release and the issues we initially saw went away with 3.4 and a upower that understood the scoping stuff.
I haven't seen any problems like that with my F17 setup, but it looks like upowerd isn't honouring scope properly.
Still present with kernel-3.5.2-3.fc17.x86_64. Still have to rebuild to avoid the inevitable oops.
I think I ran into the same problem: https://bugzilla.redhat.com/show_bug.cgi?id=868604 I am trying kernel with CONFIG_HID_BATTERY_STRENGTH disabled.
*** Bug 868604 has been marked as a duplicate of this bug. ***
(In reply to comment #19) > I haven't seen any problems like that with my F17 setup, but it looks like > upowerd isn't honouring scope properly. I'm not sure how upowerd would cause the oops being seen here. The sysfs files are created internally in the kernel.
This message is a reminder that Fedora 17 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 17. 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 '17'. 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 17'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 17 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, you are encouraged change the 'version' to a later Fedora version prior to Fedora 17's end of life. 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.
Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.