Bug 152473

Summary: radeon driver broken on T41p
Product: [openSUSE] SUSE Linux 10.1 Reporter: Christoph Thiel <cthiel>
Component: X.OrgAssignee: Stefan Dirsch <sndirsch>
Status: RESOLVED FIXED QA Contact: Stefan Dirsch <sndirsch>
Severity: Normal    
Priority: P2 - High CC: dmueller, eich, gp, mdanzer, suse-beta
Version: Beta 4   
Target Milestone: ---   
Hardware: Other   
OS: Other   
Whiteboard:
Found By: Other Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---
Attachments: Xorg.0.log
xorg.conf
New RPM for testing.
New RPM for testing
Final RPM for testing
Gerald's xorg.conf
Gerald's Xorg.0.log

Description Christoph Thiel 2006-02-21 13:35:07 UTC
Rewriting fglrx to radeon causes a black and therefore an unsuable maschine after updating xorg packages. I'll attach logfiles.
Comment 1 Christoph Thiel 2006-02-21 13:43:21 UTC
Created attachment 69565 [details]
Xorg.0.log
Comment 2 Christoph Thiel 2006-02-21 13:43:36 UTC
Created attachment 69566 [details]
xorg.conf
Comment 3 Stefan Dirsch 2006-02-21 13:54:48 UTC
Hmm ... does removing ' Load         "dri" ' in xorg.conf help?

