Bug 35935 - since, screen become garbled after some times (RV770)
Summary: since, screen become garbled after some times (RV770)
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Radeon (show other bugs)
Version: XOrg git
Hardware: x86-64 (AMD64) Linux (All)
: medium major
Assignee: Default DRI bug account
QA Contact:
Depends on:
Reported: 2011-04-03 11:57 UTC by Mjules
Modified: 2011-05-30 08:34 UTC (History)
0 users

See Also:
i915 platform:
i915 features:

garbled screen (95.07 KB, image/jpeg)
2011-04-03 11:57 UTC, Mjules
no flags Details
Xorg log (73.98 KB, text/plain)
2011-04-03 12:01 UTC, Mjules
no flags Details
dmesg (121.41 KB, text/plain)
2011-04-03 12:05 UTC, Mjules
no flags Details

Description Mjules 2011-04-03 11:57:04 UTC
Created attachment 45194 [details]
garbled screen


Since I'm using kernel, Xorg screen became garbled after some times (see screenshot). It occurs on but seems to be less frequent (3-4 hours for ; 8-10 for
I didn't get this bug with 2.6.38

TTY stay fine and after I close and start X, everything is fine again. No need to reboot.

I can't find anything precise which can trigger this bug, it simply occurs. Maybe an hint, it seems to be when I try to display a minimized window.

There is nothing obvious in the logs (but I'm not using debug option), kernel or X.

kernel  (kernel-linus- ; vanilla kernel packaged by my distro)
xorg 1.9.3
ati 6.14.1
mesa 7.9
libdrm 2.4.24
Comment 1 Mjules 2011-04-03 12:01:19 UTC
Created attachment 45195 [details]
Xorg log

Forgot to say I'm using a radeon 4870 (RV770), with KMS and power profile low.
Comment 2 Mjules 2011-04-03 12:05:34 UTC
Created attachment 45196 [details]
Comment 3 Alex Deucher 2011-04-03 16:59:38 UTC
(In reply to comment #0)
> Since I'm using kernel, Xorg screen became garbled after some times
> (see screenshot). It occurs on but seems to be less frequent (3-4
> hours for ; 8-10 for
> I didn't get this bug with 2.6.38

Did you update anything besides the kernel between 2.6.38 and (mesa of xf86-video-ati)?  If the same userspace components (mesa, xf86-video-ati) work on 2.6.38 and become garbled on, can you bisect between 2.6.38 and and see which commit caused the problem?  If you updated the userspace components as well, this is probably a duplicate of bug 33929.
Comment 4 Mjules 2011-04-04 03:23:59 UTC
thanks for your quick answer.

With the same userspace and configuration, 2.6.38 works fine.

I will try to bisect.

Comment 5 Mjules 2011-04-26 14:20:30 UTC
The result of the bisection is :
ba3ffdc68b4c80fe4cc42bdae6040eca1067ebb2 is the first bad commit
commit ba3ffdc68b4c80fe4cc42bdae6040eca1067ebb2
Author: Stanislav Kinsbursky <skinsbursky@parallels.com>
Date:   Thu Mar 17 18:54:23 2011 +0300

    RPC: killing RPC tasks races fixed
    commit 8e26de238fd794c8ea56a5c98bf67c40cfeb051d upstream.
    RPC task RPC_TASK_QUEUED bit is set must be checked before trying to wake up
    task rpc_killall_tasks() because task->tk_waitqueue can not be set (equal to
    Also, as Trond Myklebust mentioned, such approach (instead of checking
    tk_waitqueue to NULL) allows us to "optimise away the call to
    rpc_wake_up_queued_task() altogether for those
    tasks that aren't queued".
    Here is an example of dereferencing of tk_waitqueue equal to NULL:
    CPU 0               	CPU 1				CPU 2
    --------------------	---------------------	--------------------------
    						spin_lock(tk_waitqueue == NULL)
    			task->tk_waitqueue = q
    Signed-off-by: Stanislav Kinsbursky <skinsbursky@openvz.org>
    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

:040000 040000 91b88f0611c9ff1cf2691d9d65ec13c652a554ac e23b6d459a8bef93de6ea4821754e2f51e3ad32f M	net

which seems completely bogus to me (I don't use nfs).

BTW, the bug is still present with and seems more frequent with it. 

Another detail is it occurs only one time during a session.
Comment 6 Mjules 2011-05-30 08:34:19 UTC

I can't reproduce reliably (sometimes it occurs 2 times in 5 minutes, sometimes nothing during weeks) and I suspect a hardware bug.

I think it's better to close it, no need to pollute buglist.

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.