-----BEGIN PGP SIGNED MESSAGE----- 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHrsAnOjLpvpq7dMoRAlcJAJ9PbZubniFyFq+4hgs5vJBPvG+3VgCghw4z 7skXKx7BSJSsgTRGg02R5oI= =9PbX -----END PGP SIGNATURE-----
