On 05/26/2012 11:31 PM, Fred Korz wrote:
On 05/25/2012 05:57 PM, Julien Cristau wrote:
On Thu, May 24, 2012 at 23:38:06 -0400, Fred Korz wrote:
Package: xserver-xorg-video-openchrome
Version: 1:0.2.904+svn1050-1+b1
Severity: important
Dear Maintainer,
[* What led up to the situation?]
Been running "testing" for 8 years now. Currently that's wheezy. Do
dist-upgrade daily and reboot & backup weekly.
Reboot on 2012.05.20 after dist-upgrade failed to bring up network and display.
* What exactly did you do (or not do) that was effective (or
ineffective)?
Rebooted single user, manually configured network to get debugging
access off of console. (New startup sequences, network configured by
network manager and that isn't started until it has a screen to start
on. So if gdm3 doesn't come up, you loose your network path onto the
system, e.g. sshd. *boo*) Worked around that by reinstalling the old
ifupdown package, which had been autoremoved but config data left in
place.
With ssh access, investigated server and found 40 to 80
/usr/lib/gdm3/gdm-simple-slave processes, all children of one
/usr/sbin/gdm3, and each slave had started a /usr/bin/Xorg instance.
What's in the gdm log?
Cheers,
Julien
Hi Julien,
I'll assume we're talking about the gdm3 logs. Last thing that
touched the gdm logs was in April, quite a few daily
dist-upgrades and weekly reboot & backup cycles ago.
Because my last test had been trying the .906 OpenChrome driver,
and failed like the one in the repos, I reverted to the standard
apt-get installed one, cleaned up logs, locks and sockets, etc,
then moved my forced vesa driver xorg.conf out of the way, and
ran "gdm3 force-reload". Usual madness ensued (terminated by
"/etc/init.d/gdm3 stop")
In the few seconds I let it run, it generated log files for
displays 0 through 29 (nice trick for a single device that can
drive only one display).
I've attached a selection of the resulting logs, for 0 through
3. Either I/O errors (the minority) or segfaults with minimal
backtraces.
There's a pending update that came out in the last 48 hours
which I didn't want to apply before capturing a reproduction for
you.
I'll upgrade now and retry the resulting configuration. Perhaps
the i/o problems, segfaults, and multiplicity problem stem from
the common or core?
Conf xserver-common (2:1.12.1.902-1 Debian:testing [all])
Conf xserver-xephyr (2:1.12.1.902-1 Debian:testing [i386])
Conf xserver-xorg-core (2:1.12.1.902-1 Debian:testing [i386])
Conf xserver-xorg-dev (2:1.12.1.902-1 Debian:testing [i386])
If this doesn't work, I'm also going to load up a squeeze live
distribution and/or Ubuntu 12.04, just to rule out some freak
change in my hardware.
Many thanks for looking into this with me.
It's frustrating not being able to use serious screen
resolutions for graphical things after years of flawless
operations
Fred
A squeeze live distribution booted up fine and ran
with full autodetect of the Via chipset. The unichrome driver
loaded and ran 1920x1080 on the hardware.
That rules out a coincidental hardware failure just at the time
the x-installation was updated. (The Ubuntu live disk wouldn't
boot because they've raised the minimum hardware requirements.)
Fred
|