Bug 727717
| Summary: | Gnome 3 Battery status icon / Upowerd problem | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Nicholai Cornilliac <nmcunix> | ||||||||||||
| Component: | kernel | Assignee: | John Feeney <jfeeney> | ||||||||||||
| Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||||||
| Severity: | high | Docs Contact: | |||||||||||||
| Priority: | unspecified | ||||||||||||||
| Version: | 15 | CC: | aquini, borysjr, gansalmon, itamar, jonathan, kernel-maint, madhu.chinakonda, martin.wilck, rhughes, richard, r_wellington | ||||||||||||
| Target Milestone: | --- | ||||||||||||||
| Target Release: | --- | ||||||||||||||
| Hardware: | i686 | ||||||||||||||
| OS: | Linux | ||||||||||||||
| Whiteboard: | |||||||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||||||
| Doc Text: | Story Points: | --- | |||||||||||||
| Clone Of: | Environment: | ||||||||||||||
| Last Closed: | 2012-07-11 17:54:02 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
Nicholai Cornilliac
2011-08-03 02:07:27 UTC
Can you try (as root) killall upowerd /usr/libexec/upowerd --verbose And then try to reproduce the problem. You should get a whole heap of debugging data, in which case please attach it to this bug. Thanks. Created attachment 516514 [details]
/usr/libexec/upowerd --verbose
This is a kernel problem; /sys/devices/LNXSYSTM:00/device:00/PNP0C0A:00/power_supply/BAT0 is being removed and re-added over and over again. Reassigning. I suspect a start would be to get the output of acpidump from pmtools. also, does this still happen with 2.6.40.3 ? Yes, it does still happen with 2.6.40.3 if im doing the acpidump, would you like the output in hex or binary ? Just run acpidump without any arguments. Created attachment 521065 [details]
acpidump
here is the output from my acpidump
Hi, I have the same problem. Using Fedora 15 (fresh install, fully updated), HP Compaq 615 laptop. I'll add my output also. Ty. Hi, I have the same problem. Using Fedora 15 (fresh install, fully updated), HP Compaq 615 laptop. I'll add my output also. Ty. Seeing a similar thing here on a Fujitsu laptop (ESPRIMO Mobile M9400). upowerd constanly consuming 50% CPU (i.e. 1 full CPU core). This happened to me the first time today, apparently after running out of battery in a conference call and plugging the laptop back into AC power. This made GNOME3 totally unresponsive. On the text console and under GNOME2 legacy mode with Compiz, working was possible. gdm login was extremely sluggish (close to unusable), thus I'm working from a GNOME2 legacy session started via startx now. Created attachment 580504 [details]
/var/lib/upower/history-charge-Modelxxx-57.dat
This upowerd history file shows that, similar to what was stated in BZ before, the battery seems to disappear and reappear again.
I've been running Fedora on this laptop since F13, (F16 for about 3 months), and this never happened to me before (fortunately, because it's easily one of the most annoying things that ever happened to me using Linux). This problem wouldn't even go away by power-cycling the machine.
While I'm typing this, upowerd seems to have settled down. I'll try logging in with GNOME3 again. See what happens.
Looking at the kernel code in acpi_battery_update(), there are 2 code paths where sysfs_remove_battery() / sysfs_add_battery() is called. The first is in acpi_battery_update(), when the battery_present bit (0x10) returned by the _STA method of the battery device changes. This could be caused by hardware or firmware defects - at least the acpidump of comment #9 and from my own laptop suggest that the return value is dynamic and dependent on some registers of the embedded controller. However this degree of broken-ness seems pretty unlikely on various laptops of well-known manufacturers. Does it really make sense to tie the presence of the entire sysfs directory to the "battery present" bit? The second is acpi_battery_refresh(), which is called whenever a ACPI_BATTERY_NOTIFY_INFO event is received (indicating that *static* battery info has changed). If such events happen often (I guess if that happens, it would also indicate a firmware problem) the sysfs dir might be removed and re-added frequently. It might by better to check whether re-adding is really necessary (i.e if the power_unit of the battery device changed). Created attachment 580520 [details]
tentative patch for the acpi_battery_refresh() case
This is just to illustrate my thoughts on the second possible reason why the sysfs directory keeps being removed and re-added.
Created attachment 580521 [details]
strace of upowerd
This strace (captured while I was seeing the problem) demonstrates that /sys/devices/LNXSYSTM:00/device:00/PNP0C0A:00/power_supply/BAT0/ actually goes away and reappears. It also shows that upowerd seems to read the sysfs files many times in a row in a very short timespan, indicating room for improvement in that area as well.
Fedora 15 has reached it's end of life as of June 26, 2012. As a result, we will not be fixing any remaining bugs found in Fedora 15. In the event that you have upgraded to a newer release and the bug you reported is still present, please reopen the bug and set the version field to the newest release you have encountered the issue with. Before doing so, please ensure you are testing the latest kernel update in that release and attach any new and relevant information you may have gathered. Thank you for taking the time to file a report. We hope newer versions of Fedora suit your needs. |