[Bug 42678] [3.3-rc1] radeon stuck in kernel after lockup
bugzilla-daemon at bugzilla.kernel.org
bugzilla-daemon at bugzilla.kernel.org
Wed Apr 4 05:43:53 PDT 2012
https://bugzilla.kernel.org/show_bug.cgi?id=42678
--- Comment #13 from Adrien Nader <camaradetux at gmail.Com> 2012-04-04 12:43:51 ---
My previous comment was missing some bits because of my lack of sleep.
My first issue was that, with a new laptop, which has two AMD cards (one
integrated, one discrete), the both cards are enabled and running even though
it's the integrated one which is actually used. That makes the laptop use a lot
more power than it should and it gets very hot.
I finally found out that I could save a lot of power by using vga_switcheroo to
switch to the dedicated card and then to the integrated one. That saves almost
45W of power consumption.
However, when I start X, even with only twm, I get MANY MANY MANY lockups as
soon as X is starting. At some point, X seems unable to recover. After
something like maybe 20 lockups...
Maybe that X could manage better but the current rate of lockups is one every
10 seconds, and that's with each lockup taking 10 seconds before a reset.
Maybe that this should go in another bug report however.
At Jérôme's request, I've exported my dmesg in order to check that X was stuck
inside the kernel. It contains my dmesg output with several executions of "echo
t > /proc/sysrq-trigger".
http://notk.org/~adrien/heat_issue/lockup/dmesg_sysrq_t_lockup
I've tried on 3.2.13; 3.3.0, 3.4-rc1(+) and I've had issues with all of these.
I'm running the latest individual tarballs of X (as of 5 days ago), along with
the latest libdrm, and a mesa git.
PS: I've started my laptop a bit after starting to write this. I've just
reached the 53 lockups, after abit more than 10 minutes after issuing "startx"
(and X is still recovering, oh, it seeems it has stopped recovering after 56
lockups)
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
More information about the dri-devel
mailing list