|
Bugzilla – Full Text Bug Listing |
| Summary: | radeon driver broken on T41p | ||
|---|---|---|---|
| Product: | [openSUSE] SUSE Linux 10.1 | Reporter: | Christoph Thiel <cthiel> |
| Component: | X.Org | Assignee: | 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
Created attachment 69565 [details]
Xorg.0.log
Created attachment 69566 [details]
xorg.conf
Hmm ... does removing ' Load "dri" ' in xorg.conf help? First problem. Since /root/xorg.conf exists this config file is used instead of /etc/X11/xorg.conf. :-( 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. :-(
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. 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. 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. /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 radeonold works as well. --- 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 + +------------------------------------------------------------------- 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
works. 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. Created attachment 69824 [details]
New RPM for testing
- disabled xf86-video-ati-disable-mc-clients.diff
Or let call it: - enabled rn50-pixelclock-limit.diff again 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. :-( 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) Created attachment 69834 [details]
Final RPM for testing
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 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!
Indeed. rn50-pixelclock-limit.diff has not been responsible for the hangup. I'll change this accordingly. ... 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. 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? *** Bug 152177 has been marked as a duplicate of this bug. *** 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 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. Created attachment 70154 [details]
Gerald's xorg.conf
Created attachment 70155 [details]
Gerald's Xorg.0.log
The difference might be related to a preinstalled fglrx package on Christoph's machine. I'll check this. 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 ... 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. Well, on every update of the xorg there still will be the rewrite from fglrx -> radeon, which will trigger this bug IIUC. 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. fixed in Beta > 5. |