Bug 10975

Summary: Enabling DRI makes X crash on resumed box
Product: DRI Reporter: Julien Puydt <julien.puydt>
Component: DRM/otherAssignee: Default DRI bug account <dri-devel>
Status: RESOLVED INVALID QA Contact:
Severity: normal    
Priority: medium CC: radimluza
Version: XOrg git   
Hardware: x86 (IA32)   
OS: All   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
Running dmesg after a clean startup
none
Xorg log after a clean startup
none
Running dmesg after a resume in console
none
Xorg log after the resume
none
My xorg.conf none

Description Julien Puydt 2007-05-16 23:49:55 UTC
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
case ;
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>
Comment 1 Julien Puydt 2007-05-16 23:53:08 UTC
I forgot (!) to mention that I'm running debian/unstable with a distribution-supplied linux 2.6.20 kernel.
Comment 2 Michel Dänzer 2007-05-17 02:23:55 UTC
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.
Comment 3 Julien Puydt 2007-05-17 08:02:43 UTC
Created attachment 9996 [details]
Running dmesg after a clean startup
Comment 4 Julien Puydt 2007-05-17 08:04:17 UTC
Created attachment 9997 [details]
Xorg log after a clean startup
Comment 5 Julien Puydt 2007-05-17 08:58:39 UTC
Created attachment 9998 [details]
Running dmesg after a resume in console
Comment 6 Julien Puydt 2007-05-17 09:02:07 UTC
Created attachment 9999 [details]
Xorg log after the resume
Comment 7 Julien Puydt 2007-05-17 09:04:41 UTC
Created attachment 10000 [details]
My xorg.conf

There's a commented Disable "dri" line because I usually prefer having hibernation than 3d.
Comment 8 Julien Puydt 2007-05-17 09:09:01 UTC
Ah, yes, I forgot to answer the first question : It's about hibernating (suspend to disk).

If I can provide more information...
Comment 9 Julien Puydt 2007-05-31 22:43:25 UTC
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?
Comment 10 Michel Dänzer 2007-06-01 00:18:24 UTC
(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.
Comment 11 Tormod Volden 2007-06-01 00:27:22 UTC
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?
Comment 12 Julien Puydt 2007-06-01 04:11:08 UTC
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?
Comment 13 Julien Puydt 2007-06-03 01:59:40 UTC
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 :-)
Comment 14 Timo Jyrinki 2007-06-27 03:10:09 UTC
*** Bug 11216 has been marked as a duplicate of this bug. ***
Comment 15 Martin Peres 2019-10-14 13:20:11 UTC
Hi,

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!

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.