Bug 806295
Summary: | 3.3.0-4.fc16.x86_64 is FUBAR on imac 27" which now thinks it has a battery. | ||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Andrew Walrond <andrew> | ||||||||||||
Component: | upower | Assignee: | Richard Hughes <hughsient> | ||||||||||||
Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||||||
Severity: | urgent | Docs Contact: | |||||||||||||
Priority: | unspecified | ||||||||||||||
Version: | 17 | CC: | bugzilla, dantti12, gansalmon, hughsient, ikke, itamar, jfeeney, jonathan, kazimieras.vaina, kernel-maint, kevin, madhu.chinakonda, rhughes, vitor.dominor | ||||||||||||
Target Milestone: | --- | Keywords: | Reopened | ||||||||||||
Target Release: | --- | ||||||||||||||
Hardware: | x86_64 | ||||||||||||||
OS: | Linux | ||||||||||||||
Whiteboard: | |||||||||||||||
Fixed In Version: | kernel-2.6.43.2-6.fc15 | Doc Type: | Bug Fix | ||||||||||||
Doc Text: | Story Points: | --- | |||||||||||||
Clone Of: | Environment: | ||||||||||||||
Last Closed: | 2013-08-01 17:05:09 UTC | Type: | --- | ||||||||||||
Regression: | --- | Mount Type: | --- | ||||||||||||
Documentation: | --- | CRM: | |||||||||||||
Verified Versions: | Category: | --- | |||||||||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||||||||
Embargoed: | |||||||||||||||
Attachments: |
|
Description
Andrew Walrond
2012-03-23 11:41:01 UTC
Can you install the pmtools package and attach the output of the acpidump command (when run as root)? Created attachment 572320 [details]
Output of acpidump as root
Sure thing - see attachment.
Thanks! Any chance you can get dmesg for the broken case? Created attachment 572329 [details]
dmesg from broken kernel
Dmesg output as requested
The battery is coming from your wireless keyboard. What desktop environment are you running? Can you also get the output of "upower --dump" -- Thanks. I'm running default fedora gnome 3 environment. I'll grab the upower output when I get to the office in the morning. Enjoy your Friday evenings :) PS it is rather amusing that my iMac thinks it's running off the AA batteries in the Bluetooth keyboard! No wonder it panicked! :) Created attachment 572418 [details]
sudo upower --dump
Here you go
Urgh:
> power supply: yes
What does "ls /sys/devices/pci0000:00/0000:00:1a.7/usb1/1-1/1-1.1/1-1.1.1/1-1.1.1:1.0/bluetooth/hci0/hci0:12/0005:05AC:030D.0004/power_supply/hid-10:9A:DD:76:0A:5A-battery" and "cat /sys/class/power_supply/BAT0/type" say?
Thanks,
Richard
andrew@golden ~ $ ls -l /sys/devices/pci0000:00/0000:00:1a.7/usb1/1-1/1-1.1/1-1.1.1/1-1.1.1:1.0/bluetooth/hci0/hci0:12/0005:05AC:030D.0004/power_supply/hid-10:9A:DD:76:0A:5A-battery total 0 -r--r--r--. 1 root root 4096 Mar 26 09:45 capacity lrwxrwxrwx. 1 root root 0 Mar 26 09:47 device -> ../../../0005:05AC:030D.0004 -r--r--r--. 1 root root 4096 Mar 26 09:45 model_name -r--r--r--. 1 root root 4096 Mar 26 09:47 online drwxr-xr-x. 2 root root 0 Mar 26 09:47 power -r--r--r--. 1 root root 4096 Mar 26 09:45 present -r--r--r--. 1 root root 4096 Mar 26 09:45 status lrwxrwxrwx. 1 root root 0 Mar 26 09:45 subsystem -> ../../../../../../../../../../../../../../class/power_supply -r--r--r--. 1 root root 4096 Mar 26 09:45 type -rw-r--r--. 1 root root 4096 Mar 26 09:45 uevent andrew@golden ~ $ cat /sys/class/power_supply/BAT0/type cat: /sys/class/power_supply/BAT0/type: No such file or directory andrew@golden ~ $ cat /sys/class/power_supply/hid-10\:9A\:DD\: hid-10:9A:DD:76:0A:5A-battery/ hid-10:9A:DD:91:97:30-battery/ andrew@golden ~ $ cat /sys/class/power_supply/hid-10\:9A\:DD\:76\:0A\:5A-battery/type Battery andrew@golden ~ $ cat /sys/class/power_supply/hid-10\:9A\:DD\:91\:97\:30-battery/type Battery andrew@golden ~ $ *** Bug 809279 has been marked as a duplicate of this bug. *** Richard, Matthew, I'm not sure this is a kernel bug. The kernel is just reporting a battery state for a HIDE device, which seems perfectly reasonable to me. Should this be moved to upower? For now, I disabled CONFIG_HID_BATTERY_STRENGTH in the f15/f16 kernels. Matthew suggested we move this bug to F17 as there are kernel and upower patches needed to properly support this. I've pushed this to upower: commit 28c8653ed8d43bfdcac4bb09c0fe16b5ac124668 Author: Richard Hughes <richard> Date: Wed Apr 18 16:46:41 2012 +0100 Never detect HID devices with batteries as power supplies Some HID devices with batteries (like bluetooth keyboards) have been creating power supply devices in sysfs since Linux 3.3. UPower thinks that they are system devices and shuts down the system if they get low. This is bad. This is fixed in Linux 3.4, where there is a new 'scope' file that defines if the device is powering the system. Helpfully ACPI batteries don't populate the scope value, but soon will. Add support for the scope attribute now, and default to system devices if it's missing. Note, you need to be running a 3.4 kernel or a 3.3 with the patch backported for this to work. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=806295 (In reply to comment #15) > I've pushed this to upower: > > commit 28c8653ed8d43bfdcac4bb09c0fe16b5ac124668 > Author: Richard Hughes <richard> > Date: Wed Apr 18 16:46:41 2012 +0100 > > Never detect HID devices with batteries as power supplies Will a upower package with that commit get pushed to Fedora? If so, which branches? (In reply to comment #16) > Will a upower package with that commit get pushed to Fedora? If so, which > branches? Yup, I'm planning to to a release upstream this week after someone has tested that patch with mjg's new kernel. I'll push it to F17 and rawhide, but I can do F16 as well if you want. (In reply to comment #17) > (In reply to comment #16) > > Will a upower package with that commit get pushed to Fedora? If so, which > > branches? > > Yup, I'm planning to to a release upstream this week after someone has tested > that patch with mjg's new kernel. I'll push it to F17 and rawhide, but I can do > F16 as well if you want. OK. I think F17 and rawhide are probably just fine. I've already disabled the config option on F16 so it won't help there and I'll look at backporting the changes from 3.4 to F17 later this week. Thanks. kernel-2.6.43.2-6.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/kernel-2.6.43.2-6.fc15 Package kernel-2.6.43.2-6.fc15: * should fix your issue, * was pushed to the Fedora 15 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing kernel-2.6.43.2-6.fc15' as soon as you are able to, then reboot. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-6406/kernel-2.6.43.2-6.fc15 then log in and leave karma (feedback). Presumably the fc16 kernel will also be forthcoming soon? (In reply to comment #21) > Presumably the fc16 kernel will also be forthcoming soon? http://koji.fedoraproject.org/koji/buildinfo?buildID=314510 It's set to hit f16-updates on the next push. I didn't include this bug number on the bodhi update for f16 because I didn't want bodhi to auto-close the bug. It still needs work for F17. kernel-2.6.43.2-6.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report. I thought I'd seen the back of this, but then I upgraded to F17... (In reply to comment #24) > I thought I'd seen the back of this, but then I upgraded to F17... Oops. Yeah, comment #22 clearly says it needs more work in F17. Fortunately, F17 will be rebased to 3.4.x hopefully today. Got 3.4 from testing this morning and all is well again. What changed? I assume the kernel now presents modified information to upower. Is this a permanent and complete fix or is there more to do? (In reply to comment #26) > Got 3.4 from testing this morning and all is well again. > > What changed? I assume the kernel now presents modified information to > upower. 3.4 has additional commits to provide scope for the sysfs battery information. > Is this a permanent and complete fix or is there more to do? As soon as 3.4 hits F17 stable updates, it will be permanent. There's nothing more to do from what I remember. I'll mark this bug in the 3.4 update so it gets closed by Bodhi. kernel-3.4.0-1.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/FEDORA-2012-8824/kernel-3.4.0-1.fc17 kernel-3.4.0-1.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report. My Imac's ghostly laptop battery is back :( I've got testing updates enabled, so hopefully we can fix it before it reaches the main repo? I think it arrived during a yum update yesterday, although I can't be certain since I only just noticed it this morning. Let me know what info you need. I assume you're running the latest upower update already. does upower --dump look any different from last time ? $ upower --version UPower client version 0.9.17 UPower daemon version 0.9.17 $ sudo upower --dump Device: /org/freedesktop/UPower/devices/battery_hid_10o9AoDDo76o0Ao5A_battery native-path: /sys/devices/pci0000:00/0000:00:1a.7/usb1/1-1/1-1.1/1-1.1.1/1-1.1.1:1.0/bluetooth/hci0/hci0:12/0005:05AC:030D.0005/power_supply/hid-10:9A:DD:76:0A:5A-battery power supply: no updated: Wed Aug 8 14:31:51 2012 (5 seconds ago) has history: yes has statistics: yes battery present: yes rechargeable: yes state: empty energy: 0 Wh energy-empty: 0 Wh energy-full: 0 Wh energy-full-design: 0 Wh energy-rate: 0 W percentage: 0% capacity: 100% Daemon: daemon-version: 0.9.17 can-suspend: yes can-hibernate yes on-battery: no on-low-battery: no lid-is-closed: no lid-is-present: no is-docked: no to clarify, is this actually causing a problem like it was before ? from the looks of things, it's just reporting that there's a battery, which is expected. The 'on-battery: no' seems to suggest it's working. Richard ? AIUI, the version of upower in F16 does not support this kernel feature, and as per comment #15, it used to be disabled in F16 kernels, apparently this was lost in the 3.3 rebase. Sorry, as per comment #14, I mean. (In reply to comment #34) > AIUI, the version of upower in F16 does not support this kernel feature, and > as per comment #15, it used to be disabled in F16 kernels, apparently this > was lost in the 3.3 rebase. I doubt it. 3.4 works fine and that is what F16 is on still. 3.5 seems to be the kernel causing this to reappear based on other bug reports, but that is only in F17. My guess would be Andrew is on F17 now. Either way, answering Dave's question would be good. I'm using 17 (and this entry is marked as such) although these issues seem well travelled ;) You are right of course; this new issue is of lesser importance since my machine does not seem to be considered as 'on battery' and shutting down at random intervals as before. However, it's not strictly 'right' since 1) Gnome reports a 'laptop battery, 0%' 2) Upower reports a rechargeable battery - which it/they are not - disposable AAs 3) Where is the other one? There were two reported before; I have both bt keyboard and mouse. I suspect upower needs to walk the sysfs path to figure out what the battery belongs to so that it can give it a better name than 'laptop battery'. After another upgrade last night I now have both bluetooth device batteries showing up in upower and gnome. Now if we can just get the names right it will all be tickety boo! $ sudo upower -d Device: /org/freedesktop/UPower/devices/battery_hid_10o9AoDDo91o97o30_battery native-path: /sys/devices/pci0000:00/0000:00:1a.7/usb1/1-1/1-1.1/1-1.1.1/1-1.1.1:1.0/bluetooth/hci0/hci0:11/0005:05AC:023A.0004/power_supply/hid-10:9A:DD:91:97:30-battery model: Apple Wireless Keyboard power supply: no updated: Sun Aug 12 08:53:11 2012 (18 seconds ago) has history: yes has statistics: yes battery present: yes rechargeable: yes state: discharging energy: 0 Wh energy-empty: 0 Wh energy-full: 0 Wh energy-full-design: 0 Wh energy-rate: 0 W percentage: 0% capacity: 100% History (charge): 1344757956 0.000 unknown History (rate): 1344757956 0.000 unknown Device: /org/freedesktop/UPower/devices/battery_hid_10o9AoDDo76o0Ao5A_battery native-path: /sys/devices/pci0000:00/0000:00:1a.7/usb1/1-1/1-1.1/1-1.1.1/1-1.1.1:1.0/bluetooth/hci0/hci0:14/0005:05AC:030D.0006/power_supply/hid-10:9A:DD:76:0A:5A-battery model: andrewwalronds mouse power supply: no updated: Sun Aug 12 08:53:11 2012 (18 seconds ago) has history: yes has statistics: yes battery present: yes rechargeable: yes state: discharging energy: 0 Wh energy-empty: 0 Wh energy-full: 0 Wh energy-full-design: 0 Wh energy-rate: 0 W percentage: 40% capacity: 100% History (charge): 1344757958 40.000 discharging 1344757956 0.000 unknown History (rate): 1344757956 0.000 unknown Daemon: daemon-version: 0.9.17 can-suspend: yes can-hibernate yes on-battery: no on-low-battery: no lid-is-closed: no lid-is-present: no is-docked: no I'm experiencing what looks like a related problem since 3.5.1-1.fc17, not sure whether to open separate bug or not. System shows Rocketfish BT mouse battery, goes to some sort of sleep state (NOT hibernate as set in power settings) when inactive for some period. When awakened, mouse is not responsive. I've stumbled on the awkward workaround that CTRL-ALT-F2 to a console session and back restores mouse function. upower -d is similar to above. Dmesg shows this after such an event: [151821.493051] power_supply hid-00:02:76:10:B5:D8-battery: driver failed to report `capacity' property: -5 [154466.699370] hid-generic 0005:19FF:0207.000F: unknown main item tag 0x0 [154466.717698] input: Rocketfish Apple Bluetooth Mouse as /devices/pci0000:00/0000:00:1d.2/usb7/7-2/7-2:1.0/bluetooth/hci0/hci0:11/input29 [154466.718269] hid-generic 0005:19FF:0207.000F: input,hidraw0: BLUETOOTH HID v2.45 Mouse [Rocketfish Apple Bluetooth Mouse] on 00:24:7E:17:7D:98 Will post further info here if requested, otherwise will open new bug. Picked up kernel-3.5.2-1.fc17.x86_64 on a yum update, and two things happened that I noticed: 1) gnome power manager now shows a percentage remaining for the Rocketfish batteries 2) The mouse no longer gets lost after a sleep/quasi-sleep (In reply to comment #39) > After another upgrade last night I now have both bluetooth device batteries > showing up in upower and gnome. > > Now if we can just get the names right it will all be tickety boo! > > $ sudo upower -d > Device: /org/freedesktop/UPower/devices/battery_hid_10o9AoDDo91o97o30_battery > native-path: > /sys/devices/pci0000:00/0000:00:1a.7/usb1/1-1/1-1.1/1-1.1.1/1-1.1.1:1.0/ > bluetooth/hci0/hci0:11/0005:05AC:023A.0004/power_supply/hid-10:9A:DD:91:97: > 30-battery > model: Apple Wireless Keyboard > power supply: no > updated: Sun Aug 12 08:53:11 2012 (18 seconds ago) > has history: yes > has statistics: yes > battery > present: yes > rechargeable: yes > state: discharging > percentage: 0% > capacity: 100% Hi, I wrote the kernel patch that probes these devices, tho most of the issues said here are userland issues I noticed this output which might need fixing. Some Apple keyboards have wrong info in their descriptions, which is the case of my keyboard but not my magic track pad, so in order to improve the system we need to add quirks to the kernel. Can you please say if with an used battery the percentage is still 0% ? if so can you give use the lsinput info of your keyboard? - The mouse is just fine... Thanks. Hi, my keyboard is doing this on fedora 17. It trashes the log with: ----------------------------- [349847.631435] power_supply hid-7C:C3:A1:XX:XX:XX-battery: driver failed to report `capacity' property: -5 ----------------------------- ----------------------------- $ upower --dump Device: /org/freedesktop/UPower/devices/battery_hid_7CoC3oA1oXXoXXoXX_battery native-path: /sys/devices/pci0000:00/0000:00:16.0/usb7/7-4/7-4:1.0/bluetooth/hci0/hci0:11/0005:05AC:0256.0003/power_supply/hid-7C:C3:A1:XX:XX:XX-battery model: Apple Wireless Keyboard power supply: no updated: Mon Oct 22 12:52:30 2012 (0 seconds ago) has history: yes has statistics: yes battery present: yes rechargeable: yes state: discharging energy: 0 Wh energy-empty: 0 Wh energy-full: 0 Wh energy-full-design: 0 Wh energy-rate: 0 W percentage: 0% capacity: 100% Device: /org/freedesktop/UPower/devices/battery_hid_60oC5o47o82oC6o3E_battery native-path: /sys/devices/pci0000:00/0000:00:16.0/usb7/7-4/7-4:1.0/bluetooth/hci0/hci0:12/0005:05AC:030E.0004/power_supply/hid-60:C5:47:XX:XX:XX-battery model: Apple Wireless Trackpad power supply: no updated: Mon Oct 22 12:52:09 2012 (21 seconds ago) has history: yes has statistics: yes battery present: yes rechargeable: yes state: discharging energy: 0 Wh energy-empty: 0 Wh energy-full: 0 Wh energy-full-design: 0 Wh energy-rate: 0 W percentage: 19% capacity: 100% Daemon: daemon-version: 0.9.17 can-suspend: yes can-hibernate yes on-battery: no on-low-battery: no lid-is-closed: no lid-is-present: no is-docked: no ----------------------------- It seems there are several tickets open related to the same issue. At least: 812625, 830046, 845770, 806295, 863524 @Ilkka Tengvall Can you please attach the lsinput output, there are some devices that do not report the correct info about how to grab the information, resulting in the error you get, in those cases I need to add a quirk to the kernel, I just need to make sure you are having the same case.. Created attachment 632549 [details]
lsinput with apple bt trackpad and keyboard
Daniel, here's the lsinput info.
(In reply to comment #45) > Created attachment 632549 [details] > lsinput with apple bt trackpad and keyboard > > Daniel, here's the lsinput info. Thanks, can you also attach the file /sys/kernel/debug/hid/[YOUR DEVICE]/rdesc, and also confirm that killing upower, then upower -d never shows the correct percentage of the keyboard? Created attachment 632695 [details]
rdesc for apple bt keyboard
$ sudo service upower stop
Redirecting to /bin/systemctl stop upower.service
$ ps -ef |grep u[p]owe
$
$ upower -d
Device: /org/freedesktop/UPower/devices/battery_hid_7CoC3oA1o98o49oD6_battery
native-path: /sys/devices/pci0000:00/0000:00:16.0/usb7/7-4/7-4:1.0/bluetooth/hci0/hci0:11/0005:05AC:0256.0003/power_supply/hid-7C:C3:A1:98:49:D6-battery
model: Apple Wireless Keyboard
power supply: no
updated: Wed Oct 24 14:33:34 2012 (0 seconds ago)
has history: yes
has statistics: yes
battery
present: yes
rechargeable: yes
state: discharging
energy: 0 Wh
energy-empty: 0 Wh
energy-full: 0 Wh
energy-full-design: 0 Wh
energy-rate: 0 W
percentage: 0%
capacity: 100%
History (charge):
1351078414 0.000 unknown
History (rate):
1351078414 0.000 unknown
btw, gnome3 shows the red battery sign on the panel, and tells I have two laptop batteries on my desktop PC (apple kb&mouse). The trackpad mouse charge level there is ok, 14%, but keyboard shows 0%, and at least I'm typing this with it... (In reply to comment #48) > btw, gnome3 shows the red battery sign on the panel, and tells I have two > laptop batteries on my desktop PC (apple kb&mouse). The trackpad mouse > charge level there is ok, 14%, but keyboard shows 0%, and at least I'm > typing this with it... Thanks, your device is "broken" like mine, so a kernel patch is needed. INPUT(71)[INPUT] Field(0) Logical(GenericDesktop.Keyboard) Application(Consumer.0001) Usage(1) GenericDeviceControls.BatteryStrength Logical Minimum(0) Logical Maximum(255) Report Size(8) Report Count(1) Report Offset(0) Flags( Variable Absolute ) Instead if INPUT it should report as FEATURE, and Logical Maximum (255) should be (100). the problem is providing a patch so you could test :/ I'm having the same issue with Fedora 18 (3.8.x kernel series) and a low-end bluetooth mouse. The upower reports an additional battery and following messages appear in dmesg: power_supply hid-00:60:D1:01:B1:02-battery: driver failed to report `capacity' property: -5 It also often prevents mouse from functioning - mouse is connected, but mouse cursor does not move on the screen. I need to reconnect the mouse several times to get it working. As a workaround I recompiled the kernel with CONFIG_HID_BATTERY_STRENGTH disabled and it's all ok now. 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. |