Bug 806295

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.