Comment 4 Stefan Dirsch 2006-02-21 14:12:35 UTC
First problem. Since /root/xorg.conf exists this config file is used instead of /etc/X11/xorg.conf. :-(
Comment 5 Stefan Dirsch 2006-02-21 14:45:16 UTC
The problem is, that the radeon driver does not work (any more). Even with a clean xorg.conf for the radeon driver with DRI disabled.

[...]
(==) RADEON(0): Write-combining range (0xe0000000,0x8000000)
(II) RADEON(0): Dynamic Clock Scaling Disabled
(WW) RADEON(0): Enabling DRM support

        *** Direct rendering support is highly experimental for Radeon 9500
        *** and newer cards. The 3d mesa driver is not provided in this tree.
        *** A very experimental (and incomplete) version is available from Mesa CVS.
        *** Additional information can be found on http://r300.sourceforge.net
        *** This message has been last modified on 2005-08-07.

(II) RADEON(0): BIOS HotKeys Disabled
--> Here it hangs. :-(
Comment 6 Stefan Dirsch 2006-02-21 14:49:05 UTC
Even using 

  Option "noaccel"
  Option "BIOSHotKeys" "off"

didn't help. :-(

(II) RADEON(0): Dynamic Clock Scaling Disabled
(WW) RADEON(0): Acceleration disabled, not initializing the DRI
(II) RADEON(0): BIOS HotKeys Disabled
--> hangs again.

  
Comment 7 Stefan Dirsch 2006-02-21 21:37:06 UTC
Driver has been up-to-date. Latest changelog entry of the xorg-x11-driver-video package:

* Fr Feb 17 2006 - sndirsch@suse.de
- p_mga.diff:
  * fixes graphics corruption on Mystique revision 2 (Bug #151306)
- xf86-video-ati-disable-mc-clients.diff:
  * fixes video corruption on ATI ES1000 (Bug #151631)

Christoph, please also try "radeonold" driver.
Comment 8 Stefan Dirsch 2006-02-22 08:17:26 UTC
And also try these RPMS, so I can figure out which change (patch) is responsible for the regresssion.

/work/built/mbuild/shannon-sndirsch-10/i386/
/work/built/mbuild/shannon-sndirsch-11/i386/
/work/built/mbuild/shannon-sndirsch-12/i386/

Build should be ready in about 5 minutes.
Comment 9 Christoph Thiel 2006-02-22 11:53:35 UTC
/work/built/mbuild/shannon-sndirsch-10/i386/ - works
/work/built/mbuild/shannon-sndirsch-11/i386/ - doesn't work
/work/built/mbuild/shannon-sndirsch-12/i386/ - doesn't work
Comment 10 Christoph Thiel 2006-02-22 11:58:29 UTC
radeonold works as well.
Comment 11 Stefan Dirsch 2006-02-22 12:03:17 UTC
--- xorg-x11-driver-video-20060218/xorg-x11-driver-video.changes       
+++ xorg-x11-driver-video-20060221/xorg-x11-driver-video.changes       
@@ -1,4 +1,34 @@
+Fri Feb 17 19:05:22 CET 2006 - sndirsch@suse.de
+
+- p_mga.diff:
+  * fixes graphics corruption on Mystique revision 2 (Bug #151306)
+- xf86-video-ati-disable-mc-clients.diff:
+  * fixes video corruption on ATI ES1000 (Bug #151631)
+
+-------------------------------------------------------------------
+Fri Feb 17 14:52:41 CET 2006 - sndirsch@suse.de
+
+- rn50-pixelclock-limit.diff:
+  * Limit pixel clock to model memory bandwidth limits 
+    (Bug #139361, X.Org Bug #5766)
+
+-------------------------------------------------------------------
+Thu Feb 16 11:43:18 CET 2006 - sndirsch@suse.de
+
+- radeon-memmap-7.0-3.diff:
+  * obsoletes p_radeon-memmap.diff/p_radeon-memmap-fix.diff
+    (Bug #150146)
+
+-------------------------------------------------------------------
+Thu Feb 16 10:53:48 CET 2006 - sndirsch@suse.de
+
+- avoid_random_bogus_dma.diff:
+  * avoids random bugs bugs (Bug #140420, comments #45/46/47/48)
+  * obsoletes r300-sn2-piowrite_v7.diff
+  * this also happened on non-ia64 machines, so apply it everywhere
+
+-------------------------------------------------------------------

Comment 12 Stefan Dirsch 2006-02-22 12:21:11 UTC
Created attachment 69752 [details]
New RPM for testing.

Could you try this one. I disabled

- rn50-pixelclock-limit.diff
- xf86-video-ati-disable-mc-clients.diff
Comment 13 Christoph Thiel 2006-02-22 13:29:05 UTC
works.
Comment 14 Stefan Dirsch 2006-02-22 14:01:00 UTC
Wow! That's good to hear. I'm happy that it's not the change below:

-------------------------------------------------------------------
Thu Feb 16 11:43:18 CET 2006 - sndirsch@suse.de

- radeon-memmap-7.0-3.diff:
  * obsoletes p_radeon-memmap.diff/p_radeon-memmap-fix.diff
    ( Bug #150146)

We'll need one more iteration. :-) I'll provide a new RPM for testing ASAP.
Comment 15 Stefan Dirsch 2006-02-22 16:13:34 UTC
Created attachment 69824 [details]
New RPM for testing

- disabled xf86-video-ati-disable-mc-clients.diff
Comment 16 Stefan Dirsch 2006-02-22 16:20:57 UTC
Or let call it:

- enabled rn50-pixelclock-limit.diff again
Comment 17 Stefan Dirsch 2006-02-22 17:03:03 UTC
Ok. Just tested. No matter which patch you enable again - xf86-video-ati-disable-mc-clients.diff or rn50-pixelclock-limit.diff -
the result is a black screen. :-(
Comment 18 Stefan Dirsch 2006-02-22 17:21:07 UTC
I've disabled these patches for now and reopened the according bugreports again. Package submitted for STABLE.

-------------------------------------------------------------------
Wed Feb 22 18:11:49 CET 2006 - sndirsch@suse.de

- disabled 
  * rn50-pixelclock-limit.diff
  * xf86-video-ati-disable-mc-clients.diff
  since these patches have broken IBM T41p support again 
  completely (Bug #152473)
Comment 19 Stefan Dirsch 2006-02-22 17:26:29 UTC
Created attachment 69834 [details]
Final RPM for testing
Comment 20 Michel Danzer 2006-02-22 17:30:13 UTC
I don't see how rn50-pixelclock-limit.diff could have such an effect - it should only have *any* effect with an RN50 card.
Comment 21 Stefan Dirsch 2006-02-22 17:32:57 UTC
It was surprising for me as well ...
Comment 22 Stefan Dirsch 2006-02-22 18:26:46 UTC
> > I don't see how rn50-pixelclock-limit.diff could have such an effect - it
> > should only have *any* effect with an RN50 card.
> It was surprising for me as well ...
I'll doublecheck!
Comment 23 Stefan Dirsch 2006-02-23 14:12:05 UTC
Indeed. rn50-pixelclock-limit.diff has not been responsible for the hangup. I'll change this accordingly.
Comment 24 Christoph Thiel 2006-02-23 20:42:54 UTC
... the fix in STABLE didn't resolve the problem, as we were still able to crash the system while using sax2. However it didn't crash while using X (after sax2 -r -a -m 0=radeon) yet.
Comment 25 Stefan Dirsch 2006-02-23 21:30:06 UTC
I need to know what's exactly the difference between using

  sax2 -r -a -m 0=radeon  +  starting Xserver afterwards

and

  sax2 -r -m 0=radeon

Marcus?
Comment 26 Mark Gordon 2006-02-23 22:28:54 UTC
*** Bug 152177 has been marked as a duplicate of this bug. ***
Comment 27 Marcus Schaefer 2006-02-24 09:23:43 UTC
There is no difference, -a will write the config to /etc/X11/xorg.conf
without -a exactly this file is used to run the X-Server
Comment 30 Stefan Dirsch 2006-02-24 11:17:21 UTC
I can't reproduce this problem on Gerald's notebook. I've rebuilt the driver
currently submitted to /work/src/done/STABLE/xorg-x11-driver-video/. Both
mechanisms to configure X11 using

1) "sax2 -r -a" 
2) "sax2 -r" + "save configuration"

work fine. I also configured the radeon driver with "sax2 -r"
on top of a running fbdev Xserver without any problems. I need to test
this on Christoph's notebook on monday.
Comment 32 Stefan Dirsch 2006-02-24 11:21:43 UTC
Created attachment 70154 [details]
Gerald's xorg.conf
Comment 33 Stefan Dirsch 2006-02-24 11:22:17 UTC
Created attachment 70155 [details]
Gerald's Xorg.0.log
Comment 35 Stefan Dirsch 2006-02-24 11:33:09 UTC
The difference might be related to a preinstalled fglrx package on Christoph's machine. I'll check this.
Comment 36 Stefan Dirsch 2006-02-24 11:42:57 UTC
Indeed. I've got a freeze short after executing "sax2 -r -m 0=radeon". BTW, this is something really nobody wants to do. Either you want to use the radeon driver or the fglrx driver. In this case SaX2 mixes a profile for the fglrx driver with a radeon driver setup, which is never a good idea. I'm still investigating ...
Comment 37 Stefan Dirsch 2006-02-24 11:58:46 UTC
Ok. I can't reproduce this freeze after removin ",dri" from
/usr/share/sax/profile/FireGL. Therefore I think there's a problem with enabling DRI on this notebook. This is default already for the the initial
Xserver used by SaX2, when adding the FireGL profile to a radeon driver
setup. Again, nobody will do this in real life.
Comment 38 Christoph Thiel 2006-02-24 12:05:03 UTC
Well, on every update of the xorg there still will be the rewrite from fglrx -> radeon, which will trigger this bug IIUC.
Comment 39 Stefan Dirsch 2006-02-24 12:06:34 UTC
But one problem is remaining. During the system update when replacing "fglrx" with "radeon"  in xorg.conf the ' Load "dri" ' line should be removed as well.
Comment 40 Stefan Dirsch 2006-02-25 22:10:30 UTC
fixed in Beta > 5.