Comment 149 for bug 625239

Hi Seth,

On Wed, Sep 15, 2010 at 12:25:13AM -0000, Seth wrote:
> So that seems to imply that the problem does not manifest itself on
> maverick (yet). However, since we have such good understanding of the
> triggering events I decided to check with my force.sh (forced
> reproduction script from comment #142).

> Surprisingly, not only is the new nvidia/xorg combination vulnerable to
> the same start up race,

That's not surprising to me at all. Your force.sh does not accurately model
the conditions on startup; instead of a trigger for gdm starting based on
udev events, you are forcing gdm to start in parallel to the modprobe of
nvidia-current, which is always going to be racy.

> what's more: the timing has gotten faster by just enough that
> gdm-simple-slave (gdm-server.c) runs out of launching attempts. The end
> result in that scenario is _not pretty_: the upstart job ("task"?) is in
> status 'running' while there is no X session at all!

Oh. The intended behavior in this situation is that the gdm process will
exit non-zero, so that the /etc/init/failsafe-x.conf job will start up and
present the user with appropriate options. It sounds like this is a
separate regression in maverick; would you mind filing a bug report against
the gdm package for this?

> All in all, it appear that the potential that this race occurs on
> Maverick is present just like in Ubuntu. Timings are different, and I
> haven't yet spontaneously encountered the situation on boot. But on
> manual triggering the behaviour is far worse.

force.sh doesn't establish this at all. There *could* still be a race -
successful boots don't rule this out - but if so, we need to find it based
on looking at /var/log/udev from maverick and/or by reproducing it with an
actual boot.

Actually, there might be an easier way. Could you boot with '--verbose'
added to the boot options, and attach the resulting /var/log/syslog? This
should show us what events upstart is seeing related to video cards, and
may be enough to confirm/deny that the requisite event is being sent in
response to the nvidia driver and not an unrelated framebuffer driver.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>