[intrepid] X server fails to start properly on Jetway

[Peter Belew]

Binary package hint: xorg

After upgrading online from 8.04.1 to 8.10 (Intrepid), and starting the new system, keyboard and mouse input to the X server are frozen. However, if I switch to a console and restart X either by killing the Xorg process explicitly or executing '/etc/init.d/gdm restart', the inputs are enabled. (In the initial state, keyboard input works for doing commands like ctrl-alt-F2 or ctrl-alt-DEL, but X can't be (re-)started with ctrl-alt-BS).

The system has a Jetway 625EMP-800 motherboard, with a VIA Samuel 2 800 mHz CPU.
The rest of the chipset is made by VIA.
The display controller is a VIA Technologies, Inc. VT8623 [Apollo CLE266] integrated CastleRock graphics (rev 03)
The monitor is a ViewSonic E771 17" tube monitor.

Software version info:
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=8.10
DISTRIB_CODENAME=intrepid
DISTRIB_DESCRIPTION="Ubuntu 8.10"
Linux trippy 2.6.25-2-386 #1 Tue Sep 30 14:47:35 UTC 2008 i686 GNU/Linux

I have enclosed dmesg output, and will add more files shortly.

This system has had another X server startup problem for some time - in about a quarter of boots, it fails to start up at screen resolutions >= 1024x768, and starts up at 800x600. This is likely a timing problem - some race condition. This bug is probably related to that.

[Peter Belew (peterbe)]

This happens each time I reboot, but not when I restart X with ctrl-alt-BS.

I've enclosed the last bit of my /var/log/daemon.log, covering the installation.

What other files would be useful?

[Peter Belew (peterbe)]

Possible solution:

I may have found a fix to this problem - in /etc/rc2.d, I changed the symlink S13gdm to S90gdm to delay startup of gdm. ( S90gdm -> ../init.d/gdm)

I have only rebooted once since changing this, so more testing is necessary.

Some concerns are that whatever the race condition is WITH may not be something started at the same runlevel, and that reordering gdm startup in this manner may cause a problem with other daemons started at this runlevel.

This problem did not occur in starting from the CD most likely because the slow speed of loading from the CD delayed gdm startup more than sufficiently.

Hopefully this will also fix the old occasional low-resolution startup with this motherboard. (I have 2 systems with this kind of motherboard, and I'll try this solution on the other one, too - still running 8.04.1 on that one).

I'll revisit this if any further problems occur of this nature, and also if the problem seems to be solved by this hack.

[Peter Belew (peterbe)]

I upgraded another system with the same type of motherboard, chipset, and cpu. In this case, I used the alternate install CD as the primary source of new files, allowing access to the Internet for additional upgrades.

In this case, the symlink for starting gdm in /etc/rc2.d turned out to be S30gdm -> ../init.d/gdm - not S13gdm, as above, and the display started on the first reboot after installation.

So why was it S13gdm in my first upgrade installation? Could this have been left over from the installation of a previous version of Ubuntu - on the theory that the upgrade install does not change existing symlinks? Or could there be some difference between upgrades from the Internet versus upgrades primarily from the Alternate CD? I suspect that the former case is most likely.

It may be that for most hardware the order in which gdm is started relative to other daemons started in runlevel 2 is not so critical; but for this motherboard it is pretty critical.

[Timo Aaltonen (tjaalton)]

It should be S30 on hardy too, don't know if it has been S13 before..

[Sebastien Bacher (seb128)]

Thanks for the bug report. This particular bug has already been reported, but feel free to report any other bugs you find.

[Peter Belew (peterbe)]

This appears to have been fixed in the Ubuntu 9.04 Beta release - that worked fine on both the Jetway systems I have. Also an unreported problem in which the systems didn't start with consistent screen resolutions seems to have gone away.

I'm not sure that this was actually the same as the 'duplicate' bug - this one seems to have been dependent on the particular hardware, including the motherboard and CPU. What is the same is that changing the priority of starting gdm was a factor in the 8.x releases.