Bug#674501: xserver-xorg-video-openchrome: gdm3 spawns tens of slaves and X servers after upgrade to 0.2.904+svn1050-1+b1
On 06/06/2012 04:25 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 This is probably the same as #675407. Cheers, Julien After a few hours of looking at pinning docs and experimenting, I have downgraded to a working though rather old openchrome and associated packages, pinned to stable. Not perfect, but it will do far better than forcing the vesa driver and associated non-native screen resolution visual artifacts. Quite a relief to not have the display trying to dither its impression of 1024x768 on 1920x1080 screen. Though I've found and added to the sources.list entries for squeeze-backports and experimental, and run apt-get update, I couldn't seem to get the pinning syntax to select either the squeeze-backports or experimental versions, both of which are closer to the last working versions I saw on unstable. Package: xserver-common Pin: release a=stable Pin-Priority: 1001 Package: xserver-xorg* Pin: release a=stable Pin-Priority: 1001 Just checked back on #675407 and it looks like there's a fix available since Friday, but I've not seen new packages show up in apt-cache show or apt-cache policy output yet, and don't have time before next weekend to go the source-level + manual install route. Thanks again (and any insight to the pinning syntax) Fred
Bug#674501: xserver-xorg-video-openchrome: gdm3 spawns tens of slaves and X servers after upgrade to 0.2.904+svn1050-1+b1
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
Bug#674501: xserver-xorg-video-openchrome: gdm3 spawns tens of slaves and X servers after upgrade to 0.2.904+svn1050-1+b1
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 This is probably the same as #675407. Cheers, Julien -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#674501: xserver-xorg-video-openchrome: gdm3 spawns tens of slaves and X servers after upgrade to 0.2.904+svn1050-1+b1
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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
