[Splashy-devel] Initramfs bug understood

[Luis Mondesi]

On 9/29/07, Tim Dijkstra <newsuser at famdijkstra.org> wrote:
>
> On Fri, 28 Sep 2007 16:49:00 -0400
> "Luis Mondesi" <lemsx1 at gmail.com> wrote:
>
> > Elliot (from Rpath) made the patch they are using available to us. This
> is a
> > very simply 2 liner. I hope that this can help somebody out there get
> around
> > this problem.
> >
> > The other solution would be to switch to upstart ;-)
>
> IIRC, does have an option to not allocate a new VT. Can't we first
> switch VT to 17 and then start libdirectfb?
>
> Could you maybe try that Luis?


Yep. We tried that before. The problem is that  directfb does this:

1. opens /dev/tty0 (hard coded) (see dfb_vt_initialize() in
directfb-0.9.25.1/systems/fbdev/vt.c)
2. then it attempts to find a console available:  n = ioctl( dfb_vt->fd0,
VT_OPENQRY, &dfb_vt->num );
3. since we are launched from initramfs very early, tty2 is available and
directfb attaches to that (I'd say even if you launch the process in a tty
other than tty1, which seems to be the case now).
4. when init moves on to the real filesystem, something happens to the
console that triggers that race condition that's now documented on the Rpath
linux page (https://issues.rpath.com/browse/RPL-1593)


-- 
----)(-----
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/20070929/c92994c8/attachment.htm