[Splashy-devel] Splashy: initramfs done (?)

[Luis]

On 9/25/06, Tim Dijkstra <newsuser at famdijkstra.org> wrote:
> Op Mon, 25 Sep 2006 01:51:59 -0400
> schreef Luis <lemsx1 at gmail.com>:
[snip]
> > 4. cp scripts/splashy-update-progress-steps to /etc/init.d
> > and do: update-rc.d splashy-update-progress-steps stop 01 0 6 .
>
> The packaging for the 0.3 branch does this (points 2,3 and 4) already.
> Have a look in 0.3/debian.
>

Are you talking about Makefile.am? I'll have a look at it in branch
0.3. I haven't been paying attention to it because I didn't want to
deviate from having .2 released.

[snip]

> > 2. splashy uses almost 100% of the CPU during boot. i still don't know
> > why is this, but that only happens from initramfs
>
> Hmm, I hurrayed to early :( This is what I saw a few weeks ago. I
> thought this was the infamous 'initramfs bug'...

When we used to run splashy from initramfs (before
keymap/console-screen created problem for us), we never saw Splashy
taking 100% of the CPU.
Now, we have had this problem before, where Splashy just starts
chewing CPU cycles like crazy. I'll look at the notes in the code to
see where this problems usually happens. But, I'm affraid it has to do
with a part of the code that's polling for something (be it keyboard
events or the network socket). I'll hunt this down tonite. From what
you remember, did you put a *yield* CPU clause of some kind in the
stuff that reads events from the UNIX socket? I have to become
familiar with your socket's code to see if this perhaps introduced
this situation. This might not be what does this problem though. I
have a feeling that it can be the keyboard event thread.

I wish there was a way to name the threads so that when you do: ps ax
| grep splashy. they show something like:

splashy:keyboard
splashy:progress
splashy:main
...
etc

There is also the main splashy process that's supposed to fork(), go
into the background and exit and let it's child (now parentless) run
on its own without attachments to the console (daemon-mode).

[snip]
> > if runlevel is S
> >   see if splashy is not running and launch it with boot as argument,
> >   then exit (because the filesystem is probably read-only and we
> > can't calculate the progress steps needed, as they need to be saved
> > in /lib/splashy/*)
>
> This (5) is also done in the 0.3 three branch.

I'll merge this too.

> > I hope I'm not missing something here. I'll add more as we go. If we
> > get these minor issues resolved, we can release splashy as 0.2 and
> > move on with life.
>
> I think there still is the major issue of splashy taking 100% CPU when
> launched from initramfs. This is really a show-stopper. On my machine
> it adds 90s to the boottime.

ouch

> Unfortunately I don't have time to work on this the coming time, but
> I think debugging should concentrate on this. The other issues are
> already done in 0.3 or should have a quick fix. I'm really stumped
> about the 100% CPU thing. If somebody has time, he/she should try to
> run a very simple directfb program (that only draws a picture on the
> screen) from initramfs to see if it is the directfb library that
> creates the problem.

cool. I'll concentrate on fixing the 100% issue. The fun thing is that
the app runs fine from outside initramfs.

Fun and Games...

-- 
----)(-----
Luis Mondesi
*NIX Guru

Kiskeyix.org

"We think basically you watch television to turn your brain off, and
you work on your computer when you want to turn your brain on" --
Steve Jobs in an interview for MacWorld Magazine 2004-Feb

No .doc: http://www.gnu.org/philosophy/no-word-attachments.es.html