Created attachment 45194 [details]
Since I'm using kernel 184.108.40.206, Xorg screen became garbled after some times (see screenshot). It occurs on 220.127.116.11 but seems to be less frequent (3-4 hours for 18.104.22.168 ; 8-10 for 22.214.171.124)
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 126.96.36.199 (kernel-linus-188.8.131.52-1mdv-1-1 ; vanilla kernel packaged by my distro)
Created attachment 45195 [details]
Forgot to say I'm using a radeon 4870 (RV770), with KMS and power profile low.
Created attachment 45196 [details]
(In reply to comment #0)
> Since I'm using kernel 184.108.40.206, Xorg screen became garbled after some times
> (see screenshot). It occurs on 220.127.116.11 but seems to be less frequent (3-4
> hours for 18.104.22.168 ; 8-10 for 22.214.171.124)
> I didn't get this bug with 2.6.38
Did you update anything besides the kernel between 2.6.38 and 126.96.36.199 (mesa of xf86-video-ati)? If the same userspace components (mesa, xf86-video-ati) work on 2.6.38 and become garbled on 188.8.131.52, can you bisect between 2.6.38 and 184.108.40.206 and see which commit caused the problem? If you updated the userspace components as well, this is probably a duplicate of bug 33929.
thanks for your quick answer.
With the same userspace and configuration, 2.6.38 works fine.
I will try to bisect.
The result of the bisection is :
ba3ffdc68b4c80fe4cc42bdae6040eca1067ebb2 is the first bad commit
Author: Stanislav Kinsbursky <email@example.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 <firstname.lastname@example.org>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Greg Kroah-Hartman <email@example.com>
:040000 040000 91b88f0611c9ff1cf2691d9d65ec13c652a554ac e23b6d459a8bef93de6ea4821754e2f51e3ad32f M net
which seems completely bogus to me (I don't use nfs).
BTW, the bug is still present with 220.127.116.11 and seems more frequent with it.
Another detail is it occurs only one time during a session.
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.