Bug 117690 - (Radeon 7500) DRI breaks S3 Sleep
(Radeon 7500) DRI breaks S3 Sleep
Product: Fedora
Classification: Fedora
Component: XFree86 (Show other bugs)
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Mike A. Harris
Depends On: 117607
  Show dependency treegraph
Reported: 2004-03-07 04:01 EST by Warren Togami
Modified: 2007-11-30 17:10 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-03-18 23:36:26 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
radeon powermanagement patch (23.37 KB, patch)
2004-03-08 10:12 EST, Bill Nottingham
no flags Details | Diff
XFree86-4.3.0-radeon-power-management-v1.patch (21.93 KB, patch)
2004-03-08 22:30 EST, Warren Togami
no flags Details | Diff

  None (edit)
Description Warren Togami 2004-03-07 04:01:33 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6)
Gecko/20040225 Firefox/0.8

Description of problem:
kernel-2.6.3-2.1.242 (Note: Bug #117607 4G/4G breaks S3 sleep)

Load  "dri"
If this line is not commented out of /etc/X11/XF86Config then resuming
from "echo 3 > /proc/acpi/sleep", the entire system locks up if
suspended while in X graphics mode.  The graphical screen restores,
but the top of the display is corrupted and system is totally locked
up.  Please let me know if you need any other information.

<arjan> I guess it's a case of needing to stop and restore the
busmaster bit on the device
<arjan> mharris has had a lot of cases like that before
<arjan> and it's chipset specific

IBM Thinkpad T41

01:00.0 Class 0300: 1002:4c57
01:00.0 VGA compatible controller: ATI Technologies Inc Radeon
Mobility M7 LW [Radeon Mobility 7500] (prog-if 00 [VGA])
        Subsystem: IBM: Unknown device 0530
        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: 66 (2000ns min), Cache Line Size 08
        Interrupt: pin A routed to IRQ 11
        Region 0: Memory at e0000000 (32-bit, prefetchable)
        Region 1: I/O ports at 3000 [size=256]
        Region 2: Memory at c0100000 (32-bit, non-prefetchable) [size=64K]
        Capabilities: [58] AGP version 2.0
                Status: RQ=48 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64-
HTrans- 64bit- FW- AGP3- Rate=x1,x2,x4
                Command: RQ=1 ArqSz=0 Cal=0 SBA+ AGP- GART64- 64bit-
FW- Rate=<none>
        Capabilities: [50] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:01.0 Class 0604: 8086:3341 (rev 03)
00:01.0 PCI bridge: Intel Corp. 82855PM Processor to AGP Controller
(rev 03) (prog-if 00 [Normal decode])
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR+ FastB2B-
        Status: Cap- 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 96
        Bus: primary=00, secondary=01, subordinate=01, sec-latency=64
        I/O behind bridge: 00003000-00003fff
        Memory behind bridge: c0100000-c01fffff
        Prefetchable memory behind bridge: e0000000-e7ffffff
        Expansion ROM at 00003000 [disabled] [size=4K]
        BridgeCtl: Parity- SERR- NoISA+ VGA+ MAbort- >Reset- FastB2B-
Comment 1 Bill Nottingham 2004-03-08 10:10:59 EST
There's a patch in 4.4pre CVS for this for the XFree86 radeon driver.
Comment 2 Bill Nottingham 2004-03-08 10:12:08 EST
Created attachment 98370 [details]
radeon powermanagement patch

I believe this is the power management patch to fix suspend. Feel free to try
it (if it's not it, I'll grovel around on my laptop some more for it. :) )
Comment 3 Warren Togami 2004-03-08 22:30:18 EST
Created attachment 98390 [details]

Merged it manually minus the whitespace changes, and attempted build into
XFree86-4.3.0-62 and attempted build on FC1.  Strange build failure:

make[3]: Entering directory `/home/temp1/redhat/BUILD/XFree86-4.3.0/xc/lib/dps'

checking ../../config/pswrap/pswrap over in ../../config/pswrap first...
make[4]: Entering directory
gcc -m32 -O2  -pipe -march=i386 -mcpu=i686 -fno-strict-aliasing -pipe -ansi
-pedantic -Wall -Wpointer-arith -Wundef     -I../.. -I../../exports/include  
-Dlinux -D__i386__ -D_POSIX_C_SOURCE=199309L				  
-DNARROWPROTO	-DXENVIRONMENT	  -c -o main.o main.c
bison -y -d pswparser.y
conflicts: 1 shift/reduce
make[4]: *** [pswparser.c] Broken pipe
make[4]: Leaving directory
make[3]: *** [../../config/pswrap/pswrap] Error 2
make[3]: Leaving directory `/home/temp1/redhat/BUILD/XFree86-4.3.0/xc/lib/dps'
make[2]: *** [includes] Error 2
make[2]: Leaving directory `/home/temp1/redhat/BUILD/XFree86-4.3.0/xc/lib'
make[1]: *** [includes] Error 2
make[1]: Leaving directory `/home/temp1/redhat/BUILD/XFree86-4.3.0/xc'
make: *** [World] Error 2
make: Leaving directory `/home/temp1/redhat/BUILD/XFree86-4.3.0/xc'
error: Bad exit status from /var/tmp/rpm-tmp.59063 (%build)

Tried the same patch on XFree86-4.3.0-63 on FC1.90, build failure below.  I
suspect a portion of the patch from upstream CVS is missing?

gcc -m32 -O2  -pipe -march=i386 -mcpu=i686 -fno-strict-aliasing -pipe -ansi
-pedantic -Wall -Wpointer-arith -Wundef    -fno-merge-constants -I.
-I../../../../../../programs/Xserver/fb -I../../../../../../programs/Xserver/mi
-I../../../../../../programs/Xserver/GL/dri -I../../../../../../lib/GL/dri
-I../../../../../../include -I../../../../../../include/fonts
-I../../../../../../include/extensions -I../../../../../../exports/include/X11 
-I../../../../../.. -I../../../../../../exports/include -Dlinux -D__i386__
			 -DXFree86LOADER  -DXFree86Server		       
	  -DXF86VIDMODE 			  -DXvMCExtension    
-DSMART_SCHEDULE				  -DXResExtension	       
radeon_driver.c: In function `RADEONSetDynamicClock':
radeon_driver.c:6917: error: structure has no member named `RamWidth'
radeon_driver.c:6918: error: `R300_MEM_USE_CD_CH_ONLY' undeclared (first use in
this function)
radeon_driver.c:6918: error: (Each undeclared identifier is reported only once
radeon_driver.c:6918: error: for each function it appears in.)
make[7]: *** [radeon_driver.o] Error 1
make[7]: Leaving directory

