-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Somebody in the thread at some point said: > On Fri, Feb 08, 2008 at 11:36:38AM +0000, Andy Green wrote: > >> Ha -- looks like the PCF50633 "LOWBAT" interrupt service tries always to >> do kill_proc(1, SIGPWR, 1); when LOWBAT really means *NO*BAT -- it kills >> the garbage collection fork stone dead when it tries to start instead >> and finds that signal waiting there. I guess the GTA01 PMU driver did >> the same... > > Yes. This is the desired behaviour. Traditionally, unix power failures > are signalled to the init process by means of SIGPWR. Even 20-30 year > old code can deal with that :)
It's really the desired behaviour that if we don't have a battery in this device it tries to kill init? I don't think I desire it -- I want the device to stay up without a battery so long as I give it power another way (patches coming). > Now the question is rather: why is that garbage collection thread using > PID 1. It shouldn't do that, since that PID is reserved for init and > nothing else. > > It's probably worth pushing this question to linux-mtd and/or dwmw2 > directly. 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. - -Andy -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHrHlIOjLpvpq7dMoRAgyVAKCAJPXTqPGar7fKpoPw0MfZc5hKMwCfZW+A IrSLzrtKq5xdwvaj+l5guLo= =a1fY -----END PGP SIGNATURE-----
