Bug 820321 - WARNING and OOPS following turning Bluetooth mouse off then on again
WARNING and OOPS following turning Bluetooth mouse off then on again
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
17
Unspecified Unspecified
unspecified Severity high
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
: 818791 868604 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-05-09 11:42 EDT by James
Modified: 2013-07-31 22:10 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-07-31 22:09:56 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
dmesg output showing oops (78.16 KB, text/x-log)
2012-05-09 11:42 EDT, James
no flags Details
dmesg output following power-cycling bluetooth mouse (88.59 KB, text/plain)
2012-08-04 05:45 EDT, James
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
Linux Kernel 45551 None None None 2012-08-04 18:53:23 EDT

  None (edit)
Description James 2012-05-09 11:42:58 EDT
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
Comment 1 James 2012-05-09 11:53:26 EDT
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.
Comment 2 James 2012-05-09 12:06:17 EDT
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.
Comment 3 Josh Boyer 2012-05-09 12:28:19 EDT
(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.
Comment 4 Josh Boyer 2012-05-09 12:31:30 EDT
Jeremy, have you seen something like this while working on the HID_BATTERY_STRENGTH stuff?
Comment 5 Jeremy Fitzhardinge 2012-05-09 12:50:05 EDT
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.)
Comment 6 Jeremy Fitzhardinge 2012-05-09 12:51:53 EDT
(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?
Comment 7 James 2012-05-09 12:56:51 EDT
(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?
Comment 8 Jeremy Fitzhardinge 2012-05-09 13:06:18 EDT
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.
Comment 9 James 2012-05-09 13:09:21 EDT
Right, getting that data. One extra note: I think it depends on switching off and on quickly enough, like within 1-2 seconds.
Comment 10 James 2012-05-09 13:14:40 EDT
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.
Comment 12 Justin M. Forbes 2012-05-10 18:26:39 EDT
*** Bug 818791 has been marked as a duplicate of this bug. ***
Comment 13 James 2012-05-18 16:41:26 EDT
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
Comment 14 James 2012-06-17 14:03:06 EDT
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?
Comment 15 James 2012-08-04 05:42:45 EDT
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.
Comment 16 James 2012-08-04 05:45:16 EDT
Created attachment 602234 [details]
dmesg output following power-cycling bluetooth mouse
Comment 17 James 2012-08-04 18:52:03 EDT
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?
Comment 18 Josh Boyer 2012-08-05 10:24:40 EDT
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.
Comment 19 Jeremy Fitzhardinge 2012-08-05 13:34:49 EDT
I haven't seen any problems like that with my F17 setup, but it looks like upowerd isn't honouring scope properly.
Comment 20 James 2012-08-24 12:44:58 EDT
Still present with kernel-3.5.2-3.fc17.x86_64. Still have to rebuild to avoid the inevitable oops.
Comment 21 H.J. Lu 2012-10-27 19:43:38 EDT
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.
Comment 22 Josh Boyer 2013-01-02 13:17:05 EST
*** Bug 868604 has been marked as a duplicate of this bug. ***
Comment 23 Josh Boyer 2013-01-02 13:18:54 EST
(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.
Comment 24 Fedora End Of Life 2013-07-03 19:27:43 EDT
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.
Comment 25 Fedora End Of Life 2013-07-31 22:10:01 EDT
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.

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