Bug 264720

Created attachment 131227 [details]
/etc/X11/xorg.conf

Forget to mention: This is with
  xorg-x11-driver-video-7.2-77 (build Fri Apr 6)
the newest available on Factory.

What's the latest RPM changelog of the package?

xorg-x11-driver-video-7.2-77:

* Tue Apr 03 2007 - sndirsch@suse.de
- updated "nvrandr12" driver to current git:
  * G80: Get HW cursor working with RandR 1.2
- added two nv driver patches (xf86-video-nv-{1,2}.diff)
  * X.Org Bug #10360: Need to inject a mode corresponding panel
  width/height for validation
  * Remove extraneous DisplayModeRec allocation (Thanks to Luc
  Verhaegen for pointing this out)

Ok. This is too old. You'll need this one to verify.

-------------------------------------------------------------------
Thu Apr 12 20:43:12 CEST 2007 - sndirsch@suse.de

- bug-263199_radeon-mergedfb-crash.diff:
  * fixed MergedFB related Xserver crash (Bug #263199)

I suggest to use the package from the buildservice (xorg73 project) if
Factory is too old.

> Ok. This is too old. You'll need this one to verify.

I expected so, but there is no newer in Factory.

> I suggest to use the package from the buildservice (xorg73 project)
Thanks for the pointer.

X seems to run ok now (so far at least) thus I close this bug. If it is not fixed, I will reopen it.

Ok. Thanks for testing.

While X is more stable, I still have problems. Yesterday morning I logged in (with KDM, at home) and in the evening I found the KDM screen with the mouse frozen and the usb keyboard too. A look in the Xorg.0.log.old this morning showed:


Apr 19 14:23 /var/log/Xorg.0.log.old:

(II) Mouse[1]: ps2EnableDataReporting: succeeded
Could not init font path element unix/:7100, removing from list!
(**) RADEON(0): RADEONSaveScreen(2)
(**) RADEON(0): RADEONSaveScreen(0)
(**) RADEON(0): RADEONSaveScreen(2)
(**) RADEON(0): RADEONDisplayPowerManagementSet(1,0x0)

Backtrace:
0: /usr/bin/Xorg(xf86SigHandler+0x6d) [0x4921cd]
1: /lib64/libc.so.6 [0x2ace61213410]
2: /usr/lib64/xorg/modules//drivers/radeon_drv.so [0x2ace628eaa5b]
3: /usr/lib64/xorg/modules//drivers/radeon_drv.so(RADEONDisplayPowerManagementSet+0x1f0) [0x2ace628ead90]
4: /usr/bin/Xorg(DPMSSet+0xce) [0x49444e]
5: /usr/bin/Xorg [0x56a37c]
6: /usr/bin/Xorg [0x56a608]
7: /usr/bin/Xorg(WaitForSomething+0x657) [0x56ad27]
8: /usr/bin/Xorg(Dispatch+0x9a) [0x450b9a]
9: /usr/bin/Xorg(main+0x45d) [0x439a0d]
10: /lib64/libc.so.6(__libc_start_main+0xf4) [0x2ace61200944]
11: /usr/bin/Xorg(FontFileCompleteXLFD+0x229) [0x438d09]

Fatal server error:
Caught signal 11.  Server aborting

(**) RADEON(0): RADEONDisplayPowerManagementSet(0,0x0)


Status is current Factory (11 April) with (only) xorg-x11-driver-video from xorg73 on the build server (xorg-x11-driver-video-7.2-196.1, last entry:
* Fri Apr 13 2007 sndirsch@suse.de
- bug-263199_radeon-autocrt.diff)

*** Bug 266549 has been marked as a duplicate of this bug. ***

I can still cause a crash with the lastest driver package:

jpr@rook:~> rpm -q xorg-x11-driver-video
xorg-x11-driver-video-7.2-83

jpr@rook:~> rpm -q --changelog xorg-x11-driver-video | more
* Wed Apr 18 2007 - sndirsch@suse.de
- updated nv driver to release 2.0.2:
  * This release adds product names for the GeForce 8600 GTS and GT,
  and the GeForce 8500 GT. It also contains a fix for bug 10360.
- obsoletes xf86-video-nv-1.diff, xf86-video-nv-2.diff

Created attachment 132834 [details]
xorg log of crash with xorg-x11-driver-video-7.2-83 and gnome-screensaver locking

(In reply to comment #9)
> I can still cause a crash with the lastest driver package:
Sure this bug has not been fixed yet. ;-)

Raising severity.

Looks like or similar to https://bugs.freedesktop.org/show_bug.cgi?id=10772
"xf86-video-ati-6.6.191 segfaults when a client makes it enter RADEONDisplayPowerManagementSet() on a r200 card"

Any chance to install the -debuginfo packages for xorg-x11-server and xorg-x11-driver-video so we'll get some more useful debug output? Is it
possible to trigger the crash with

  1)  xset dpms force standby; sleep 2; xset dpms force on
  2)  xset dpms force suspend; sleep 2; xset dpms force on
  3)  xset dpms force off; sleep 2; xset dpms force on

