False OnBattery detection

[Traveller]

After upgrading to mprime 25.7, I am having a problem under Linux (best verified on Kubuntu 8.10 i386).

The communication with the server works and all the assignments transferred, but the worker thread will not stay running. It stops with a message about being on battery power. Nothing else happens no matter what I do. The OS is responding properly to on/off battery events.

The workaround I have is to set the RunOnBattery=1 in local.txt,

Any ideas? I haven't found any reference to this in my archive searches.

Thanks,
Traveller

[Uncwilly]

This was one of the issues that George had wanted tested for v25.7. No one every gave him an answer.

[S00113]

Originally Posted by Uncwilly

This was one of the issues that George had wanted tested for v25.7. No one every gave him an answer.

Yes, I did

[Traveller]

Originally Posted by S00113

Yes, I did

Only I am having the opposite issue. I have to force mprime to RunOnBattery to get it to stay running when plugged in. However, I agree with the dynamic throttling based on temperature.

[starrynte]

Originally Posted by Traveller

I agree with the dynamic throttling based on temperature.

seconded! though I want it in prime95

[Prime95]

Can you Linux users tell me what /proc/acpi/battery/BAT0/state contains?
My research says this is where Linux stores the battery state.

[Traveller]

Originally Posted by Prime95

Can you Linux users tell me what /proc/acpi/battery/BAT0/state contains?
My research says this is where Linux stores the battery state.

Fully charged on AC:
present: yes
capacity state: ok
charging state: charged
present rate: 1 mA
remaining capacity: 7800 mAh
present voltage: 12513 mV

On Battery:
present: yes
capacity state: ok
charging state: discharging
present rate: 371 mA
remaining capacity: 6667 mAh
present voltage: 12388 mV

Back on AC, charging:
present: yes
capacity state: ok
charging state: charging
present rate: 1849 mA
remaining capacity: 6149 mAh
present voltage: 12731 mV

I have also seen the present rate display 'unknown', but that shouldn't affect the needs of the mprime program.

I hope that helps,
Traveller

[Prime95]

Thanks. That is what I was expecting. Re-re-examining the code has uncovered my bug. Will be fixed in 25.8.

[sichase]

I'm running v25.7 build 3 under Windows MP and have also noticed a false onBattery situation. I have two workers running on my dual-core T7300, and after removing power cable only one worker went into Battery Pause. The other kept running. After recabling the power, both workers toggled so that the other worker was then in an incorrect Battery Pause. Repeated toggling of the power state repeatedly toggled both workers until I exited and restarted Prime95. Just thought you should know...

--Scott

[Traveller]

I just tested mprime version 25.8.2 on my Kubuntu 8.10 i386 laptop.

I can now run mprime without the RunOnBattery=1 that was needed before. However, it is still not detecting the battery status when I pull the plug and continues to run.

The change in sense from Not Running to Running reduces the severity of this issue for me.

Let me know if you need any additional information.

Thanks,
Traveller

Running 25.7 on a Windows XP laptop, the typical 2-processor kind of thing everyone is buying now.

When the power cable is unplugged, both clients correctly always stop. When the power cable is plugged back in, sometimes but not always, only one client will resume and the other will continue to think it is on battery pause forever. Unplugging and replugging the power cable again always restarts both of them.

Mostly I notice it if I accidentally snag the cord and plug it back in. I have one client running trial factoring and the other running LL tests. It is either always or almost-always the LL test client that fails to restart.

Speculation: if the cord is unplugged and replugged within the space of a couple seconds, the LL test client is busy shutting down and writing results at the time the AC power comes back on. Easy fix by having it re-check the power state after it finishes shutting down, or by holding the restart-the-client message in a queue if the client is busy when the message is sent, maybe?