[Splashy-devel] Initramfs bug understood
Luis Mondesi
lemsx1 at gmail.com
Fri Sep 28 17:50:50 UTC 2007
Hello all,
The guys from Rpath seem to have uncover the pesky bug that makes directfb
"hang" the system while booting from initramfs. It seems that allowing
DirectFB to use tty8 (instead of 2) would definitely fix this issue.
Read more from this page:
https://issues.rpath.com/browse/RPL-1593
Quote
Elliot Peele <https://issues.rpath.com/secure/ViewProfile.jspa?name=elliot>-
22/Aug/07
11:38 AM At this point I am running into issues getting splashy to compile.
It fails with several unresolved symbol errors when linking. This are
symbols that should be provided by the libs that splashy is link to.
[ Show » <https://issues.rpath.com/browse/RPL-1593> ]
Elliot Peele <https://issues.rpath.com/secure/ViewProfile.jspa?name=elliot>-
22/Aug/07
11:38 AM At this point I am running into issues getting splashy to compile.
It fails with several unresolved symbol errors when linking. This are
symbols that should be provided by the libs that splashy is link to.
[ Permlink <https://issues.rpath.com/browse/RPL-1593#action_46100> | «
Hide <https://issues.rpath.com/browse/RPL-1593> ]
Elliot Peele <https://issues.rpath.com/secure/ViewProfile.jspa?name=elliot>-
24/Aug/07
10:23 AM
Splshy builds and works, now it is just a matter of porting the patches for
mkinitrd and initscripts from usplash to splashy.
[ Show » <https://issues.rpath.com/browse/RPL-1593> ]
Elliot Peele <https://issues.rpath.com/secure/ViewProfile.jspa?name=elliot>-
24/Aug/07
10:23 AM Splshy builds and works, now it is just a matter of porting the
patches for mkinitrd and initscripts from usplash to splashy.
[ Permlink <https://issues.rpath.com/browse/RPL-1593#action_48839> | «
Hide <https://issues.rpath.com/browse/RPL-1593> ]
Elliot Peele <https://issues.rpath.com/secure/ViewProfile.jspa?name=elliot>-
20/Sep/07
05:46 PM
Current Status:
We are going to be shipping splashy in rPath Linux 2 Alpha 4. uSplash has
been abandoned as it is too hard to create themes for.
Three packages are required splashy, DirectFB, and initscripts from
usplash.rb.rpath.com at rpl:devel. These are only available as x86.
Splashy is being started from /etc/rc.sysinit by calling splash_boot which
is a function implemented in /etc/init.d/functions. There are several splash
related functions near the end of /etc/init.d/functions.
When running in run level 3 splashy seems to work rather well, however in
run level 5 splashy starts using 100% of the CPU when init switches from
rc.sysinit to rc. At this point init detaches the controlling terminal from
splashy which seems to make it freak out. I have tried stracing the splashy
process, but splashy behaves differently in this case because the
controlling terminal changes differently.
[ Show » <https://issues.rpath.com/browse/RPL-1593> ]
Elliot Peele <https://issues.rpath.com/secure/ViewProfile.jspa?name=elliot>-
20/Sep/07
05:46 PM Current Status: We are going to be shipping splashy in rPath Linux
2 Alpha 4. uSplash has been abandoned as it is too hard to create themes
for. Three packages are required splashy, DirectFB, and initscripts from
usplash.rb.rpath.com at rpl:devel. These are only available as x86. Splashy is
being started from /etc/rc.sysinit by calling splash_boot which is a
function implemented in /etc/init.d/functions. There are several splash
related functions near the end of /etc/init.d/functions. When running in run
level 3 splashy seems to work rather well, however in run level 5 splashy
starts using 100% of the CPU when init switches from rc.sysinit to rc. At
this point init detaches the controlling terminal from splashy which seems
to make it freak out. I have tried stracing the splashy process, but splashy
behaves differently in this case because the controlling terminal changes
differently.
[ Permlink <https://issues.rpath.com/browse/RPL-1593#action_49142> | «
Hide <https://issues.rpath.com/browse/RPL-1593> ]
Stas Kysel <https://issues.rpath.com/secure/ViewProfile.jspa?name=stas>
- 25/Sep/07
01:09 PM - edited
Splashy is cycling in the following function in DirectFB, in "while":
static void*
keyboardEventThread( DirectThread *thread, void *driver_data )
{
int readlen;
unsigned char buf[64];
KeyboardData *data = (KeyboardData*) driver_data;
/* Read keyboard data */
while ((readlen = read (data->vt->fd, buf, 64)) >= 0 || errno == EINTR) {
int i;
direct_thread_testcancel( thread );
for (i = 0; i < readlen; i++) {
DFBInputEvent evt;
evt.type = ((buf[i] & 0x80) ?
DIET_KEYRELEASE : DIET_KEYPRESS);
evt.flags = DIEF_KEYCODE;
evt.key_code = buf[i] & 0x7f;
dfb_input_dispatch( data->device, &evt );
keyboard_set_lights( data, evt.locks );
}
}
readlen = 0, errno = 0
Probably "sleep(1)" workaround would fix 100% load and may be considered a
quick fix.
I don't know yet why it is not cycling when started from command line or on
shutdown - the cycle looks quite endless and 100%-consuming one, if keys are
not pressed and file descriptor is non-blocking.
Debugger doesn't work very well when program is cycling (it shows data=0 and
exits program on pthread_testcancel()), so I use debug prints.
[ Show » <https://issues.rpath.com/browse/RPL-1593> ]
Stas Kysel <https://issues.rpath.com/secure/ViewProfile.jspa?name=stas>
- 25/Sep/07
01:09 PM - edited Splashy is cycling in the following function in DirectFB,
in "while":
static void*
keyboardEventThread( DirectThread *thread, void *driver_data )
{
int readlen;
unsigned char buf[64];
KeyboardData *data = (KeyboardData*) driver_data;
/* Read keyboard data */
while ((readlen = read (data->vt->fd, buf, 64)) >= 0 || errno == EINTR) {
int i;
direct_thread_testcancel( thread );
for (i = 0; i < readlen; i++) {
DFBInputEvent evt;
evt.type = ((buf[i] & 0x80) ?
DIET_KEYRELEASE : DIET_KEYPRESS);
evt.flags = DIEF_KEYCODE;
evt.key_code = buf[i] & 0x7f;
dfb_input_dispatch( data->device, &evt );
keyboard_set_lights( data, evt.locks );
}
}
readlen = 0, errno = 0 Probably "sleep(1)" workaround would fix 100% load
and may be considered a quick fix. I don't know yet why it is not cycling
when started from command line or on shutdown - the cycle looks quite
endless and 100%-consuming one, if keys are not pressed and file descriptor
is non-blocking. Debugger doesn't work very well when program is cycling (it
shows data=0 and exits program on pthread_testcancel()), so I use debug
prints.
[ Permlink <https://issues.rpath.com/browse/RPL-1593#action_49217> | «
Hide <https://issues.rpath.com/browse/RPL-1593> ]
Elliot Peele <https://issues.rpath.com/secure/ViewProfile.jspa?name=elliot>-
25/Sep/07
04:36 PM - edited
Adding a usleep(200) to the above function if readlen == 0 seems to have
alleviated the 100% CPU problem.
[ Show » <https://issues.rpath.com/browse/RPL-1593> ]
Elliot Peele <https://issues.rpath.com/secure/ViewProfile.jspa?name=elliot>-
25/Sep/07
04:36 PM - edited Adding a usleep(200) to the above function if readlen == 0
seems to have alleviated the 100% CPU problem.
[ Permlink <https://issues.rpath.com/browse/RPL-1593#action_49305> | «
Hide <https://issues.rpath.com/browse/RPL-1593> ]
Stas Kysel <https://issues.rpath.com/secure/ViewProfile.jspa?name=stas>
- 26/Sep/07
10:20 AM
The trouble is:
DirectFB is using VT_OPENQRY ioctl to get the next unused tty.
It gets /dev/tty2 this way because gettys are not started by init yet.
Later, when getty on /dev/tty2 is started, it uses it and interfere with
DirectFB.
Resolutions may include:
Patching DirectFB to use /dev/tty7 or any other device - patch is ready,
I've used it during investigation.
Disabling tty2 in inittab (looks weird)
Making ttys up to 6 busy during splashy startup somehow - start gettys on it
(maybe put splashy to inittab, after getty entries), or use some other
program to open all ttys mentioned in inittab, or maybe just find proper
switch in init.
Look how it's resolved in other distros.
Ask splashy developers.
Try to modify DirectFB so that it doesn't rely on tty modes (or in other way
interfere with getty).
If anybody has any idea on clean resolution of this, please add comment.
Some details which may be interesting if above is not understood fully:
1. When started from initscripts, DirectFB opens 2 ttys - /dev/tty0 and
/dev/tty2.
When started from command line after boot - /dev/tty7.
2. /dev/tty2(7) is used by buggy thread for keyboard input.
DirectFB uses termios to change it's mode:
ts.c_cc[VTIME] = 0;
ts.c_cc[VMIN] = 1;
ts.c_lflag &= ~(ICANON|ECHO|ISIG);
ts.c_iflag = 0;
3. But somewhere in boot up tty mode is changed back. I can't find "stty"
in /etc scripts, I'm not sure where it's done, most probably in gettys. I
suspect that this triggers cycling bug in DirectFB.
4. Ttys up to tty6 (but excluding tty7) are mentioned in
kde3/kdm/kdmrc:ConsoleTTYs=tty1,tty2,tty3,tty4,tty5,tty6
inittab
5. When I change mode back, cycling doesn't stop.
6. When I patch DirectFB to open tty7 instead of tty2, or when I disable
tty2 getty in inittab, bug is not triggered.
[ Show » <https://issues.rpath.com/browse/RPL-1593> ]
Stas Kysel <https://issues.rpath.com/secure/ViewProfile.jspa?name=stas>
- 26/Sep/07
10:20 AM The trouble is: DirectFB is using VT_OPENQRY ioctl to get the next
unused tty. It gets /dev/tty2 this way because gettys are not started by
init yet. Later, when getty on /dev/tty2 is started, it uses it and
interfere with DirectFB. Resolutions may include: Patching DirectFB to use
/dev/tty7 or any other device - patch is ready, I've used it during
investigation. Disabling tty2 in inittab (looks weird) Making ttys up to 6
busy during splashy startup somehow - start gettys on it (maybe put splashy
to inittab, after getty entries), or use some other program to open all ttys
mentioned in inittab, or maybe just find proper switch in init. Look how
it's resolved in other distros. Ask splashy developers. Try to modify
DirectFB so that it doesn't rely on tty modes (or in other way interfere
with getty). If anybody has any idea on clean resolution of this, please add
comment. Some details which may be interesting if above is not understood
fully: 1. When started from initscripts, DirectFB opens 2 ttys - /dev/tty0
and /dev/tty2. When started from command line after boot - /dev/tty7. 2.
/dev/tty2(7) is used by buggy thread for keyboard input. DirectFB uses
termios to change it's mode:
ts.c_cc[VTIME] = 0;
ts.c_cc[VMIN] = 1;
ts.c_lflag &= ~(ICANON|ECHO|ISIG);
ts.c_iflag = 0;
3. But somewhere in boot up tty mode is changed back. I can't find "stty" in
/etc scripts, I'm not sure where it's done, most probably in gettys. I
suspect that this triggers cycling bug in DirectFB. 4. Ttys up to tty6 (but
excluding tty7) are mentioned in
kde3/kdm/kdmrc:ConsoleTTYs=tty1,tty2,tty3,tty4,tty5,tty6 inittab 5. When I
change mode back, cycling doesn't stop. 6. When I patch DirectFB to open
tty7 instead of tty2, or when I disable tty2 getty in inittab, bug is not
triggered.
[ Permlink <https://issues.rpath.com/browse/RPL-1593#action_49358> | «
Hide <https://issues.rpath.com/browse/RPL-1593> ]
Michael K. Johnson<https://issues.rpath.com/secure/ViewProfile.jspa?name=johnsonm>-
26/Sep/07
02:13 PM
tty7 gets used by the first X in runlevel 5, and that's a default
configuration in some cases.
As a workaround, we could be very sneaky in the initrd and mknod tty2 with
the right minor number for tty8 – or tty16, or whatever.
getty does change the mode. I wonder if we could possibly make use of this
this? That is, in the thread, if readlen == 0, then see if termios settings
have been changed, and if so, re-use VT_OPENQRY to open up a new vt and use
that.
I'd think that enhancing DirectFB to allow specifying what tty to use would
be a good idea in general – we know, for instance, that vt8 will always be
available in our normal setups, but that's quite flexible in the general
case.
End Quote
This is very very good news!
--
----)(-----
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/20070928/23aee3f7/attachment-0001.htm
More information about the Splashy-devel
mailing list