Which one?

(In reply to comment #14)
> Is it possible to trigger the crash with
> 
>   1)  xset dpms force standby; sleep 2; xset dpms force on
>   2)  xset dpms force suspend; sleep 2; xset dpms force on
>   3)  xset dpms force off; sleep 2; xset dpms force on
> 
> Which one?

Question was adressed to JP.

Tobias, could you try to trigger it with

  xset dpms force standby

I can't reproduce this issue with a *very* similar card

  Model: "ATI FireGL V3100 (RV370) 5B64 (PCIE)"
  Vendor: pci 0x1002 "ATI Technologies Inc"
  Device: pci 0x5b64 "FireGL V3100 (RV370) 5B64 (PCIE)"

with the xorg.conf attached to comment #1.

# xset dpms force standby

(**) RADEON(0): RADEONSaveScreen(2)
(**) RADEON(0): RADEONSaveScreen(0)
(**) RADEON(0): RADEONDisplayPowerManagementSet(1,0x0)
(**) RADEON(0): RADEONSaveScreen(2)
(**) RADEON(0): RADEONSaveScreen(1)
SetClientVersion: 0 9
SetGrabKeysState - disabled

>> pressed a key to wake up <<

(**) RADEON(0): RADEONDisplayPowerManagementSet(0,0x0)
(**) RADEON(0): RADEONSaveScreen(2)
SetGrabKeysState - enabled
(**) RADEON(0): RADEONSaveScreen(2)

I even can't reproduce when using a MergedFB configuration as JP uses.

Tobias, see my question in comment #15.
JP, see my question in comment #14.

> Any chance to install the -debuginfo packages for xorg-x11-server and
> xorg-x11-driver-video so we'll get some more useful debug output?

Is there anything else required besides installing it and running it normally?
I just installed it, started X and got after a while the usual backtrace in Xorg.0.log. I don't see more debug information than before.

With xset dpms I will play when I come home.

Hmm ... probably you need to run the Xserver in the debugger then. Difficult if you're not familiar with gdb. :-( Might be not to complicated when you can trigger the crash with xset. So test this first.

> Hmm ... probably you need to run the Xserver in the debugger then.
> Difficult if you're not familiar with gdb

I have a problem with gdb:

$ gdb /var/X11R6/bin/X
GNU gdb 6.6
[...]
(gdb) run
Starting program: /var/X11R6/bin/X
[...]
[Thread debugging using libthread_db enabled]
[New Thread 47034746995472 (LWP 7772)]
Error while reading shared library symbols:
Cannot find new threads: generic error
linux-nat.c:546: internal-error: wait returned unexpected status 0x4057f
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) y
linux-nat.c:546: internal-error: wait returned unexpected status 0x4057f
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Create a core file of GDB? (y or n) n

This seems to be similar to http://www.nabble.com/generic-error-with-a-statically-linked-multithreaded-program-t3529790.html
except that gdb does not hang (the X server still runs after gdb quit).

I tried it with the Intel idb, but it only shows:

(**) RADEON(0): RADEONDisplayPowerManagementSet(1,0x0)
Backtrace:
0: /usr/bin/Xorg(xf86SigHandler+0x6d) [0x49227d]
1: /lib64/libc.so.6 [0x2ab2a2b86410]
2: /usr/lib64/xorg/modules//drivers/radeon_drv.so [0x2ab2a425db7b]
3: /usr/lib64/xorg/modules//drivers/radeon_drv.so(RADEONDisplayPowerManagementSet+0x1f0) [0x2ab2a425deb0]
[...]
Caught signal 11.  Server aborting
(**) RADEON(0): RADEONDisplayPowerManagementSet(0,0x0)
Process has exited
Reading symbolic information from /usr/bin/Xorg...No debugging symbols found
Could not load symbols for /usr/bin/Xorg ... Recovering ...

If you have an idea where to place a break point, I can try again.

Sure that you installed the -debuginfo packages? BTW, the question for triggering the crash is still open.

