1) when dri is disabled, suspend/resume just works in any case ;
2) when dri is enabled, and I suspend/resume from inside an xterm, X blocks on
resume (black screen, flashing lights, magic system key reboot required) ;
3) when dri is enabled, but I suspend/resume from console, things run
smoother... until I switch back to X, in which case we're back to the crashy
4) finally, if I boot without X and suspend/resume, then launch X with dri, then I get the crash.
So it looks like something in DRI-land doesn't like when a box has been resumed.
Here is what lspci -vvv says about my video system :
01:00.0 VGA compatible controller: ATI Technologies Inc M9+ 5C61 [Radeon
Mobility 9200 (AGP)] (rev 01) (prog-if 00 [VGA])
Subsystem: ASUSTeK Computer Inc. Unknown device 1811
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR+ FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 64 (2000ns min), Cache Line Size: 256 bytes
Interrupt: pin A routed to IRQ 10
Region 0: Memory at c0000000 (32-bit, prefetchable) [size=128M]
Region 1: I/O ports at d000 [size=256]
Region 2: Memory at feaf0000 (32-bit, non-prefetchable) [size=64K]
Expansion ROM at feac0000 [disabled] [size=128K]
Capabilities: <access denied>
I forgot (!) to mention that I'm running debian/unstable with a distribution-supplied linux 2.6.20 kernel.
Suspend to RAM or disk? Note that this could also be an AGP driver issue. Please attach (as opposed to paste) X config and log files and the dmesg output.
Created attachment 9996 [details]
Running dmesg after a clean startup
Created attachment 9997 [details]
Xorg log after a clean startup
Created attachment 9998 [details]
Running dmesg after a resume in console
Created attachment 9999 [details]
Xorg log after the resume
Created attachment 10000 [details]
There's a commented Disable "dri" line because I usually prefer having hibernation than 3d.
Ah, yes, I forgot to answer the first question : It's about hibernating (suspend to disk).
If I can provide more information...
I did some more tests this morning : suspend to disk or to ram shows the same problem.
I noticed that radeon(4) says AGP is enabled only with DRI... is there a way to still enable AGP without DRI, to see whether that's the problem as suggested?
(In reply to comment #9)
> I noticed that radeon(4) says AGP is enabled only with DRI... is there a way to
> still enable AGP without DRI, to see whether that's the problem as suggested?
The point is that AGP is only used by the DRI, so even if it could be 'enabled' without it that would hardly matter. Another way to test this could be Option "BusType" "PCI" to make the driver not use AGP.
I notice that you have an AGP 8X card, but is running it in 4X. There has been reported trouble when the BIOS sets it for one speed, and Xorg uses another. Although this was supposed to be fixed, can you try setting (in xorg.conf):
Option "AGPMode" "8"
or look at your BIOS settings?
I made the suggested tries :
- the BIOS doesn't give advanced settings about display ;
- setting the AGPMode to 8 didn't give improvement ;
- setting BusType to PCI makes resume work even with DRI.
So it looks like an AGP bug ; what more can I do to track the issue further?
Notice that if it's a matter of doing an apt-get source, patch the source (to enable more debugging output, for example), then compile a newer package, I'm used to it.
Waiting for directions : a dead bug always makes my day :-)
*** Bug 11216 has been marked as a duplicate of this bug. ***
Freedesktop's Bugzilla instance is EOLed and open bugs are about to be migrated to http://gitlab.freedesktop.org.
To avoid migrating out of date bugs, I am now closing all the bugs that did not see any activity in the past year. If the issue is still happening, please create a new bug in the relevant project at https://gitlab.freedesktop.org/drm (use misc by default).
Sorry about the noise!