Created attachment 25216 [details] Xorg.0.log gotten via ssh after trying to shutdown X hd3470 mobility on a toshiba a300 laptop, gentoo linux. X works just fine, the problem is when I try to switch back to console / shutdown the laptop. When I try to switch back to console (ctrl-alt-[fnXY|backspace]) the mouse pointer disappears and the computer freezes badly. I can log in via ssh but cannot manage to kill X / get back a working screen. Not even sysrq works. kernel log is spammed with [drm] wait idle failed status : 0xFFFFFFFF 0xFFFFFFFF lines. When shutting down, the X server shows the startup black/white grid, the mouse pointer disappears, and the pc locks. Sometimes it manages to shutdown 'cleanly' (I never get to see the console though, X grid until the monitor shuts down). Removing the ForceLowPowerMode option from xorg.conf completely fixes this. Running latest xf86-video-ati from git (-9999 gentoo ebuild from x11 overlay), last synched this morning (04-28), never worked correctly for me. Tested it with kernel 2.6.29.1 and 2.6.30-rc3-git2, xorg-server-1.6.0 and -1.6.1, mesa-9999 branch radeon-rewrite (really don't care about 3d though), libdrm-9999
Ok, maybe the '[drm] wait idle failed status' lines are not directly related to the problem: I tried running the X server as root with no wm and I got the very same behaviour, but I managed to kill -9 the X process (which, I forgot to mention, takes 100% cpu when it hangs) via ssh, and didn't get these messages. Even after killing the process though, the laptop screen would remain stuck on the X screen, with the mouse pointer disappeared. No further output on Xorg.0.log
Little update: upgraded to latest 1.6.2-rc X server and latest git xf86-video-ati package, linux 2.6.30-rc4. Still getting the same behaviour, now noticed a bad message in dmesg after trying to shut down X via ctl-alt-backspace: [ 68.474307] [drm] wait idle failed status : 0xFFFFFFFF 0xFFFFFFFF [ 68.596881] [drm] wait idle failed status : 0xFFFFFFFF 0xFFFFFFFF [ 68.720096] [drm] wait idle failed status : 0xFFFFFFFF 0xFFFFFFFF [ 68.720105] BUG: unable to handle kernel NULL pointer dereference at (null) [ 68.720109] IP: [<ffffffffa00480c2>] radeon_read_ring_rptr+0x26/0x29 [radeon] [ 68.720119] PGD 0 [ 68.720121] Oops: 0000 [#1] PREEMPT SMP [ 68.720124] last sysfs file: /sys/devices/LNXSYSTM:00/device:00/ACPI0003:00/power_supply/ACAD/type [ 68.720127] CPU 1 [ 68.720128] Modules linked in: radeon drm ath5k [ 68.720133] Pid: 2328, comm: X Not tainted 2.6.30-rc4 #1 Satellite A300 [ 68.720135] RIP: 0010:[<ffffffffa00480c2>] [<ffffffffa00480c2>] radeon_read_ring_rptr+0x26/0x29 [radeon] [ 68.720142] RSP: 0018:ffff8800be307c80 EFLAGS: 00013246 [ 68.720144] RAX: ffff8800be054980 RBX: ffff8800bf83d000 RCX: ffffc20010252000 [ 68.720147] RDX: 000000000000002c RSI: 0000000000000000 RDI: ffff8800bf83d000 [ 68.720149] RBP: ffff8800bf83e000 R08: ffff8800bf83e000 R09: 0000000000000001 [ 68.720151] R10: ffff8800be0cdd80 R11: 000000007ffffff2 R12: ffff8800bf752900 [ 68.720153] R13: ffff8800bf9a9b00 R14: 0000000000000008 R15: 0000000000000009 [ 68.720156] FS: 00007fd047b1c6f0(0000) GS:ffff880001035000(0000) knlGS:0000000000000000 [ 68.720158] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [ 68.720160] CR2: 0000000000000000 CR3: 0000000000201000 CR4: 00000000000006e0 [ 68.720162] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 68.720165] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [ 68.720167] Process X (pid: 2328, threadinfo ffff8800be306000, task ffff8800bedd2220) [ 68.720169] Stack: [ 68.720170] ffffffffa0048834 ffff8800bf83d000 ffffffffa00561ba ffff8800bf83d000 [ 68.720174] ffffffffa004b7e6 ffff8800bd8ea4c0 ffff8800bf83e000 ffff8800bd8ea4c0 [ 68.720177] ffffffffa0021c60 ffff8800bd8ea4c0 ffff8800bdbf0e40 ffff8800bd8ea4c0 [ 68.720181] Call Trace: [ 68.720183] [<ffffffffa0048834>] ? radeon_commit_ring+0x44/0x9a [radeon] [ 68.720189] [<ffffffffa00561ba>] ? r600_do_cp_idle+0xc8/0xd1 [radeon] [ 68.720196] [<ffffffffa004b7e6>] ? radeon_do_release+0x5c/0x1a2 [radeon] [ 68.720209] [<ffffffffa0021c60>] ? drm_lastclose+0x40/0x294 [drm] [ 68.720222] [<ffffffff80286e61>] ? __fput+0xcd/0x16a [ 68.720227] [<ffffffff802845d1>] ? filp_close+0x5f/0x6a [ 68.720230] [<ffffffff80228360>] ? need_resched+0x1a/0x23 [ 68.720234] [<ffffffff8023395c>] ? put_files_struct+0x60/0xbd [ 68.720237] [<ffffffff80234fc2>] ? do_exit+0x197/0x5fd [ 68.720240] [<ffffffff8023548f>] ? do_group_exit+0x67/0x93 [ 68.720243] [<ffffffff8023d7f9>] ? get_signal_to_deliver+0x375/0x393 [ 68.720247] [<ffffffff80262b06>] ? get_pageblock_migratetype+0x17/0x18 [ 68.720250] [<ffffffff8020a484>] ? do_notify_resume+0x83/0x6d8 [ 68.720254] [<ffffffff8052e003>] ? _spin_unlock_irq+0x2b/0x39 [ 68.720254] [<ffffffff8052c61b>] ? thread_return+0x3e/0x99 [ 68.720254] [<ffffffff80246dbd>] ? hrtimer_nanosleep+0x9c/0x108 [ 68.720254] [<ffffffff8020b8de>] ? retint_signal+0x3d/0x7f [ 68.720254] Code: 31 c0 c3 90 90 f6 87 d6 03 00 00 08 48 8b 87 10 01 00 00 74 09 89 f6 48 03 70 18 8b 06 c3 c1 ee 02 89 f6 48 c1 e6 02 48 03 70 18 <8b> 06 c3 83 7f 74 00 74 07 31 f6 e9 ca ff ff ff 66 83 bf d4 03 [ 68.720254] RIP [<ffffffffa00480c2>] radeon_read_ring_rptr+0x26/0x29 [radeon] [ 68.720254] RSP <ffff8800be307c80> [ 68.720254] CR2: 0000000000000000 [ 68.720316] ---[ end trace 342357252ce6c353 ]--- [ 68.720318] Fixing recursive fault but reboot is needed!
Okay, looking around a bit I found a quick workaround: from the irc log http://www.radeonhd.org/?page=archive_display&c=radeon&m=4&y=2009&d=2009-4-15 I have read: tormod: agd5f: ok it helped. now X starts, but the laptop freezes solid when I switch VT agd5f: tormod: comment out the RADEONSetClockGating() calls in RADEONPMEnterVT() and RADEONPMLeaveVT() and RADEONPMFini() agd5f: in radeon_pm.c tormod: thanks agd5f: tormod: I'll commit a fix I found that those three lines actually were not commented in current git code, so I commented them and now I can switch back to console / shutdown the system properly. Whether removing those lines is dangerous (and that's why agd5f hasn't removed them yet) or it is the right way to do it, I really have no idea.
Created attachment 26037 [details] [review] my fix attempt at radeon_pm.c
(In reply to comment #4) > Created an attachment (id=26037) [details] > my fix attempt at radeon_pm.c > Removing the "ClockGating" option from your config will also prevent that code from being called.
> > Removing the "ClockGating" option from your config will also prevent that code > from being called. > but wouldn't that mean that (in both cases?) power management is not fully running on my board? or does ForceLowPowerMode somewhat override/surpasses ClockGating's function anyway?
(In reply to comment #6) > > > > Removing the "ClockGating" option from your config will also prevent that code > > from being called. > > > > but wouldn't that mean that (in both cases?) power management is not fully > running on my board? or does ForceLowPowerMode somewhat override/surpasses > ClockGating's function anyway? > There are 3 options which can be used individually or combined: 1. ClockGating - Enables chips specific power saving features like clock gating that are handled by the hardware directly. This doesn't really do much on r6xx/r7xx boards yet. 2. DynamicPM - Automatically reduces the engine clock and pcie lanes when dpms has powered down the displays 3. ForceLowPowerMode - Runs the chip at a constant reduced engine clock and pcie lanes.
> (In reply to comment #5) > Removing the "ClockGating" option from your config will also prevent that code > from being called. > Well it might be me but actually rebuilding the driver with those lines uncommented and adding in xorg.conf an Option "ClockGating" "False" line (I had no clock gating options in xorg.conf before) doesn't fix the problem, ie. my laptop still hangs.
(In reply to comment #8) > Well it might be me but actually rebuilding the driver with those lines > uncommented and adding in xorg.conf an > > Option "ClockGating" "False" > > line (I had no clock gating options in xorg.conf before) doesn't fix the > problem, ie. my laptop still hangs. > Then the lockup appears to be with the the clock or pcie code for you chip. What your patch did is to make all of the power management code conditional on the ClockGating option. Effectively disabling power management all together. if (info->pm.clock_gating_enabled) - RADEONSetClockGating(pScrn, FALSE); + // RADEONSetClockGating(pScrn, FALSE); if (info->pm.force_low_power_enabled || info->pm.dynamic_mode_enabled) RADEONSetStaticPowerMode(pScrn, POWER_DEFAULT); the top "if" statement now applies to both the following "if" statement. the logic is now: if (info->pm.clock_gating_enabled) if (info->pm.force_low_power_enabled || info->pm.dynamic_mode_enabled) RADEONSetStaticPowerMode(pScrn, POWER_DEFAULT);
(In reply to comment #9) > Then the lockup appears to be with the the clock or pcie code for you chip. > > What your patch did is to make all of the power management code conditional on > the ClockGating option. Effectively disabling power management all together. So (if I understand correctly) to put it simply power management just doesn't work on my board, right? If you have any suggestion / thing you'd like me to try / thing you want to know please tell me, since power management was really the only thing holding me to the proprietary drivers...
Mass closure: This bug has been untouched for more than six years, and is not obviously still valid. Please reopen this bug or file a new report if you continue to experience issues with current releases.
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.