[Splashy-devel] Initramfs bug understood

[Luis Mondesi]

On 9/30/07, Tim Dijkstra <newsuser at famdijkstra.org> wrote:
>
> On Sat, 29 Sep 2007 22:08:14 -0400
> "Luis Mondesi" <lemsx1 at gmail.com> wrote:
>
> >
> > We just need to yield the CPU from the keyboard even thread. That
> > fixes the CPU issue and the booting from initramfs issue.
> >
> > The only problem is that the ESC key is not handled when booting from
> > initramfs. I'll ask in the directfb-users list to see if i get an
> > answer.
>
> So, to summarize:
>
> If we start from initramfs
>         => it takes tty2
>                 => directfb looses keyboard


The keyboard gets "lost" when init starts (when the progressbar starts to
grow in Splashy). If you hit ESC as soon as Splashy starts, the keyboard
listening code is still working. We need to figure out why this is
happening. My guess is that since Splashy was launched on a different
environment (root tree), when the switch to a new root (real root tree)
happens, the other files are marked as "deleted" (this is what lsof shows
during boot). So directfb is trying to read from a console that is marked as
deleted. Perhaps the real solution is to never close the listening device
once directfb opens it; that way the kernel marks it as "deleted" but there
is a process still "listening" from it. Again, this is just me taking wild
guesses that match the behavior that I see.

                        => keyboard thread goes haywire


yep. thread goes into a tight while loop that never ends.


> Solutions
> 1) Make keyboard thread shed some cycles.
>         => Drawback: we don't have keyoard


Well, this solution makes the CPU issue alleviate. We loose the keyboard
regardless of what method we choose (use a different tty or patch directfb
to shed some CPU cycles).


> 2) Make directfb use another tty.
>         -> Drawback: ?


CPU still goes to 99% when you do this alone. And in fact, this is not
needed since we skip execution of console-screen.sh until Splashy is
finished. So, the boot process is never stopped (like it used to before that
you had to go to TTY2 and hit ENTER to move on).

Is this summary correct?
>
> Why don't we do solution 2?


Yep. That's correct. But like I said before, solution 2 is not a solution
for Debian (Sid). That solution works for RPath Linux and perhaps other
distros. In Debian, all we need is to yield the CPU at the keyboard thread
level.

Regards,

-- 
----)(-----
Luis Mondesi
Maestro Debiano

----- START ENCRYPTED BLOCK (Triple-ROT13) ------
Gur Hohagh [Yvahk] qvfgevohgvba oevatf gur fcvevg bs Hohagh gb gur fbsgjner
jbeyq.
----- END ENCRYPTED BLOCK (Triple-ROT13) ------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.alioth.debian.org/pipermail/splashy-devel/attachments/20070930/d1de016d/attachment.htm