Bug 2932

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.