ubuntu-x-swat team mailing list archive

["John S. Gruber" <JohnSGruber@xxxxxxxxx>]

@Jamie:

Since I'm only another member of the community it's completely possible
that I won't be able to see this through to a fix. A glance from a
plymouth or gdm developer may mean more progress than I could make in
days. If it's ok with you, though, maybe we can move this towards a
successful triage state on our own so it will be easy for a developer to
find the problem. I appreciate your willingness to try things. I may not
recognize when we have enough info.

I think your reply was very interesting.

1. You have a system that flies. This bug may be a problem caused by a
race condition. A faster system may have different results than a slower
one. How many processors or cores does your system have? What speed? I
ask this to look for correlations between your report and those by
others.

2. You are configured to use splash and it is working.

3. The timestamp on your file is correct. Because you were occasionally
starting on tty2, I had myself half convinced that it would have an old
date and that gdm wasn't even trying to start on the same virtual
terminal as plymouth. It may be that gdm thinks plymouth's active
terminal is tty1 (or maybe even tty2).

4. Between the time you see the splash and you see the login you see a
blink. There isn't supposed to be a blink. That may be where your
virtual console is switching from tty7 to tty1 and X is sealing its fate
by starting there (or may not).

Some basics first:

You said you are running plymouth version plymouth 0.8.2-2ubuntu2. What
version of gdm and upstart are you running?

Next:

Could you try adding the boot option plymouth:debug in grub and on that
boot recreate the problem? Could you then attach the  plymouth debugging
log, gdm log, and the log from the failing X. It will probably be in
Xorg.0.log.old after you restart. The failing X log will contain a
traceback and say something about  a quit signal or another signal
depending upon the key you pressed when it crashed.

@Dino:
If you are still with us. Would you mind terribly telling us, when it fails for you, what you see? What versions of plymouth, gdm, and upstart are you running? What is your computer like? Like Jamie, does the creation time of /var/run/gdm/firstserver.stamp match the login time (it should). I'm just trying to confirm there aren't two separate underlying reasons for starting X on tty1 or tty2.

Warning: If this is a race condition just adding plymouth:debug might
change the timing and "fix" the problem by slowing plymouth down. The
logs may still be helpful. I'm thinking that it's a race condition and
that Dino's compiz experiment changed the timing. I certainly may be
wrong.

The purpose of the logs is to make sure plymouth is running on tty7 as
expected, to see if gdm is asking if plymouth is active on plymouth's
virtual terminal, and to watch where X starts. The idea is to get an
idea where things get directed to tty1. We won't need the auth logs.
They simply helped establish the interference from the getty process. We
already know if you are starting X on tty1 that we have this problem.

Whether you each have the time and inclination to continue on with me or
not, thanks to you both for posting your experiences.

-- 
X starts on wrong tty: pressing enter after 5 minutes crashes X
https://bugs.launchpad.net/bugs/625239
You received this bug notification because you are a member of Ubuntu-X,
which is subscribed to xserver-xorg-video-ati in ubuntu.