Neo Freerunner PMU Status

Andy Green andy at
Sun Feb 10 10:13:12 CET 2008

Hash: SHA1

Somebody in the thread at some point said:

> no, you misunderstood me.  your fix to not send SIGPWR in case there
> actually is power provided via USB is obviously correct.
> However, this SIGPWR-to-garbage-collector can still happen, in the
> actual case of low battery voltage and no power being supplied via USB.

You're right about that, I was focussed on stopping my device dying in
boot with no battery, but it is still possible to have the bad behaviour
with a genuinely low battery at boot: thanks for pointing it out.

What I have done to "solve" this immediately is check that pid 1 exists
before issuing the signal.  It means that in the case where init starts
< 8 seconds since LOWBAT detected, init did not get a warning about
power loss.  But, if the guy pulls the battery by hand, or the battery
is so low it cannot maintain operation until the rootfs mounts and init
can start, init perforce does not get a warning about power loss either.
 So I think this is okay.

>> This issue belongs to nobody less than Linus I think -- I saw he wrote
>> the fork.c code that associates the signal with the kernel thread for
>> the garbage collection.  I think the issue is more correctly that the
>> process does not appear in the process table yet at the time it blows
>> chunks, therefore I guess it doesn't have ANY process ID.  Somehow it is
>> affected by pending signals to nonexistant pids.
> ;) well.  Sending it to Linus is probably a bit of an exaggeration. but
> lkml is fine, certainly.

Yeah I didn't mean to bother him directly about it :-)  Just I am
worrying the answer will be "why the hell are you sending a signal to a
pid that doesn't exist -- of course the behaviour is undefined" -- but
of course there is a case that it shouldn't do what it does do right now
however you look at it.

But according to the existing fork.c logic I cut and pasted, if it did
correctly direct the signal, that "fix" will get us to "Failed to fork
*init*: Error 513" --> "Panic".  So we need to check for pid #1 presence
anyway before firing the signal, removing the issue for us.

- -Andy
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora -


More information about the openmoko-kernel mailing list