B2G mis-interpretes absence of battery as a low-battery condition

RESOLVED INACTIVE

Status

()

Core
Hardware Abstraction Layer (HAL)
RESOLVED INACTIVE
5 years ago
2 days ago

People

(Reporter: bjacob, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

STR:

- take an Otoro phone
- remove battery
- boot, running on USB power
- it will reboot/poweroff due to what it mis-interpretes as a low-battery condition.

JS stack:

I/Gecko   (  329): 0 sm_startPowerOff() ["app://system.gaiamobile.org/js/sleep_menu.js":219]
I/Gecko   (  329):     this = [object Object]
I/Gecko   (  329): 1 bm_checkBatteryDrainage() ["app://system.gaiamobile.org/js/battery_manager.js":29]
I/Gecko   (  329):     this = [object Object]
I/Gecko   (  329): 2 bm_init() ["app://system.gaiamobile.org/js/battery_manager.js":38]
I/Gecko   (  329):     this = [object Object]
I/Gecko   (  329): 3 <TOP LEVEL> ["app://system.gaiamobile.org/js/battery_manager.js":277]
I/Gecko   (  329):     this = [object Window]
I/Gecko   (  329):

See bug 839452 for context.
What does /sys/class/power_supply/battery/status return when the phone has no battery?
(Reporter)

Comment 2

5 years ago
Removed battery, rebooted (adb reboot), ./run-gdb.sh attach. When it broke:

$ adb shell cat /sys/class/power_supply/battery/status
Charging
(Reporter)

Comment 3

5 years ago
...and same result starting with a completely unplugged phone.
And /sys/class/power_supply/battery/capacity ?
I wouldn't be surprised if that's 0.

FWIW, the author of the Gonk backend for the Battery API never cared about the case of no battery. The backend never check that and I was hoping that somehow "/sys/class/power_supply/battery/" wouldn't exist. It seems that "/sys/class/power_supply/battery/present" could be used but doing a hot unplug of my battery didn't update the value of that file. I can't boot the phone without a battery for the moment. If it seems to work, I could try to write a patch.
(Reporter)

Comment 5

5 years ago
$ adb shell cat /sys/class/power_supply/battery/capacity
1
(In reply to Benoit Jacob [:bjacob] from comment #5)
> $ adb shell cat /sys/class/power_supply/battery/capacity
> 1

1 or 0 is the same given that it is likely low enough to get the system to shutdown.

Did you check "/sys/class/power_supply/battery/present"?
On my otoro, /sys/class/power_supply/battery/present is always 1, even with the battery removed. Same on unagi.
Created attachment 718960 [details] [diff] [review]
Check presence of battery

Here is a patch for testing the presence of the battery. As I mentioned, the respective value is always 1, so it doesn't really solve the problem. But it might work in the future.
Attachment #718960 - Flags: feedback?(mounir)
Comment on attachment 718960 [details] [diff] [review]
Check presence of battery

We shouldn't land something that we know doesn't work, this is going to mislead developers.

Could that problem be on a lower level? Who is responsible to update the /present file? The kernel?
Attachment #718960 - Flags: feedback?(mounir) → feedback-
Yes. And the kernel comes from the phone vendors. CC'ing cjones, maybe he can help.
The Michaels may be able to offer advice too.

Comment 12

5 years ago
(In reply to Thomas Zimmermann [:tzimmermann] from comment #10)
> Yes. And the kernel comes from the phone vendors. CC'ing cjones, maybe he
> can help.

As I knew that battery present is dependent on detecting of battery ID and it is done by kernel driver or AMSS from modem processor (report to linux kernel via RPC)
For v1.0.1 devices, iirc the lack of a battery really isn't a valid operating mode.   Ideally the bootloader would just block this from occurring.    That's why we need to power down the device when the battery is low even with USB power applied.
Component: General → Hardware Abstraction Layer (HAL)
Product: Firefox OS → Core
Duplicate of this bug: 779016

Comment 15

2 days ago
Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.
Status: NEW → RESOLVED
Last Resolved: 2 days ago
Resolution: --- → INACTIVE
You need to log in before you can comment on or make changes to this bug.