[Splashy-devel] My Tests.

[Luis]

Hello Pat,

I think that I can answer some of your findings. However, let me say,
thanks! keymap.sh has been our worse enemy for quiet some time. I can
understand a bit better now what those corrupted characters on tty2
means (if you let splashy timeout and switch to tty2, you are able to
hit ENTER).

Now read on:

On 2/17/07, Pat Suwalski <pats at xandros.com> wrote:
> Hello,
>
> I never got around to doing the splashy tests at lunch a few days ago,
> but I did take a few hours tonight.
>

Very good. I rebuilt my system from scratch the other day. I'll start
testing the latest release of Splashy myself.

> What I have found is that there are many things that are suboptimal,
> that I don't have easy solutions for. My technique was to use "sh -x"
> extensively, combined with strace iteratively.
>
> First, on a clean "unstable" install, the progress locks up on
> rcS.d/S05keymap.sh, which calls start_unicode, which in turn calls
> vt-is-UTF8. This attempts to open the console, write 3 bytes, and see
> how many characters actually were printed (thus UTF-8 or not). The
> problem is that splashy is holding the console, so it's not getting very
> far.

I thought that we did something to skip the system from running
keymap.sh/console-screen.sh. I guess it only prevents
console-screen.sh from running... I'll have to look into the source
code for 0.3.2 to figure this one out.

> In case people haven't noticed, you can just Escape splashy and go to
> Alt-F2 console, see the junk that vt-is-UTF8 spit out, and hit Enter to
> continue (so it reads its last byte). I believe it breaks because the
> init script uses fgconsole, which doesn't actually work as expected due
> to aforementioned resources being occupied by splashy. More on this later.

Excellent work! I never knew that fgconsole was trying to read that
last byte. I did notice that if the splashy script (the initrc script)
has some kind of logging enabled, this problem doesn't happen, but the
boot process is slowed down. By "logging" I mean something like: echo
"foo" >> /tmp/splashy.log. This acts as if somebody was pressing
"ENTER" for you every now and then. Though I really don't understand
completely why this would skip the vt-is-UTF8 problem.

> If we remove S05keymap, it still gets started later on in init, on my
> clean install it happens right between sysklog and klog in rc2. Probably
> something to do with the LSB dependency field in the init scripts.
> Anyway, this results in a progress bar that advances very very slowly.
>
> Now, I have commented before about how splashy seems to use tty0 and
> tty2. The latter is used for apparently no reason. This has struck me as
> odd before, about a year ago, iirc.

Yes, after this I attempted to switch tty's as soon as Splashy starts.
iirc, it tries to go to tty8 and I thought that it was working fine.
Again, I'll need to make sure that whatever code was in splashy 0.2.x
is also on 0.3.x in terms of this. (That should be somewhere in
splashy_main.c).

> I have attached an lsof output from initramfs right before init
> executes. You can see that splashy has many open files, but particularly
> tty0, tty2, and vcs1. Also, unless I am mistaken, there are seven (7!)
> splashy processes. I expected 2: one parent, one child. The child has
> spawned 5 processes of its own; this is highly suspect.

Splashy uses threads to speed things up. I believe there are 5 threads
that we open (counting the master/parent): keyboard events, log events
(vcs*), progress bar, splashy itself (bg image), ...for more see
splashy_functions.c.

> Long story short, what I witnessed tonight is exactly what I witnessed a
> year ago: resource contention. Splashy takes two ttys, stays on one of
> them, init is forced to take another, things expect to be on the tty
> that init is on, there is a lock.

I'll have a fresh look at this issue and see why tty8 is not been used.

> Something I had meant to experiment with last year (never got the
> chance), was to make splashy open a higher tty by default, say tty6 or
> tty9. Perhaps if init is on tty0 it will be happier. Maybe there could
> be some experimentation whether a tty even needs to be opened?
>
> The line that opens the tty has a blatant error, btw:
> "O_RDONLY|O_WRONLY" makes no sense whatsoever. It should be either-or,
> or O_RDWR. This might be another source of problems if it does not run
> as designed.

This might be just the problem. I can't recall exactly why we used
both flags there. But I remember looking at examples of this and
reading the man page for the system call. I'll try using O_RDWR.

> Sorry about the long eMail. Perhaps something useful will come of this.
> I feel we will be a big step closer when we figure out why tty2 is used,
> amongst other things.
>
> It's all in the tty's, folks.
> --Pat

Thanks a lot Pat. This certainly revives this issue and gives us a
fresh insight into the problem.

The use of tty2 is definitely a show stopper.

-- 
----)(-----
Luis Mondesi
*NIX Guru

"Feliz el hombre que ha hallado sabiduria y el hombre que consigue
discernimiento, porque el tenerla como ganancia es mejor que tener la
plata como ganancia; y el tenerla como producto, [mejor] que el oro
mismo" (Prov 3:13-14).
      |_|0|_|
      |_|_|0|
      |0|0|0|