Neo Freerunner PMU Status

Andy Green andy at
Mon Feb 11 08:31:27 CET 2008

Hash: SHA1

Somebody in the thread at some point said:
> Harald Welte wrote:
>> 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.
> PID 1 is just the thread that starts the garbage collector, so this
> looks okay.

How does that work then because we didn't mount rootfs yet, JFFS2
garbage collector is a kernel thread whose footprint is in the
monolithic kernel.  Busybox init sure didn't spawn it... it must just
for accounting it marks it up as child of PID #1 when nothing real
occupies PID #1 yet.

> We could hack around the issue by blocking (parent) signals in
> jffs2_start_garbage_collect_thread or even kernel_thread.

No the fork.c code aborts the fork before anything gets going due to
signals pending too early, IIRC.  It certainly aborted it before it made
it to the process table, so I don't think we get to do anything in
jffs2_*().  Anyway this issue doesn't come from JFFS2, if that isn't the
first kernel thread to behave that way and get aborted, then we solved
nothing by that.

> And/or we could add a CLONE_ORPHAN flag indicate that we don't want the
> child to die just because the parent does. If this is implemented in
> copy_process, the flag would have to be stripped if coming from user
> space. If implemented in kernel_thread, it could just trigger blocking
> of parent signals.

What we really wanted was to let *busybox init* have an advance warning
of power loss so it can go down in an orderly way.  Maybe what we should
do instead if we have no external power, and we get LOWBAT and PID #1
doesn't exist is just turn ourselves off right there, because otherwise
we are hanging around bringing ourselves up just we can shut ourselves
down -- and we might not make it through all that because we have
genuine low battery!

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


More information about the openmoko-kernel mailing list