https://bugs.freedesktop.org/show_bug.cgi?id=36598
Summary: [RS880] Slow resume from suspend generates kernel oops Product: DRI Version: XOrg CVS Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/Radeon AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: steve@stevemurphy.org
Created an attachment (id=46075) --> (https://bugs.freedesktop.org/attachment.cgi?id=46075) dmesg output for boot and suspend, showing the issue around 78.3
I'm forwarding this bug from ubuntu - https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/764788
Problem] Resume from suspend triggers a kernel oops due to the radeon kms module taking more than 10 seconds to resume
[Discussion] When resuming from the suspend state, a popup box is displayed indicating an error has occured and "Your system might become unstable now and might need to be restarted.". In the dmesg output, the following lines are present before the kernel oops, showing that the radeon driver took 11408.919 msecs to resume and the kernel oops is due to resume taking longer than 10 seconds total (11430 msecs).
Interesting lines in the dmesg output when the error occurs are below (with kernel.drm=0x04 set, adding a bit of verbosity when the radeon driver is restoring):
[ 69.792851] PM: resume of drv:scsi_disk dev:2:0:0:0 complete after 2644.379 msecs [ 70.122093] [drm:output_poll_execute], [CONNECTOR:15:VGA-1] status updated from 2 to 2 [ 70.124058] [drm:radeon_atombios_connected_scratch_regs], DFP1 disconnected [ 70.124062] [drm:output_poll_execute], [CONNECTOR:17:HDMI-A-1] status updated from 2 to 2 [ 71.960104] [drm:radeon_atom_encoder_dpms], encoder dpms 21 to mode 3, devices 00000001, active_devices 00000000 [ 71.960113] [drm:radeon_atom_encoder_dpms], encoder dpms 30 to mode 3, devices 00000008, active_devices 00000000 [ 71.960136] [drm:radeon_compute_pll_avivo], 7187, pll dividers - fb: 130.5 ref: 2, post 13 [ 71.980174] [drm:drm_crtc_helper_set_mode], [ENCODER:12:LVDS-12] set [MODE:30:1366x768] [ 76.950136] [drm:avivo_crtc_load_lut], 0 [ 76.950200] [drm:radeon_atom_encoder_dpms], encoder dpms 31 to mode 0, devices 00000002, active_devices 00000002 [ 76.960133] [drm:radeon_atom_encoder_dpms], encoder dpms 31 to mode 3, devices 00000002, active_devices 00000002 [ 78.303704] [drm:radeon_atom_encoder_dpms], encoder dpms 21 to mode 3, devices 00000001, active_devices 00000000 [ 78.303713] [drm:radeon_atom_encoder_dpms], encoder dpms 30 to mode 3, devices 00000008, active_devices 00000000 [ 78.303734] [drm:avivo_crtc_load_lut], 0 [ 78.303790] [drm:radeon_atom_encoder_dpms], encoder dpms 31 to mode 0, devices 00000002, active_devices 00000002 [ 78.310132] PM: resume of drv:radeon dev:0000:01:05.0 complete after 11408.919 msecs [ 78.310148] PM: resume of drv:drm dev:controlD64 complete after 8513.702 msecs [ 78.310173] PM: resume of devices complete after 11409.422 msecs [ 78.330262] PM: resume devices took 11.430 seconds [ 78.330265] ------------[ cut here ]------------ [ 78.330272] WARNING: at /build/buildd/linux-2.6.38/kernel/power/suspend_test.c:53 suspend_test_finish+0x86/0x90() [ 78.330274] Hardware name: 1215T [ 78.330277] Component: resume devices, time: 11430
Upon investigating further, it looks like portions of the the following workarounds were discovered that allow resume from suspend to work as expected, by avoid the radeon driver:
[Workarounds] 1. Add "nomodeset" to the linux command line in grub 2. Use the proprietary FGLRX driver.
[System Environment] ASUS 1215T running a fresh install of 11.04 beta or 11.04 beta2.