make[6]: *** [all] Error 2
make[6]: Leaving directory

make[5]: *** [all] Error 2
make[5]: Leaving directory
make[4]: *** [hw/xfree86] Error 2
make[4]: Leaving directory
make[3]: *** [all] Error 2
make[3]: Leaving directory
make[2]: *** [all] Error 2
make[2]: Leaving directory `/home/builder/rpmbuild/BUILD/XFree86-4.3.0/xc'
make[1]: *** [World] Error 2
make[1]: Leaving directory `/home/builder/rpmbuild/BUILD/XFree86-4.3.0/xc'
make: *** [World] Error 2
make: Leaving directory `/home/builder/rpmbuild/BUILD/XFree86-4.3.0/xc'
error: Bad exit status from /var/tmp/rpm-tmp.74576 (%build)
Comment 4 Mike A. Harris 2004-03-08 23:46:42 EST
Arjan) I don't think this is a busmaster enable issue, but warren
can test for that by doing lspci -vvv before suspending, then
switching to tty1 prior to suspend, then resume and run lspci -vvv
again to see if the busmaster bit was disabled.  That usually
prevents X from hanging for those cases.

Unfortunately, the thing is that many changes have occured in XFree86
developement CVS in the radeon driver since Charl's dri-resume patch
went into the tree, and it's non-trivial to isolate each possible bug
fix from the larger changes that have occured in the last year (it's
about 12 months or so since Charl wrote the initial patch).  While
it is definitely possible to backport all of the relevant bits,
and include it, there are some really good reasons why not to do
this, which I'd like to touch upon:

Our current Radeon driver is very heavily patched already, and
maintenance of it becomes more and more difficult with each
overlapping patch that is applied.  It would be easier to maintain
the driver in a separate CVS repository directly than to keep
patching it.  Some of the patches we apply are applied conditionally,
or there is need to enable some of them only for certain builds,
which complicates thigns when patches overlap, as you need to
maintain multiple patches that add the same functionality, but
depend on which other conditionalized patches are being applied.

Another issue, is that in the past, the XFree86 side changes for
dri-resume patch to work, required kernel side changes as well,
and it was never clear for a long time wether all of our supported
OS releases got the patches for this from DRI CVS or not.  Since
we share XFree86 4.3.0 across RHL 9, FC1, RHEL3, it would have to
be in the kernels of all of those releases in order to keep
unnecessary conditionalization stew out of the spec file.  ;o)
I do not know if each OS release we ship 4.3.0 in has the needed
changes or not, and it's been so long now since the patches were
made that it would require research to make sure it would work in
all OS releases.

Additionally, this is a rather intrusive change, and has never
been tested in the distribution proper, so it is not without risk
of regression, which is particularly bad for the case of RHEL3,
and a risk I would rather not take.  To conditionalize the patch(es)
out for RHEL3 invites additional maintenance burden as described
above due to overlapping patches.

The good news however, is that XFree86 4.4.0 has full support for
this, and the X.org server tree has also.  We are planning on
putting X.org into the tree within the next few weeks anyway, so
this functionality comes for free at that time with no engineering
effort, and with much less risk of regression, and also is built
into the upstream codebase, so has zero maintenance costs.  ;o)

RHL 9 goes EOL at the end of April IIRC, and Fedora Core 2 will
be coming out not long after that.  RHEL 3 with 4.3.0 has to be
supported for 5 years however, and the risk of regression to RHEL
to add support for this when the 2 main products it benefits would
be EOL within months is not worth it, considering everyone is likely
to upgrade to Fedora Core 2 when it is out (if not before then).

The rpms of xorg-x11 once ready will most likely be installable
on Fedora Core 1 and later unless I need to break that for some
reason, and quite possibly will install on Red Hat Linux 9 with
some updates from newer OS releases.

So for the time being, it is not that this problem is unfixable,
but rather that 4.3.0 has reached near end of life for us, and
spending any engineering resources on possibly regression risky
patches in the src.rpm which must share with RHEL3 and be supported
for 4.5 more years, when we're ditching 4.3.0 ultrasoon is just
not worth the risk IMHO.

So for now, my recommendation is to wait a few weeks and upgrade
to xorg X11 and it's radeon driver.  I'll update this when xorg
is in the tree.
Thanks for your patience.  ;o)
Comment 5 Warren Togami 2004-03-18 23:36:26 EST
It seems that this is fixed in xorg-x11!  Now only Bug #117607
prevents S3 sleep from working on the Thinkpad T40 and T41.

Note You need to log in before you can comment on or make changes to this bug.