This is a Number 9 Revolution 4 video card. Problem occurred with non-updated brand new FC3 install and also after I patched everything (including kernel and xorg-x11): kernel-2.6.10-1.770_FC3 xorg-x11-6.8.2-1.FC3.13 lspci -v output 01:00.0 VGA compatible controller: Number 9 Computer Company Revolution 4 (rev 01) (prog-if 00 [VGA]) Subsystem: Number 9 Computer Company: Unknown device 0023 Flags: bus master, 66Mhz, medium devsel, latency 0, IRQ 11 Memory at e3000000 (32-bit, prefetchable) [size=16M] Memory at e2000000 (32-bit, prefetchable) [size=16M] Memory at e1000000 (32-bit, non-prefetchable) [size=4K] Memory at e0800000 (32-bit, non-prefetchable) [size=64K] I/O ports at d800 [size=256] Expansion ROM at e1ff0000 [disabled] [size=64K] Capabilities: [80] AGP version 1.0 Capabilities: [90] Power Management version 1 It seems to only happen after the second logout from X. I already tried commenting out "Load dri" in xorg.xonf and that did not help. KDE/Gnome are not installed - this happens with twm and XFCE. The system is totally dead after the second logout. Won't respond to pings, keyboard, or mouse. Only the hardware reset button. I also posted a report with Redhat at https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=154114 They had some suggestions (e.g. disabling hw accel) which I will try today and then follow up here. I've also posted xorg.conf and a log file there. I can repost them here if needed but it looks like I have to paste them in as text rather than attachments?
Adding 'Options "NoAccel" "True"' to the video card's device section in xorg.conf did *not* help. However, if instead of logging out I use Ctrl-Alt-Backspace to kill the X session, that seems okay. Weird. I tried it 5 times on one of the affected machines (I have 10 of these) and every time the login screen came back.
Created attachment 2351 [details] xorg.conf Okay, I see how to add attachments now.
Created attachment 2352 [details] Xorg.0.log from an affected machine This is the log file after logging in for the first time. It changes only slightly after the second login and not at all when you logout a second time (forcing a crash). BTW, there is nothing in /var/log/messages - the crash happens almost instantly. Here is a diff against the Xorg.0.log file after the second login: # diff Xorg.0.log-1stlogin Xorg.0.log-2ndlogin 547a548,555 > (--) I128(0): Unmapping memory > (II) Open APM successful > (II) APM registered successfully > (--) I128(0): Mapping memory > (==) I128(0): Write-combining range (0xe3000000,0x1000000) > (**) I128(0): DPMS enabled > (==) RandR enabled > (II) Mouse0: ps2EnableDataReporting: succeeded
Please add Option "Debug" "on" to your card's Device section of your xorg.conf, reproduce the freeze, and attach the X log from the frozen session.
Created attachment 2353 [details] Xorg.0.log with debug turned on Interestingly, turning debug on made it crash on the very first logout. I don't recall that happening before. Obviously the logfile I have attached here is really Xorg.0.log.old after rebooting.
hm. what happens if you disable APM? rename /dev/apm_bios to something else and start the server.
I turned off the apmd service and rebooted (acpi was already off but as you may have guessed these are old machines :-) and it isn't supported anyway). That didn't help. I deleted /dev/apm_bios entirely but it still crashes on the second logout. Here's another useless tidbit of info: selecting reboot from the graphical login screen will also cause the machine to hang if it's the second time X is shutdown. I'm not sure if that narrows things down or if it would have been obvious to a guru.
do you still have APM enabled in the BIOS though? that's the only major difference i can see between your setup and mine (possibly excluding kernel revision). you'd said in the rh bug that the system is totally dead even to the network, right?
That's right - completely dead as far as I can tell. Doesn't respond to keyboard and mouse on any reasonable timescale (i.e. I've waited about 5 minutes after Ctrl-Alt-F1 to see if a text console came up). Won't respond to ping/ssh either. I've let it go overnight and all this is still true. The monitor is blank (and in power save mode if I recall correctly - i.e. no signal). I did still have Power Management on in the BIOS but I've now turned it off there too and the problem persists. As to the kernel version - it did it with unpatched Fedora Core 3 (2.6.9-1.667) and still does it with the latest kernel (2.6.10-1.770_FC3). I haven't tried NoAccel, no apm, etc. with the older kernel. I could if you thought that might be useful. These cards worked fine under Redhat 6.2: 2.2.19-6.2.7 kernel and XFree86-3.3.6-29. We were only using 8 bit color (still 1024x768). I should try 800x600@16 bit and some other combinations to see if that makes a difference. I won't be able to get back in there till late this afternoon. Is there something significant about Ctrl-Alt-Backspace not triggering the problem?
in principle CAB should shut down the server through the same code path as a normal shutdown. in practice, that might not be true. i'd have to check. i'm a bit busy at the moment, but i'll try to come up with a debugging patch in a few days to try to track this down. in the meantime if you could isolate a configuration that works that would be very helpful.
Sorry for the delay - I got tied up with some other projects. I cannot find a combination of resolution / color depth that doesn't exhibit the problem. I went all the way down to 640x480@8 and the systems still hang after the second logout. Any other ideas out there?
The same type of problem here with different HW: I'm using a Matrox G550, dual-head, TwinView, with Matrox HAL, runing Gentoo x11-base/xorg-x11-6.8.2-r4. I tried different window managers: - KDE - GNOME - XFCE and the system hangs with all logouts. No response to anything, including <Ctrl><Alt><Backspace>, but soleyly to <Ctrl><Alt><Delete>, issuing a reboot. Kind regards, Manfred P.S.: some more info about my machine: System uname: 2.6.13-gentoo-r3 i686 Pentium III (Coppermine) ... sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.15.92.0.2-r10 sys-devel/libtool: 1.5.18-r1 CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=pentium3 -pipe" CHOST="i686-pc-linux-gnu" CXXFLAGS="-O2 -march=pentium3 -pipe" ...
Created attachment 3562 [details] Matrox G550 :: Xorg.0.log - debug Even with debug turned on, I did not observe any additional information written into this log after issuing the logout. Kind regards, Manfred
Created attachment 3563 [details] Matrox G550 xorg.conf This is my Xorg configuration, wich worked perfectly until recent updates. Please, don't get confused about three Monitor sections for a TwinView layout. (The Eizo T960 died after more than 8 years, so I temporarily switched to the second (BNC) input of the EIZO T761 of another machine :) B.t.w.: Very recently, my major changes were: I upgraded the kernel from 2.6.12 to 2.6.13; therefore the need arouse to necessarily change to udev.
some more info: from lspci -v: -------------- 0000:01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G550 AGP (rev 01) (prog-if 00 [VGA]) Subsystem: Matrox Graphics, Inc. Millennium G550 Dual Head DDR 32Mb Flags: bus master, medium devsel, latency 64, IRQ 11 Memory at e2000000 (32-bit, prefetchable) [size=32M] Memory at e1000000 (32-bit, non-prefetchable) [size=16K] Memory at e0800000 (32-bit, non-prefetchable) [size=8M] Expansion ROM at e1fe0000 [disabled] [size=128K] Capabilities: [dc] Power Management version 2 Capabilities: [f0] AGP version 2.0 from dmesg : ------------ [drm] Initialized mga 3.1.0 20021029 on minor 0: Matrox Graphics, Inc. MGA G550 AGP mtrr: base(0xe2000000) is not aligned on a size(0x1800000) boundary agpgart: Found an AGP 1.0 compliant device at 0000:00:00.0. agpgart: Putting AGP V2 device at 0000:00:00.0 into 1x mode agpgart: Putting AGP V2 device at 0000:01:00.0 into 1x mode
manfred, this bug is for logout hangs with the i128 driver. it is clearly an issue specific to the i128 hardware; please open a new bug if you are having this issue on other hardware.
I don't know whether this is related, but I was having almost exactly the same problem with a SuSE 9.3 installation with an i810 driver. Nothing I did worked until I reinstalled the 32-bit version of linux. Now I can logout without any problems. Maybe this problem only exists for a 64-bit installation?
(In reply to comment #17) > I don't know whether this is related, but I was having almost exactly the same > problem with a SuSE 9.3 installation with an i810 driver. Logout and VT switch hangs are almost always driver specific. Please file a bug against the i810 driver. > Nothing I did worked > until I reinstalled the 32-bit version of linux. Now I can logout without any > problems. Maybe this problem only exists for a 64-bit installation? The reporter's configuration is x86, not amd64. This does not appear to be a 64-bit issue.
I came to open a bug about my i128 issue. While I have never had my system lockup when I logout out of X, I do have the problem of the screen text being garbage after the logout. A quick setfont fixes the issue, but I humbly request a proper fix. This has happened since Redhat 9 days and still happens using xorg-x11-drv-i128-1.1.0.2-1 on xorg 0.99.2 Should I open a different bug or stay with this one? Thanks, Jason
(In reply to comment #19) > Should I open a different bug or stay with this one? Bugzilla is not a forum. The purpose of bugzilla is to have one number per issue, so that they are individually trackable. If one bug starts to take on multiple issues (like logout from hangs on different drivers, or other bugs within the affected driver) then the bug can not be closed until every issue associated with that bug is resolved. Please err on the side of filing too many bugs. If it turns out that multiple bugs are filed for the same issue they can be closed as duplicates; the reverse operation isn't possible, you can't close only part of a bug.
Sorry about the phenomenal bug spam, guys. Adding xorg-team@ to the QA contact so bugs don't get lost in future.
Is this still an issue? It hasn't been updated in a long time, and there is a lot of noise in here.
I'm the original reporter but we no longer have those systems so I can't check if the issue still exists or not. At this point that is a *very* old chipset so it's certainly okay with me if this is closed out.
Closing as wontfix.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.