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

[Luis]

On 9/25/06, Tim Dijkstra <newsuser at famdijkstra.org> wrote:
> 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.

more fun and games... I'll hunt them with diff -burN then...

> > [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'm glad to see vmware is doing its job for you! I can't live without
virtualization now ;-)

Why do you think that the parent Splashy process never seems to exit?
if you look at splashy_main.c, it supposed to fork() and return and
let the child do it's job in a way that the terminal can't control it.
pstree shows all the processes spawn'd by Splashy from initramfs...
weird.

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

Ouch. This needs to be backported pronto. Or, the F2 (verbose stuff)
should be turned off in .2 before release. Otavio what's your take on
this? The stuff is ugly anyway and it's not working as it should. The
textbox and everything else is very well done (thanks to the Xandros
people of course) and works fine for other things (like printing
messages to the screen). I'll try to re-work this a bit and turn it
all off since you already figure it out. We will work on this for .4.

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

usplash talks about SVGA issues (svgalib) when running from initramfs.
Something about svgalib handling of signals. Perhaps when we tell
directfb to ignore all signals we do not handle something correctly
causing this problem? I'll revisit the way we handle signals now that
initramfs is out of the way.

> > 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;)

Thanks. At least I have a (real) SMP system with a ton of RAM to burn! (1.5Gig)

:-P

-- 
----)(-----
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