Bug 28940 - rv515 (Mobility x1400) Display corruption after some time
Summary: rv515 (Mobility x1400) Display corruption after some time
Status: NEW
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Radeon (show other bugs)
Version: unspecified
Hardware: x86 (IA32) Linux (All)
: medium normal
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-07-07 02:54 UTC by Nicos Gollan
Modified: 2012-04-12 00:20 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
lspci output (graphics only) (1.67 KB, text/plain)
2010-07-07 02:54 UTC, Nicos Gollan
no flags Details
Xorg.log from a "broken" system (32.38 KB, text/plain)
2010-07-07 02:55 UTC, Nicos Gollan
no flags Details
dmesg output from a "broken" system (60.31 KB, text/plain)
2010-07-07 02:55 UTC, Nicos Gollan
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Nicos Gollan 2010-07-07 02:54:25 UTC
Created attachment 36799 [details]
lspci output (graphics only)

After some uptime (upwards of an hour so far), I get different kinds of display corruption on a laptop with a Radeon x1400.

Currently, I'm looking at a somewhat grainy picture which looks like a badly dithered low-colour version of the screen content. There are noticeable vertical stripes, and the whole image is shimmering. The system is working fine otherwise.

In an earlier instance, I had a pulsating green gradient covering the bottom of the screen. In addition, screen response was slow, like the proper content was only updating evers second or so.

The effect does not show in screenshots.

This is on a Debian-built 2.6.34 686 kernel, running X.org 1.7.7 and the "radeon" driver 6.13.0, libdrm2 2.4.21 from Debian packages.

I'm attaching lspci output for the card, as well as dmesg and the Xorg.log from the currently "broken" running system.
Comment 1 Nicos Gollan 2010-07-07 02:55:01 UTC
Created attachment 36800 [details]
Xorg.log from a "broken" system
Comment 2 Nicos Gollan 2010-07-07 02:55:36 UTC
Created attachment 36801 [details]
dmesg output from a "broken" system
Comment 3 Nicos Gollan 2010-08-10 08:31:19 UTC
It's still there in the 2.6.35 kernel.

I noticed the following messages in dmesg when waking up from suspend-to-RAM:

[    1.463035] ATOM BIOS: M54CSP/M52CSP
[27369.832013] [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 1sec aborting
[27369.832016] [drm:atom_execute_table_locked] *ERROR* atombios stuck executing ECAC (len 86, WS 4, PS 0) @ 0xECDF
[53874.220012] [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 1sec aborting
[53874.220016] [drm:atom_execute_table_locked] *ERROR* atombios stuck executing ECAC (len 86, WS 4, PS 0) @ 0xECDF
Comment 4 Tomas Hencl 2010-08-25 10:26:34 UTC
I have same issue.
Mobility Radeon HD 3400 
kernel 2.6.34
mesa 7.8.2
xorg 1.8
Comment 5 Keivan 2012-04-11 14:33:36 UTC
it's a very long time I'm wrestling with the very same issue with my mobility x1400. Today I found a workaround to did problem. I'm in kernel 3.2 of LMDE. 

To solve this problem I forced my GPU into the maximum compatibility 3D acceleration mode with this simple xorg.conf

Section "Device"
	Identifier			"Radeon"
	Driver				"radeon"

	Option "EXAPixmaps"		"off"
	Option "AccelDFS"		"off"
	Option "MigrationHeuristic"	"greedy"
EndSection
Comment 6 Michel Dänzer 2012-04-12 00:20:12 UTC
(In reply to comment #5)
> it's a very long time I'm wrestling with the very same issue with my mobility
> x1400.

I don't think it's the very same issue:

 
>     Option "EXAPixmaps"        "off"

This is a very big hammer which basically prevents 2D acceleration from occuring in most cases, so it doesn't narrow down your problem very much unfortunately.

Moreover, the original report here mentioned 'The effect does not show in screenshots', which means this option can't really work around it. So your problem is probably not exactly the same and should be tracked elsewhere.


>     Option "AccelDFS"        "off"
>     Option "MigrationHeuristic"    "greedy"

These options don't have any effect with KMS.


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.