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

[Tim Dijkstra]

Op Mon, 25 Sep 2006 10:15:13 -0400
schreef Luis <lemsx1 at gmail.com>:

> 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.

Yes Makefile.am, but also files in debian/ . I don't remember know
precisely which. I also changed the files in scripts/. Did I remove
the lsb_end_msg branch already? The 0.3 has newer scripts.

> [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 tried debugging this a while ago, didn't have vmware yet so I
had to reboot a lot ... bit painful. Also vmware is still a bit slow
on my machine, which makes debugging this no fun.
Anyway, IIRC, I tried with the minimal number of threads. No sockets,
no keyboard, no nothing. Still splashy took 100%.

> I'll hunt this down tonite. 

I really hope you find it.

> 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. 

As I said above, I don't think so... about the socket code. In the 0.3 \
branch I redid it a bit, it's much cleaner now. I'll see if I can find
some time tonight to port it to 0.2. BTW, I also fixed a nasty bug which
still is in the 0.2 branch. The F2-textbox would open lots of /dev/vcs* 
which would make splashy hit the maximum number of fd limit. I hoped
that that was the fix, but alas, it was not.

> This might not be what does this problem though. I
> have a feeling that it can be the keyboard event thread.

My gut says it is in directfb...

> 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

Yes me too, dunno unfortunately...

> [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.
> 

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

Well, have fun rebooting your vmware;)

grts Tim