Created attachment 15134 [details] xorg log when i switch from X to console i sometimes stumble upon a flashing of the colored texts as seen on this video: http://rapidshare.com/files/99622737/mvi_4096.avi.html
this is an x1400 on a thinkpad t60
I share what I believe to be the same issue. I have a mobility x1400 on an inspiron e1705 notebook. For me, when i switch from X to console i randomly come across a distorted vga console with text flashing in all different directions. Here is a video of the issue: http://output.da4.org/vidbug1.mpg http://output.da4.org/vidbug2.mpg
Created attachment 15137 [details] This is my log.
I just got a t60p pushed in my hands by Christoph (now in cc), while it was displaying a flashing panel when restored. There is no difference in restored registers, so it is not something that can be identified directly through that. What i am seeing though, is that the MC hasn't idled properly in both the logs on here, and the log i grabbed from christophs laptop: (WW) RADEONHD(0): MC not idle So i guess that this a either good symptom of what is failing here or that it is a seperate issue. Egbert knows the MC subsystem, so i am ccing him here as well. I think he had some ideas as to what could be going wrong with the mc... Ok... something happened while this was being written. M54 seems to be related to the RV515, so it needs different handling. Assigning this bug to egbert until the MC issue is fixed.
Created attachment 15652 [details] [review] Patch to test. Just received information taht M54 may be a RV515.
Created attachment 15653 [details] [review] New patch, should apply better. The previous patch didn't contain all the pieces needed.
Created attachment 15654 [details] [review] another try...
Created attachment 15672 [details] [review] missing enum This needs to be applied on top of the last patch.
looks like the bug has gone away here after applying the two patches. if dmb doesn't have any different experience i suggest closing this bug
Well, VT switching is sure faster, but occasionally. I still get the issues shown from my videos posted earlier.
(In reply to comment #10) > Well, VT switching is sure faster, but occasionally. I still get the issues > shown from my videos posted earlier. OK. Is this a problem that was introduced at some point (a regression) or has this happened all the time?
Not 100% sure, but I think it existed since I started using the driver.
I am still seeing this on my Mobility Radeon X1300 on a ThinkPad T60, except in my X session instead of console VT. Symptom is otherwise identical to the video posted by the reporter. Happens very rarely, and seems to happen mostly on hibernate resume. Unsure about suspend-to-ram as I rarely use it. Switching back and forth between VTs will remove it after a try or two. No verbose 7 log, yet, unfortunately. Unsure if this is a regression or not as I've had my Xorg version updated in the last month.
This has existed all the time. Actually I saw this on the avivo driver too.
A PLL to CRTC mapping fix just went into the main tree. While it fixes another major issue we had with panel restore, it could also affect this. Please try the latest git driver.
Issue still persists, although appears to be more consistent now, at least. Will attempt to get some testing done it later.
Ok, another fix for the same thing (PLL ownership) went in now. I doubt that this does this resolve the issue now, but there's some chance that it does.
Please check fcb4fef67c993 in git: PLL: On M54 do not re-enable Spread Spectrum. I kind of cheated my way out of this one, but it will hopefully resolve a longstanding issue in a good enough manner with the limited amount of time i have had with hardware.
Haven't seen the error again yet. I've only tried reproducing it once so far, but so far so good.
It is working quite well on my T60. Thanks Luc!
Still occurring after coming out of hibernation, unfortunately.
I have the same problem (on a T60 with X1400 as well) with current git. So I wanted to try the patch but it has diverged from current code base that I couldn't even apply it by hand. Could someone please create an updated patch?
(In reply to comment #22) > Could someone please create an updated patch? The patch was committed to mainline quite some time ago. You will already be using it if you are running the latest from git.
OK, so that means the problem is still present and not fixed by that patch as far as I am concerned.
Does this issue occur with the preferred ati driver (xf86-vide-ati)? If so, please move this to the Driver/Radeon component. Development of radeonhd has pretty much halted and development focus is on the ati driver. Please see http://www.x.org/wiki/radeonhd If the issue does not exist in the ati driver (or if there is no response to this message), this bug will be closed as WONTFIX unless someone contributes a patch.
Closing due to lack of response. Please reopen and move to the Driver/Radeon component if this issue persists with xf86-video-ati
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.