From: bugzilla-daemon@bugzilla.kernel.org
To: dri-devel@lists.freedesktop.org
Subject: [Bug 42678] [3.3-rc1] radeon stuck in kernel after lockup
Date: Fri, 24 Feb 2012 08:42:57 GMT [thread overview]
Message-ID: <201202240842.q1O8gv9f011156@bugzilla.kernel.org> (raw)
In-Reply-To: <bug-42678-2300@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=42678
--- Comment #8 from Torsten Kaiser <just.for.lkml@googlemail.com> 2012-02-24 08:42:55 ---
I think, you're not getting away with blaming userspace. ;-)
But this issue is rather complicated, because there is more then one bug /
change involved.
To summarize the issues:
* a change in xf86-video-ati-6.14.2 -> 6.14.3: That was the initial trigger for
the GPU lockup messages on my system. While this changes was partly buggy (This
has now been fixed, but I think that fix is not released yet) it was merely a
trigger for a kernel bug.
"Prove" that 6.14.3 is to blame for this:
6.14.2 + kernel 3.1 -> no GPU lockup messages
6.14.3 + kernel 3.1 -> first GPU lockup messages
also downgrading to 6.14.2 no longer showed this with later kernels
"Prove" that the real bug causing these lockups was a kernel bug:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=1b61925061660009f5b8047f93c5297e04541273
-> with this change 6.14.3 can no longer trigger GPU lockups
* the kernel bug causing GPU lockups -> wrong DESKTOP_HEIGHT setup.
That was probably always triggerable from userspace, but only the changes in
6.14.3 made this bug visible.
This is fixed with above commit 1b61925061660009f5b8047f93c5297e04541273
This bug is not this regression wrt. 3.3-rcX, as I was seeing this since 3.1
* first regression in 3.3-rc1: mutex deadlock that you have already fixed.
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=9fc04b503df9a34ec1a691225445c5b7dfd022e7
* a second, still open regression in 3.3-rc1 that had been masked by the first
regression: Even with the mutex fix applied to the kernel (i.e. 3.3-rc2) X was
still failing to recover from the GPU lockups. See comment #3
This is the issue, why I would still consider this bug (42678) to be still
open.
And I think this is a kernel regression and not a userspace issue because:
* 6.14.3 (with the GPU lockup trigger) and 3.2 (with the GPU lockup bug) will
cause the GPU lockup messages in dmesg, but I did not even notice this was
happening at all, because X was always able to recover without noticeable
effects.
* the same userspace (6.14.3 with the trigger) and 3.3-rc2 (still with the GPU
lockup bug, but without the mutex deadlock) will trigger the GPU lockup
messages in dmesg, but X will be stuck in the kernel and fail to turn my
monitors back on.
So I think the stuck X process is caused by the kernel changes between 3.2 and
3.3-rc2.
Since 3.3-rc3 X did not get stuck again, but this is because the underlying
kernel GPU lockup bug has been fixed, so there never was a need to recover and
any recovery bug could no longer be triggered.
Does this description of the issues involved make sense for you? Please ask, if
I was unclear or messed up my explanation.
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
next prev parent reply other threads:[~2012-02-24 8:42 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-28 15:16 [Bug 42678] New: [3.3-rc1]radeon 0000:07:00.0: GPU lockup CP stall for more than 10000msec bugzilla-daemon
2012-01-28 15:16 ` [Bug 42678] " bugzilla-daemon
2012-01-28 18:27 ` [Bug 42678] [3.3-rc1] radeon stuck in kernel after lockup bugzilla-daemon
2012-01-29 20:31 ` bugzilla-daemon
2012-02-04 8:39 ` bugzilla-daemon
2012-02-06 22:11 ` bugzilla-daemon
2012-02-07 6:59 ` bugzilla-daemon
2012-02-23 22:32 ` bugzilla-daemon
2012-02-24 2:53 ` bugzilla-daemon
2012-02-24 8:42 ` bugzilla-daemon [this message]
2012-03-29 22:07 ` bugzilla-daemon
2012-03-29 22:57 ` bugzilla-daemon
2012-04-03 19:38 ` bugzilla-daemon
2012-04-03 21:24 ` bugzilla-daemon
2012-04-04 12:43 ` bugzilla-daemon
2012-05-03 11:17 ` bugzilla-daemon
2012-05-04 8:10 ` bugzilla-daemon
2012-05-04 12:50 ` bugzilla-daemon
2012-05-04 13:04 ` bugzilla-daemon
2012-05-04 13:08 ` bugzilla-daemon
2012-05-04 14:21 ` bugzilla-daemon
2012-05-04 17:27 ` bugzilla-daemon
2013-05-01 17:50 ` bugzilla-daemon
2013-07-12 20:13 ` bugzilla-daemon
-- strict thread matches above, loose matches on Subject: below --
2012-02-23 22:51 3.3-rc4+: Reported regressions from 3.2 Rafael J. Wysocki
2012-02-23 22:55 ` [Bug #42678] [3.3-rc1] radeon stuck in kernel after lockup Rafael J. Wysocki
2012-02-24 9:14 ` Torsten Kaiser
2012-02-24 9:14 ` Torsten Kaiser
2012-03-04 20:29 3.3-rc6: Reported regressions from 3.2 Rafael J. Wysocki
2012-03-04 20:31 ` [Bug #42678] [3.3-rc1] radeon stuck in kernel after lockup Rafael J. Wysocki
2012-03-04 20:31 ` Rafael J. Wysocki
2012-03-11 21:23 3.3-rc7: Reported regressions from 3.2 Rafael J. Wysocki
2012-03-11 21:23 ` [Bug #42678] [3.3-rc1] radeon stuck in kernel after lockup Rafael J. Wysocki
2012-03-11 21:23 ` Rafael J. Wysocki
2012-03-12 19:15 ` Torsten Kaiser
2012-03-12 19:15 ` Torsten Kaiser
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201202240842.q1O8gv9f011156@bugzilla.kernel.org \
--to=bugzilla-daemon@bugzilla.kernel.org \
--cc=dri-devel@lists.freedesktop.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.