Description of problem: After pairing an Apple wireless keyboard with my F18 laptop, the keyboard stops working after a short period of time and thousands of error messages appear in my /var/log/messages file: Jan 24 12:42:47 localhost kernel: [ 1275.514563] power_supply hid-44:2A:60:E0:63:97-battery: driver failed to report `capacity' property: -5 The messages appear at the rate of about a hundred per second. Version-Release number of selected component (if applicable): Fedora 18 Linux localhost.localdomain 3.7.2-204.fc18.x86_64 #1 SMP Wed Jan 16 16:22:52 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux How reproducible: Every time the keyboard is paired, even with a new set of batteries. Steps to Reproduce: 1. Pair keyboard 2. Wait for it to stop working 3. Watch thousands of messages scroll by in /var/log/messages Actual results: Errors and no BT keyboard. Expected results: Functional BT keyboard. Additional info: Unassociating the keyboard makes the errors stop.
Same problem here with exactly same symptoms and the latest kernel 3.7.4-204.fc18.x86_64.
Potential duplicate of Bug 845770, though this may be hardware-specific.
Are you still seeing this on 3.8.x?
Yes, the huge stream of errors is still there with the latest Fedora kernel. # uname -a Linux localhost.localdomain 3.8.4-202.fc18.x86_64 #1 SMP Thu Mar 21 17:02:20 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux ... Apr 4 11:15:40 localhost kernel: [ 2537.952362] power_supply hid-44:2a:60:e0:63:97-battery: driver failed to report `capacity' property: -5 Apr 4 11:15:40 localhost kernel: [ 2537.958598] power_supply hid-44:2a:60:e0:63:97-battery: driver failed to report `capacity' property: -5 Apr 4 11:15:40 localhost kernel: [ 2537.963450] power_supply hid-44:2a:60:e0:63:97-battery: driver failed to report `capacity' property: -5 Apr 4 11:15:40 localhost kernel: [ 2537.969745] power_supply hid-44:2a:60:e0:63:97-battery: driver failed to report `capacity' property: -5 Apr 4 11:15:40 localhost kernel: [ 2537.974788] power_supply hid-44:2a:60:e0:63:97-battery: driver failed to report `capacity' property: -5 Apr 4 11:15:45 localhost kernel: [ 2542.962310] power_supply hid-44:2a:60:e0:63:97-battery: driver failed to report `capacity' property: -5 ...
Josh, I still see this with 3.9.5-301.fc19.x86_64 - any ideas? This is especially annoying because of journald logging in F19: it uses CPU time and eats the battery like crazy as soon as I connect BT keyboard and /var/log/messages starts growing > 100MB/h !
Exactly the same problem here with 3.9.5-201.fc18.x86_64
Please attach the dmesg output from a fresh boot. Basically, something in userspace is reading the capacity sysfs file for the device repeatedly, and the device is returning EIO.
Benjamin, if all the reporters here are using bluetooth keyboards (Apple or otherwise), perhaps they need some entries into hid_battery_quirks to get their capacity status reported correctly?
David Herrmann did a lot of cleanup in hidp (hid over bluetooth) in 3.10. I think it would worth trying a 3.10-rc and see if these errors are still happening. As for the hid_battery_quirks, maybe, but it would be handsome to have the hidreplay[1] dump to understand if they are required (though most of apple devices has some quirks). [1] http://bentiss.github.io/hid-replay-docs/
Created attachment 762793 [details] boot messages
Unfortunately I cannot have a clean dmesg, since the moment I login the dmesg output is full with the 'capacity' error messages. I've attached a clean copy of the /var/log/messages after boot. Maybe it is helpful. I've installed also the hidreplay. I have 4 /dev/hidraw* devices corresponding to the Apple keyboard. However only the last one gives me some output from the keyboard. And most bizarre is the 3rd one which is connected with the USB cord-mouse. (I don't have BT mouse) sudo hid-recorder /dev/hidraw1 R: 75 05 01 09 06 a1 01 05 07 19 e0 29 e7 15 00 25 01 75 01 95 08 81 02 95 01 75 08 81 01 05 08 19 01 29 05 95 05 75 01 91 02 95 01 75 03 91 01 05 07 19 00 2a ff 00 95 05 75 08 15 00 26 ff 00 81 00 05 ff 09 03 75 08 95 01 81 02 c0 N: Apple Inc. Apple Keyboard P: usb-0000:00:1a.0-1.1/input0 I: 3 05ac 0250 ^C No events where recorded. You may need to add the option "--debugfs" to get more recordings. sudo hid-recorder /dev/hidraw2 R: 47 05 0c 09 01 a1 01 05 0c 75 01 95 01 15 00 25 01 09 cd 81 06 09 b5 81 02 09 b6 81 02 09 b8 81 06 09 e2 81 06 09 ea 81 02 09 e9 81 02 81 01 c0 N: Apple Inc. Apple Keyboard P: usb-0000:00:1a.0-1.1/input1 I: 3 05ac 0250 ^C No events where recorded. You may need to add the option "--debugfs" to get more recordings. ---------> The /dev/hidraw3 is linked with the mouse!!!! It reports events only when I move the USB mouse. The mouse is not Bluetooth! $ sudo hid-recorder /dev/hidraw3 R: 52 05 01 09 02 a1 01 09 01 a1 00 05 09 19 01 29 05 15 00 25 01 95 05 75 01 81 02 95 01 75 03 81 01 05 01 09 30 09 31 09 38 15 81 25 7f 75 08 95 03 81 06 c0 c0 N: Apple Inc. Apple Keyboard P: usb-0000:00:1a.0-1.1/input2 I: 3 05ac 0250 E: 0.000000 4 00 ff 00 00 <---- Mouse motion E: 0.007989 4 00 fa 01 00 E: 0.015989 4 00 f4 01 00 E: 0.023992 4 00 f2 02 00 E: 0.031992 4 00 f0 03 00 E: 0.039985 4 00 f1 06 00 E: 0.047988 4 00 f0 08 00 E: 0.055988 4 00 f0 08 00 E: 0.063991 4 00 f0 0b 00 E: 0.072034 4 00 f2 09 00 E: 0.079976 4 00 f6 0a 00 E: 0.087993 4 00 f8 08 00 E: 0.095977 4 00 fd 05 00 E: 0.103989 4 00 fe 05 00 E: 0.111982 4 00 00 02 00 E: 0.255991 4 00 00 ff 00 E: 0.263994 4 00 01 00 00 E: 0.335999 4 00 01 00 00 E: 0.343994 4 00 00 ff 00 E: 1.183991 4 00 01 ff 00 E: 1.191990 4 00 01 ff 00 E: 1.199988 4 00 01 ff 00 E: 1.207992 4 00 03 fe 00 And the last one is the one giving me events when I use the keyboard sudo hid-recorder /dev/hidraw4 R: 225 05 01 09 06 a1 01 85 01 05 07 19 e0 29 e7 15 00 25 01 75 01 95 08 81 02 75 08 95 01 81 01 75 01 95 05 05 08 19 01 29 05 91 02 75 03 95 01 91 01 75 08 95 06 15 00 26 ff 00 05 07 19 00 2a ff 00 81 00 c0 05 0c 09 01 a1 01 85 47 05 01 09 06 a1 02 05 06 09 20 15 00 26 ff 00 75 08 95 01 81 02 c0 c0 05 0c 09 01 a1 01 85 11 15 00 25 01 75 01 95 03 81 01 75 01 95 01 05 0c 09 b8 81 02 06 ff 00 09 03 81 02 75 01 95 03 81 01 05 0c 85 12 15 00 25 01 75 01 95 01 09 cd 81 02 09 b3 81 02 09 b4 81 02 09 b5 81 02 09 b6 81 02 81 01 81 01 81 01 85 13 15 00 25 01 75 01 95 01 06 01 ff 09 0a 81 02 06 01 ff 09 0c 81 22 75 01 95 06 81 01 85 09 09 0b 75 08 95 01 b1 02 75 08 95 02 b1 01 c0 00 N: Apple Wireless Keyboard P: 00:19:0e:11:03:8f I: 5 05ac 0256 E: 0.000000 9 01 00 00 28 00 00 00 00 00 E: 0.017557 9 01 00 00 00 00 00 00 00 00 E: 3.554934 9 01 00 00 04 00 00 00 00 00 aE: 3.583653 9 01 00 00 04 16 00 00 00 00 sE: 3.743679 9 01 00 00 04 16 07 00 00 00 dE: 3.832422 9 01 00 00 07 16 00 00 00 00 E: 3.833795 9 01 00 00 07 00 00 00 00 00 E: 3.883670 9 01 00 00 00 00 00 00 00 00 E: 3.907433 9 01 00 00 0d 00 00 00 00 00 jE: 4.042443 9 01 00 00 0d 04 00 00 00 00 aE: 4.076149 9 01 00 00 0d 04 0b 00 00 00 hE: 4.079900 9 01 00 00 0b 04 00 00 00 00 E: 4.104774 9 01 00 00 0b 04 16 00 00 00 sE: 4.207373 9 01 00 00 16 04 00 00 00 00 E: 4.208704 9 01 00 00 16 04 07 00 00 00 dE: 4.242437 9 01 00 00 07 04 00 00 00 00 E: 4.254823 9 01 00 00 07 00 00 00 00 00 E: 4.317327 9 01 00 00 07 0d 00 00 00 00 jE: 4.332397 9 01 00 00 07 0d 0e 00 00 00 kE: 4.333668 9 01 00 00 0e 0d 00 00 00 00 E: 4.433671 9 01 00 00 0d 00 00 00 00 00 E: 4.435049 9 01 00 00 0d 0b 00 00 00 00 hE: 4.436174 9 01 00 00 0d 0b 04 00 00 00 aE: 4.437379 9 01 00 00 16 0b 04 00 00 00 sE: 4.493691 9 01 00 00 16 0b 04 07 00 00 dE: 4.494897 9 01 00 00 16 07 04 00 00 00 E: 4.547423 9 01 00 00 16 07 04 0e 00 00 kE: 4.548668 9 01 00 00 16 07 04 0e 0d 00 jE: 4.564925 9 01 00 00 0d 07 04 0e 00 00 E: 4.566174 9 01 00 00 0d 07 0e 00 00 00 E: 4.604808 9 01 00 00 0d 0e 00 00 00 00 E: 4.667350 9 01 00 00 0d 0e 0b 00 00 00 hE: 4.672382 9 01 00 00 0d 0b 00 00 00 00 E: 4.673678 9 01 00 00 0d 0b 04 00 00 00 aE: 4.675046 9 01 00 00 04 0b 00 00 00 00 E: 4.677394 9 01 00 00 04 0b 16 00 00 00 sE: 4.729800 9 01 00 00 04 0b 16 07 00 00 dE: 4.739932 9 01 00 00 04 07 16 00 00 00 E: 4.751152 9 01 00 00 04 07 16 0e 00 00 kE: 4.761176 9 01 00 00 04 07 16 0e 0d 00 jE: 4.792346 9 01 00 00 04 07 0d 0e 00 00 E: 4.797423 9 01 00 00 0e 07 0d 00 00 00 E: 4.823653 9 01 00 00 0e 0d 00 00 00 00 E: 4.907428 9 01 00 00 0e 0d 0b 00 00 00 hE: 4.908672 9 01 00 00 0b 0d 00 00 00 00 E: 4.909816 9 01 00 00 0b 00 00 00 00 00 E: 4.954806 9 01 00 00 00 00 00 00 00 00 E: 4.959943 9 01 00 00 16 00 00 00 00 00 sE: 4.969890 9 01 00 00 16 04 00 00 00 00 aE: 4.971147 9 01 00 00 16 04 07 00 00 00 dE: 5.079799 9 01 00 00 07 04 00 00 00 00 E: 5.084900 9 01 00 00 07 00 00 00 00 00 E: 5.086179 9 01 00 00 00 00 00 00 00 00
Vasilis: - the boot messages are clean. Thanks - the hid-recorder logs shows that you are in the same state than the others Apple keyboards: the report descriptor is declaring the battery as an input whereas it should be polled (with those keyboards) as a feature. - the 3 first hid-recorder messages are giving an USB physical path ("P: usb-0000:00:1a.0-1.1/input*"). So this is your mouse. Apple must use a common HID interface for its mice/keyboards, so no worries on this side. Josh, I think you are right, adding the appropriate quirk should do the trick. However, it looks like this problem is widely spread for bluetooth devices and we should tackle it earlier than adding per-device specific quirks. If we want to stick to the quirk solution, I bet that we should add the other Apple keyboards to have a more complete list: USB_DEVICE_ID_APPLE_ALU_WIRELESS_ANSI USB_DEVICE_ID_APPLE_ALU_WIRELESS_ISO USB_DEVICE_ID_APPLE_ALU_WIRELESS_JIS USB_DEVICE_ID_APPLE_ALU_WIRELESS_2009_ANSI USB_DEVICE_ID_APPLE_ALU_WIRELESS_2009_ISO USB_DEVICE_ID_APPLE_ALU_WIRELESS_2009_JIS USB_DEVICE_ID_APPLE_ALU_WIRELESS_2011_ANSI USB_DEVICE_ID_APPLE_ALU_WIRELESS_2011_ISO I was not able to find in the specs if this is a normal behaviour, so I asked Logitech as one of their device is also reporting problem in an other equivalent bug. I'm waiting for their answer.
I got the answer from one engineer of Logitech (please do not take this as an official Logitech communication): "Battery should normally be Input reports, which should be spontaneously reported by the device when there is a change in battery strength. The HID spec does not forbid to explicitly query an Input report, but it is not clear that this is/will be respected by all manufacturers. Using a Get Feature to get input reports does not look "standard" but it certainly seems possible. Looks it can certainly be device dependent." So basically, there is no proper way to fix the queries, it will be vendor dependent. I will try to do something to prevent the huge amount of queries when the device obviously does not answers the explicit requests.
Update: David Herrmann also investigate this. He wrote a patch [1] will will land in 3.11. This patch may not fix the not working bluetooth keyboard part of the bug, but it will at least stop the thousands of battery errors in the logs. [1] http://git.kernel.org/cgit/linux/kernel/git/jikos/hid.git/commit/?h=for-3.11/battery&id=d0a934b764c67b4bf626f5b7cf725a6e3066afd2
OK. We can add that patch for now. Do you think it's worth adding additional quirks for the apple bluetooth keyboards?
Thanks Josh for adding it. In the end, we need to add an additional quirk for this apple keyboard. I am not 100% sure we can introduce it for the others model as they are untested. I am trying to work on a solution to avoid the stall in the communication when probing for the battery, but I think the cure may be worse than the illness. So, for now, please add the quirks and we can close this bug (and many others reporting the "driver failed to report `capacity' property" log).
I added the patch. I skipped the quirks for now. I'd like to see if this solves the issue people are seeing first, and then a quirks patch can be pursued upstream.
I can confirm that on Fedora 19 with kernel-3.10.0-0.rc7.git0.2.fc20.x86_64 I don't get any driver failed to report `capacity' property in dmesg: [ 63.254112] apple 0005:05AC:0256.0004: unknown main item tag 0x0 [ 65.254685] Bluetooth: hci0 command 0x0804 tx timeout [ 68.252461] input: Apple Wireless Keyboard as /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.4/1-1.4:1.0/bluetooth/hci0/hci0:12/input19 [ 68.253199] apple 0005:05AC:0256.0004: input,hidraw1: BLUETOOTH HID v0.50 Keyboard [Apple Wireless Keyboard] on e4:d5:3d:cb:c3:f5 I only see every 30s in /var/log/messages after connecting Apple bluetooth keyboard: upowerd[830]: (upowerd:830): UPower-Linux-WARNING **: no voltage values, using 10V as approximation
Thank you for the patch. I am wondering if this patch will not leave the keyboard to sleep during inactive periods. Since it makes the request every 30s will it consume rapidly the battery?
Knowing if upowerd prevents the bluetooth device to enter its sleeping mode is a different topic. I am not a bluetooth guru, but this might be vendor dependent. I can easily imagine the device to stop monitoring the bluetooth link when it goes in sleep. So unless someone comes with figures, I will not investigate this because I don't have the hardware with me (and that's not my primary target). BTW, can you confirm that the keyboard is functional now with the patch? It was said to be broken in the opening message.
(In reply to Benjamin Tissoires from comment #20) > BTW, can you confirm that the keyboard is functional now with the patch? Yes, keyboard was fully functional with kernel-3.10.0-0.rc7.git0.2.fc20. Can we get this patch in the regular F19 kernel?
(In reply to Alan Pevec from comment #21) > (In reply to Benjamin Tissoires from comment #20) > > BTW, can you confirm that the keyboard is functional now with the patch? > > Yes, keyboard was fully functional with kernel-3.10.0-0.rc7.git0.2.fc20. > Can we get this patch in the regular F19 kernel? It's already committed there. Bodhi will leave the usual update messages in this bug when a build that contains it has been submitted as an update.
kernel-3.9.8-100.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/FEDORA-2013-9123/kernel-3.9.8-100.fc17
kernel-3.9.8-300.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/kernel-3.9.8-300.fc19
Package kernel-3.9.8-300.fc19: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing kernel-3.9.8-300.fc19' as soon as you are able to, then reboot. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-11901/kernel-3.9.8-300.fc19 then log in and leave karma (feedback).
kernel-3.9.8-200.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/kernel-3.9.8-200.fc18
kernel-3.9.8-100.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.
kernel-3.9.8-300.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
*** Bug 967326 has been marked as a duplicate of this bug. ***
*** Bug 966030 has been marked as a duplicate of this bug. ***
*** Bug 923615 has been marked as a duplicate of this bug. ***
kernel-3.9.9-201.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/kernel-3.9.9-201.fc18
kernel-3.9.9-201.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.