Created attachment 19545 [details] Xorg log from a crash I have been experiencing several bugs with the Xorg-video-ati driver 6.9.0 and GIT on my RS690 based X1200 card in my laptop. This particular bug pertains EXA crashing the Xserver when "viewing pictures". The best way to describe it is that the system becomes unresponsive as soon as panning of a picture (despite the program being used) starts. I have been able to SSH into the machine and see what processes are active. Xorg eats anywhere between 99-150% CPU (the laptop CPU is dual core). There is nothing out of the ordinary in system-log, dmesg and only one time I've been able to get something in Xorg.0.log about the Xserver entering an infinite loop, never too reliably, though. The "crash" always happens with any image file if zoomed in or at normal size when viewed on any program as soon as I start panning, the system becomes unresponsive, mouse jerky, I don't seem able to snap out of X [ctrl+alt+Fx]. This only happens when Option "AccelMethod" "EXA" is enabled in xorg.conf, when using XAA performance is noticeably slower in 2D in general, but X doesn't crash. I'm using Xorg-video-ati 6.9.0 release built from source against Xorg 1.5.0 on Fedora 9, the same happens with the driver built from GIT. It may be worth noting that with XServer 1.4.99 EXA worked just fine, but with release 1.5 it does not.
(In reply to comment #0) > This particular bug pertains EXA crashing the Xserver when "viewing pictures". > The best way to describe it is that the system becomes unresponsive as soon as > panning of a picture (despite the program being used) starts. I have been able > to SSH into the machine and see what processes are active. Xorg eats anywhere > between 99-150% CPU (the laptop CPU is dual core). There is nothing out of the > ordinary in system-log, dmesg and only one time I've been able to get something > in Xorg.0.log about the Xserver entering an infinite loop, never too reliably, > though. The "crash" always happens with any image file if zoomed in or at > normal size when viewed on any program as soon as I start panning, the system > becomes unresponsive, mouse jerky, I don't seem able to snap out of X > [ctrl+alt+Fx]. > Sounds like a GPU lockup. > This only happens when Option "AccelMethod" "EXA" is enabled in xorg.conf, when > using XAA performance is noticeably slower in 2D in general, but X doesn't > crash. I'm using Xorg-video-ati 6.9.0 release built from source against Xorg > 1.5.0 on Fedora 9, the same happens with the driver built from GIT. Does: Option "renderaccel" "false" help? > > It may be worth noting that with XServer 1.4.99 EXA worked just fine, but with > release 1.5 it does not. when you say "just fine" do you mean "didn't used to hang" or something else? Any chance you could use git bisect on the xserver to track down what commit between 1.4.99 and 1.5 broke things?
(In reply to comment #1) > > Sounds like a GPU lockup. > > > This only happens when Option "AccelMethod" "EXA" is enabled in xorg.conf, when > > using XAA performance is noticeably slower in 2D in general, but X doesn't > > crash. I'm using Xorg-video-ati 6.9.0 release built from source against Xorg > > 1.5.0 on Fedora 9, the same happens with the driver built from GIT. > > Does: > Option "renderaccel" "false" > help? > > > > > It may be worth noting that with XServer 1.4.99 EXA worked just fine, but with > > release 1.5 it does not. > > when you say "just fine" do you mean "didn't used to hang" or something else? > Any chance you could use git bisect on the xserver to track down what commit > between 1.4.99 and 1.5 broke things? > First of all, thanks for replying, Alex. By "working just fine" with 1.4.99 I mean that X doesn't crash under pretty much any circumstances or at least not any of the ones which consistently crash with EXA on 1.5.0... Just tried with the RadeonHD driver from GIT (the one with pretty much the same degree of support than the Radeon driver) and this problem also happens. It takes a bit more (more panning "passes"), but still happens. So I do believe that this might have more to do with the XServer than the drivers themselves. How would I use that "git bisect"? Maybe it could be worth to bring this to the attention of the XServer maintainers of Fedora? I will try your suggestions for redneraccel, see what happens and report back.
Well, just did what you suggested, and it indeed does help. The system (or X?) doesn't hang any more when panning an image larger than the current size of the window with Option "renderaccel" "false" in xorg.conf. The only difference I'm able to tell is that there is some tearing of the image when it is panned (not such a big problem), I don't know if this has any other repercussions, though like tearing with XV or the like, will have to do some tests, but in the mean time, it would seem that X no longer crashes.
I may have spoken too soon... I'm just rebooting from a hang when I was about to close a window. I was able to recover two Xorg.0.log files, but I don't know which one is relevant (Xorg.0.log and Xorg.1.log) for my original report I erased all Xorg*log files from /var/log and caused the crashed, booted into run level 3 to not generate another and copy the only Xorg log to my home directory. I did the same this time around, but there were three files: Xorg.0.log, Xorg.0.log.old and Xorg.1.log, the .old one seems to be the resulting Xorg.0.log from the previous session before I did the change to xorg.conf to disable renderaccel. At any rate, I attach both files.
Created attachment 19550 [details] Xorg.0.log from last session.
Created attachment 19551 [details] Xorg.1.log discovered after reboot
Did some tests during the weekend, incluidng using a LiveUSB persistent environment of Fedora 9 which comes with XServer 1.4.99 and XF86-video-ati driver version 6.8.0 Xorg -version X.Org X Server 1.4.99.901 (1.5.0 RC 1) Release Date: 5 September 2007 X Protocol Version 11, Revision 0 Build Operating System: Linux 2.6.18-53.1.14.el5xen i686 Current Operating System: Linux localhost.localdomain 2.6.25-14.fc9.i686 #1 SMP Thu May 1 06:28:41 EDT 2008 i686 Build Date: 06 May 2008 03:35:07PM Build ID: xorg-x11-server 1.4.99.901-29.20080415.fc9 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Module Loader present Xorg.0.log (II) Module ati: vendor="X.Org Foundation" compiled for 1.4.99.901, module version = 6.8.0 Module class: X.Org Video Driver ABI class: X.Org Video Driver, version 4.0 This combination doesn't exhibit the problem of random crashes with EXA, though I still experience (much more at random it would seem) crashes without EXA, and having disabled Render acceleration. The only conclusion I can draw from this is that when EXA is enabled, these crashes are much more defined, easily reproducible and clear, and this has something to do with an interaction between the XF86-video-ati driver and XServer 1.5.0, other than that, I'm lost. From what I have been able to see from other bug reports, it would seem that this kind of problem is not local to the ati/radeonhd drivers, and affects also other drivers, so this would seem more of an XServer/Xorg problem than a driver isolated issue. However, I have no way to corroborate this assumption.
Since this problem is not local to the radeon driver, becaus it also happens with RadeonHD driver. So I was wondering if the component should be changed? For what is worth, here's the output of lspci -vvv regarding the VGA: 01:05.0 VGA compatible controller: ATI Technologies Inc RS690M [Radeon X1200 Series] (prog-if 00 [VGA controller]) Subsystem: Toshiba America Info Systems Unknown device ff1a Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 64, Cache Line Size: 32 bytes Interrupt: pin A routed to IRQ 11 Region 0: Memory at f0000000 (64-bit, prefetchable) [size=128M] Region 2: Memory at f8100000 (64-bit, non-prefetchable) [size=64K] Region 4: I/O ports at 9000 [size=256] Region 5: Memory at f8000000 (32-bit, non-prefetchable) [size=1M] Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [80] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable- Address: 0000000000000000 Data: 0000
(In reply to comment #7) > This combination doesn't exhibit the problem of random crashes with EXA, though > I still experience (much more at random it would seem) crashes without EXA, and > having disabled Render acceleration. Sounds like there's a reproducible problem with RENDER acceleration and at least one additional problem that is less reproducible. The older driver version probably didn't have RENDER acceleration yet. > From what I have been able to see from other bug reports, it would seem that > this kind of problem is not local to the ati/radeonhd drivers, and affects also > other drivers, so this would seem more of an XServer/Xorg problem than a driver > isolated issue. More likely just several driver specific issues. In particular, I think the radeonhd driver uses more or less the same acceleration code as the radeon driver.
Can you try with the latest code in ati git master? I've pulled in some stability fixes that may help.
I don't seem to be able to build a git clone. I get the following error message when I attempt to ./configure (do I need to install Xinerama support and -devel packages?) [ Configure] ./configure: line 20833: syntax error near unexpected token `XINERAMA,' ./configure: line 20833: `XORG_DRIVER_CHECK_EXT(XINERAMA, xineramaproto)' [/Configure]
> --- Comment #11 from Gian Paolo Mureddu <gmureddu@prodigy.net.mx> 2008-12-03 12:46:42 PST --- > I don't seem to be able to build a git clone. I get the following error message > when I attempt to ./configure (do I need to install Xinerama support and -devel > packages?) > you need the devel package for xserver, and point aclocal at xorg-server.m4 if it isn't installed in a standard place.
Is this still a problem?
closing due to lack of feedback.
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.