> >   1)  xset dpms force standby; sleep 2; xset dpms force on
> >   2)  xset dpms force suspend; sleep 2; xset dpms force on
> >   3)  xset dpms force off; sleep 2; xset dpms force on
All this triggers the bug.


> Sure that you installed the -debuginfo packages?
Yes, I installed the two packages, however, the glibc build in backtrace does not seem to use it. The Intel idb does not seem to support it (I filled a bug report) and gdb had the internal error (bug #270948).

I tried addr2line on the backtrace, but it does not print lines :-(

> BTW, the question for triggering the crash is still open.
True, but but it is difficult to trigger this remotely.

Try the following:

xf86debug -ac :1 &
DISPLAY=:1 xset dpms force standby

Attach /tmp/xf86debug.<tempfile-extension>

> Try the following:
> xf86debug -ac :1 &
> DISPLAY=:1 xset dpms force standby
Thanks, nice to know how to do this properly.

> Attach /tmp/xf86debug.<tempfile-extension>
But due to bug #270948 this does not help. Last lines:

linux-nat.c:546: internal-error: wait returned unexpected status 0x4057f
A problem internal to GDB has been detected,
Quit this debugging session? (y or n) [answered Y; input not from terminal]

Maybe the problem is x86_64 specific (including gdb). JP, does gdb work for you? Can you provide the backtrace output?

RADEONDPMSSetOff (pScrn=0x7ffb30, pPort=0x0) at radeon_display.c:2237
2237      MonType = pPort->MonType;
(gdb) bt
#0  RADEONDPMSSetOff (pScrn=0x7ffb30, pPort=0x0) at radeon_display.c:2237
#1  0x00002ac2af42aeb0 in RADEONDisplayPowerManagementSet (pScrn=0x7ffb30, PowerManagementMode=1, flags=0) at radeon_display.c:2373
#2  0x00000000004944fe in DPMSSet (level=1) at xf86DPMS.c:168
#3  0x00002ac2aedb3069 in ProcDPMSForceLevel (client=0xcbb790) at dpms.c:256
#4  0x0000000000450d6b in Dispatch () at dispatch.c:457
#5  0x0000000000439a8d in main (argc=10, argv=0x7ffffdca6cd8, envp=<value optimized out>) at main.c:445

(gdb) p pPort
$1 = (RADEONConnector *) 0x0

Reassigning to Matthias. I'm afraid we rely on JP and his machine (x86_64) since I could not reproduce on i386, but the freedesktop.org bug was reported against i386. So I don't think I can reproduce this here by installing a x86_64 system.

What do you want be to try?

I don't know yet. But if you don't kill this installation for now, this would  be great. 

> RADEONDPMSSetOff (pScrn=0x7ffb30, pPort=0x0) at radeon_display.c:2237
> 2237      MonType = pPort->MonType;
> #0  RADEONDPMSSetOff (pScrn=0x7ffb30, pPort=0x0) at radeon_display.c:2237

Not that this is necessarily the cause for the problem, but as long as

RADEONConnector *RADEONGetCrtcConnector(ScrnInfoPtr pScrn, int crtc_num)

can return NULL

static void RADEONDPMSSetOff(ScrnInfoPtr pScrn, RADEONConnector *pPort)

should not use it unguarded. (Both: xf86-video-ati-6.6.191/src/radeon_display.c)

How about as interim measure:

-  MonType = pPort->MonType;
-  TmdsType = pPort->TMDSType;
-  DacType = pPort->DACType;
+  MonType = (pPort != NULL) ? pPort->MonType : MT_UNKNOWN;
+  TmdsType = (pPort != NULL) ? pPort->TMDSType : TMDS_UNKNOWN;
+  DacType = (pPort != NULL) ? pPort->DACType : DAC_UNKNOWN;

in RADEONDPMSSetOff ? I think good programming style mandates this even though one should find out why RADEONGetCrtcConnector returns NULL.

JFYI.

See also

  http://bugs.freedesktop.org/show_bug.cgi?id=10772

Any new status? Anything I can do? Having a locked-up computer if one is interrupted for a bit longer bugs me quite a lot.

Created attachment 151445 [details]
0001-Clean-up-PortInfo-to-CRTC-mapping.txt

Fix by Luc.

Created attachment 151449 [details]
radeon-Clean-up-PortInfo-to-CRTC-mapping.diff

Patch against 6.6.192. The previous one was against git head.

Created attachment 151456 [details]
radeon-Clean-up-PortInfo-to-CRTC-mapping.diff

fixed patch

Created attachment 151472 [details]
xorg-x11-driver-video-7.2-132.i586.rpm

Created attachment 151473 [details]
xorg-x11-driver-video-7.2-132.x86_64.rpm

Tobias, JP, could you test the RPMs with the patch applied? Thanks.

> Tobias, JP, could you test the RPMs with the patch applied? Thanks.

I could only try remotely using "startx -- :1"; DISPLAY=:1 and
  1)  xset dpms force standby; sleep 2; xset dpms force on
  2)  xset dpms force suspend; sleep 2; xset dpms force on
  3)  xset dpms force off; sleep 2; xset dpms force on
