Bugzilla – Bug 151631
Display Engine stops issuing MC requests on ATI ES1000 and Radeon 7000 - video corruption
Last modified: 2006-03-01 12:13:29 UTC
Note: This problem should occur on SLES 9.2 AND SLES 10.0. The immediate concern is SLES 9.2. Description of problem: Dell has discovered that under certain conditions the video output of an ES1000 can become corrupted, obscuring the desktop. This occurs at start of XWindow and is more prevalent at higher resolutions. Exiting X by typing ctl-alt-Bksp does not resolve the problem, the video remains corrupted. A reboot is required. ATI has determined that the problem is caused by a FIFO filling when the memory controller (MC) improperly forwards transactions intended for the video frame buffer. This occurs because of a difference between the frame buffer address as specified in the MC vs. the display controller. There is a window of opportunity between the modification of the MC_FB_Location register (MC) and the modification of the display engine registers. A patch for this problem is expected to be upstream Friday 2006-02-17. Further details will be provided then.
Patch will be welcome. :-)
BTW, SUSE LINUX / SLES mapping. SUSE LINUX 9.1 <--> SLES9 SUSE LINUX 10.1 <--> SLES10 So, there's no SLES 9.2. ;-)
Stefan, thanks for the mapping correction. Regrettably, I made an error on the very first line of this Bug. This problem is expected to affect SLES10 ONLY. The XFree86 driver apparently does not have the SetFBLocation function and doesn't change MC_FB_LOCATION. There is now a WIP fix available at https://bugs.freedesktop.org/show_bug.cgi?id=5916. This might also be applicable to SuSE bug: 151636.
Unfortunately hunk 3 and 4 in radeon_driver.c of this patch does not apply when Benjamin's "radeon-memmap-7.0-3.diff" has been applied before, because he solved this in a complete different way. :-( So currently I have no idea how to merge these patches. I'm not sure whether the other hunks alone in your patch still makes sense. Please let me know.
(In reply to comment #4) > Unfortunately hunk 3 and 4 in radeon_driver.c of this patch does not apply when > Benjamin's "radeon-memmap-7.0-3.diff" has been applied before, because he > solved this in a complete different way. :-( Yes, Ben's fix is mostly a superset of this patch. The purpose of this patch is to provide a minimal fix that can be applied even to 6.8 with minimal risk. > So currently I have no idea how to merge these patches. I'm not sure whether > the other hunks alone in your patch still makes sense. Please let me know. Some parts of the patch still make sense even on top of Ben's fix; I'll attach another patch to https://bugs.freedesktop.org/show_bug.cgi?id=5916 .
Thanks. I understand.
Latest patch of X.Org Bug #5916 (comment #2) applied for STABLE. Fixed for Beta > 4.
*** Bug 151636 has been marked as a duplicate of this bug. ***
This patch has broken IBM T41p support again completely. Therefore I disabled it for now. See Bug #152473 for details.
It would be very interesting to know exactly where it's hanging with xf86-video-ati-disable-mc-clients.diff.
Currently I don't have access to this machine. Tomorrow again.
Note that for all I know, Ben's memmap fixes have fixed this bug in practice. The offending patch was supposed to eliminate remaining theoretical problems that haven't been observed in any tests I've heard of.
Ok. I think in this case I can keep this patch disabled and won't investigate this issue any furter. Closing as fixed.
Stefan, Michel, How confident are you that this problem is now fixed. Reading the above it looks like the radeon-memmap-7.0-3.diff patch was developed independantly and it might fix this problem but is there a clear link between problem and solution?
There is a clear link. The regressions caused by disabling bus mastering in RADEONSetFBLocation was one of the things that prompted Ben to do a complete cleanup of the driver's handling of the framebuffer and GART mappings. As I mentioned in comment #5, that cleanup is mostly a superset of the patches from https://bugs.freedesktop.org/show_bug.cgi?id=5916 . The only difference is that the latter attempt to address some remaining theoretical opportunities for the accidental bus master cycles. However, while I haven't heard of these theoretical opportunities actually causing problems in practice in what seems quite extensive testing at ATI and Dell, the attempt to address them resulted in bug 152473 after a short time. So, it seems safer to go without the additional precautions for now, at least until the cause of the regression has been determined and fixed.
(In reply to comment #11) > Currently I don't have access to this machine. Tomorrow again. We would still like to know what the problem is with this patch, have you had a chance to track down where it hangs?
First I need to find a machine again for testing, on which this problem occurs when this patch is enabled. On a Radeon X850 XT it doesn't.
Yes, that's correct.
What happened to comments #18-20?
> What happened to comments #18-20? Private comments. :-)