and the console output was fine and X continued to run. 

Thanks. Sounds encouraging. What about you, JP?

>   1)  xset dpms force standby; sleep 2; xset dpms force on
>   2)  xset dpms force suspend; sleep 2; xset dpms force on
>   3)  xset dpms force off; sleep 2; xset dpms force on

I now tested locally and all these work. However, and I don't know whether it is related or not (I think it is): If I press "Alt-Ctrl-F2" to change to a virtual console, the screen gets blank, X restarts and I end up in kdm. The log output (standard out/error of "startx -- :1") does not show much, though one wonders why it talks about CRTC2.

(**) RADEON(0): RADEONLeaveVT
(**) RADEON(0): EngineRestore (32/32)
(**) RADEON(0): RADEONRestore
(**) RADEON(0): RADEONRestoreMode(0x801160)
(**) RADEON(0): RADEONRestoreMemMapRegisters() :
(**) RADEON(0):   MC_FB_LOCATION   : 0x1fff0000
(**) RADEON(0):   MC_AGP_LOCATION  : 0x27ff2000
(**) RADEON(0):   Map Changed ! Applying ...
(**) RADEON(0):   Map applied, resetting engine ...
(**) RADEON(0): Updating display base addresses...
(**) RADEON(0): Memory map updated.
(**) RADEON(0): Programming CRTC2, offset: 0x00000000
(**) RADEON(0): Wrote: 0x00000000 0x00000000 0x00000000 (0x0000a400)
(**) RADEON(0): Wrote: rd=0, fd=0, pd=0
(**) RADEON(0): Programming CRTC1, offset: 0x00000000
(**) RADEON(0): Wrote: 0x0030000c 0x00030065 0x00000000 (0x0000a700)
(**) RADEON(0): Wrote: rd=12, fd=101, pd=3
ksmserver: Fatal IO error: client killed

So does this issue already happened to the older driver?

I won't be able to try this until next week.

> So does this issue already happened to the older driver?
Using Factory's xorg-x11-driver-video-7.2-130
  * Tue Jul 10 2007 - sndirsch@suse.de
  - xf86-video-nv.diff:
I can flip repeatedly between X11 and the virtual console without any problems.

Ok. This is the driver without the patch. So the patch introduced a regression. :-(

Created attachment 151663 [details]
Missing symbol.

This is one of the few drivers where the upstream developers never had the heart to actually enable -Wall as a CFLAG. This means that you don't get warned about missed conversions like this, a luxury i myself do have on my upstream drivers, one i seem to actively depend on too :)

Created attachment 151682 [details]
xorg-x11-driver-video-7.2-133.i586.rpm

fixed RPM.

Created attachment 151684 [details]
xorg-x11-driver-video-7.2-133.x86_64.rpm

fixed RPM.

Tobias, JP, could you test the new RPMs with the fixed patch applied? Thanks.

> Tobias, JP, could you test the new RPMs with the fixed patch applied? Thanks.
First, I would like to thank Luc for the patches and Stefan for the packages.

Secondly, it works better but still not fully.

If switch to the console and back, X still runs.

However, if I switch to the console, the following happens:
The screen gets blank/black (ok so far) and shows then a still image of the X11 screen, where in the first half centimetre is overwritten by a black half-screenwide bar. Below for one and a half centimetres the the X11 screen has a turquoise tint. If I press a key, the image shown does not change (and as expected mouse moves don't change anything either), but at least num lock works.

Switching back to X11: black screen and then the normal X11 (hooray!).

> > Tobias, JP, could you test the new RPMs with the fixed patch applied? Thanks.
> Secondly, it works better but still not fully.

I now also rebooted the computer instead of only restarting X and it works now; sorry for the confusion.

Everything working here now as well.

Now fixed upstream as well.

commit a156db5e8b037ed12a448f70045453baf9d0c504
Author: Luc Verhaegen <libv@skynet.be>
Date:   Sat Aug 4 17:37:18 2007 +1000

    Clean up PortInfo to CRTC mapping
    
    Also sanitise blanking and DPMS functions
    
    Fixes from Novell Bug 264720, and fd.o 10772