I'm seeing several issues related to the radeon driver on a MacBook Pro 8,2 with the following graphics card:
ATI Technologies Inc Whistler [AMD Radeon HD 6600M Series] [1002:6741]
All problems were observed when using kernel version 3.2.1. None are seen when using fglrx.
1. Excessive power draw. When using the radeon driver ACPI reports a power draw of about 30W on an idle desktop. Using fglrx brings this number down to 15W.
2. Occasional long delays when suspending. When this happens I see messages like following in dmesg:
[drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 5secs aborting [drm:atom_execute_table_locked] *ERROR* atombios stuck executing D44E (len 62, WS 0, PS 0) @ 0xD46A
Sometimes one of suspend or resume hangs completely, but I can't tell which and am not sure whether or not it's related. I'm also testing a Mac Mini with the exact same card which does not seem to suffer from this issue.
I ran a bisections that identified f8d0edd (drm/radeon/kms: improve DP detect logic) as introducing problems with suspend, and reverting this patch on top of 3.2.1 does seem to eliminate both issues.
3. When the LVDS panel is powered off and back on, the display flickers, as if the backlight is cycling rapidly between low and high brightness. If the panel is left on this effect gradually lessens and is eventually no longer noticable. This is not seen with fglrx.
Thanks, Seth
On Thu, Jan 19, 2012 at 12:18 PM, Seth Forshee seth.forshee@canonical.com wrote:
I'm seeing several issues related to the radeon driver on a MacBook Pro 8,2 with the following graphics card:
ATI Technologies Inc Whistler [AMD Radeon HD 6600M Series] [1002:6741]
All problems were observed when using kernel version 3.2.1. None are seen when using fglrx.
1. Excessive power draw. When using the radeon driver ACPI reports a power draw of about 30W on an idle desktop. Using fglrx brings this number down to 15W.
The power saving features of the open source driver are not yet as good as the closed source driver. Please see the power management section of this page (http://wiki.x.org/wiki/RadeonFeature) for more info on the options currently available.
2. Occasional long delays when suspending. When this happens I see messages like following in dmesg:
[drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 5secs aborting [drm:atom_execute_table_locked] *ERROR* atombios stuck executing D44E (len 62, WS 0, PS 0) @ 0xD46A
Sometimes one of suspend or resume hangs completely, but I can't tell which and am not sure whether or not it's related. I'm also testing a Mac Mini with the exact same card which does not seem to suffer from this issue.
I ran a bisections that identified f8d0edd (drm/radeon/kms: improve DP detect logic) as introducing problems with suspend, and reverting this patch on top of 3.2.1 does seem to eliminate both issues.
That patch doesn't really affect the modesetting paths directly; it looks like a red herring to me.
3. When the LVDS panel is powered off and back on, the display flickers, as if the backlight is cycling rapidly between low and high brightness. If the panel is left on this effect gradually lessens and is eventually no longer noticable. This is not seen with fglrx.
For the sake of tracking this properly, it would probably be best to file a bug: https://bugs.freedesktop.org Product: DRI Component: DRM/Radeon What connectors does your card actually have on it? Please attach a copy of your dmesg output and vbios: (as root) (use lspci to get the bus id) cd /sys/bus/pci/devices/<pci bus id> echo 1 > rom cat rom > /tmp/vbios.rom echo 0 > rom
Also, keep in mind that this is a mac so it's likely there may be wonky mac specific problems.
Alex
Thanks, Seth _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
On Thu, Jan 19, 2012 at 02:48:52PM -0500, Alex Deucher wrote:
On Thu, Jan 19, 2012 at 12:18 PM, Seth Forshee seth.forshee@canonical.com wrote:
I'm seeing several issues related to the radeon driver on a MacBook Pro 8,2 with the following graphics card:
ATI Technologies Inc Whistler [AMD Radeon HD 6600M Series] [1002:6741]
All problems were observed when using kernel version 3.2.1. None are seen when using fglrx.
1. Excessive power draw. When using the radeon driver ACPI reports a power draw of about 30W on an idle desktop. Using fglrx brings this number down to 15W.
The power saving features of the open source driver are not yet as good as the closed source driver. Please see the power management section of this page (http://wiki.x.org/wiki/RadeonFeature) for more info on the options currently available.
The dynpm option makes a small difference, saving about 2W. I did notice an ocassional flash on the screen with this option, and the same flash each time I changed the power options.
The only thing that improves things significatnly is the "low" profile method, which gets it down to about 18.5W.
2. Occasional long delays when suspending. When this happens I see messages like following in dmesg:
[drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 5secs aborting [drm:atom_execute_table_locked] *ERROR* atombios stuck executing D44E (len 62, WS 0, PS 0) @ 0xD46A
Sometimes one of suspend or resume hangs completely, but I can't tell which and am not sure whether or not it's related. I'm also testing a Mac Mini with the exact same card which does not seem to suffer from this issue.
I ran a bisections that identified f8d0edd (drm/radeon/kms: improve DP detect logic) as introducing problems with suspend, and reverting this patch on top of 3.2.1 does seem to eliminate both issues.
That patch doesn't really affect the modesetting paths directly; it looks like a red herring to me.
Perhaps. I just started a run of 200 s3 cycles with the patch reverted to see if I can reproduce the issues. I can usually trigger the problem with 15 or fewer s3 cycles.
3. When the LVDS panel is powered off and back on, the display flickers, as if the backlight is cycling rapidly between low and high brightness. If the panel is left on this effect gradually lessens and is eventually no longer noticable. This is not seen with fglrx.
For the sake of tracking this properly, it would probably be best to file a bug: https://bugs.freedesktop.org Product: DRI Component: DRM/Radeon What connectors does your card actually have on it? Please attach a copy of your dmesg output and vbios: (as root) (use lspci to get the bus id) cd /sys/bus/pci/devices/<pci bus id> echo 1 > rom cat rom > /tmp/vbios.rom echo 0 > rom
Also, keep in mind that this is a mac so it's likely there may be wonky mac specific problems.
I filed bug #44955 for the flickering issue.
Thanks, Seth
On Thu, Jan 19, 2012 at 02:53:17PM -0600, Seth Forshee wrote:
2. Occasional long delays when suspending. When this happens I see messages like following in dmesg:
[drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 5secs aborting [drm:atom_execute_table_locked] *ERROR* atombios stuck executing D44E (len 62, WS 0, PS 0) @ 0xD46A
Sometimes one of suspend or resume hangs completely, but I can't tell which and am not sure whether or not it's related. I'm also testing a Mac Mini with the exact same card which does not seem to suffer from this issue.
I ran a bisections that identified f8d0edd (drm/radeon/kms: improve DP detect logic) as introducing problems with suspend, and reverting this patch on top of 3.2.1 does seem to eliminate both issues.
That patch doesn't really affect the modesetting paths directly; it looks like a red herring to me.
Perhaps. I just started a run of 200 s3 cycles with the patch reverted to see if I can reproduce the issues. I can usually trigger the problem with 15 or fewer s3 cycles.
The machine completed 200 s3 cycles with the patch reverted without long delays, hangs, or any atombios error messages. Without reverting it doesn't get through many at all before experiencing the errors and long delays or hangs.
I added a printout of the connector status resulting from the logic that was changed by f8d0edd. With the logic prior to this commit it consistently returns the status as disconnected, which is correct as I have nothing connected. But with the improved logic the status is sometimes reported as connected, and these coincide with the atombios errors.
Seth
On Fri, Jan 20, 2012 at 10:53 AM, Seth Forshee seth.forshee@canonical.com wrote:
On Thu, Jan 19, 2012 at 02:53:17PM -0600, Seth Forshee wrote:
2. Occasional long delays when suspending. When this happens I see messages like following in dmesg:
[drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 5secs aborting [drm:atom_execute_table_locked] *ERROR* atombios stuck executing D44E (len 62, WS 0, PS 0) @ 0xD46A
Sometimes one of suspend or resume hangs completely, but I can't tell which and am not sure whether or not it's related. I'm also testing a Mac Mini with the exact same card which does not seem to suffer from this issue.
I ran a bisections that identified f8d0edd (drm/radeon/kms: improve DP detect logic) as introducing problems with suspend, and reverting this patch on top of 3.2.1 does seem to eliminate both issues.
That patch doesn't really affect the modesetting paths directly; it looks like a red herring to me.
Perhaps. I just started a run of 200 s3 cycles with the patch reverted to see if I can reproduce the issues. I can usually trigger the problem with 15 or fewer s3 cycles.
The machine completed 200 s3 cycles with the patch reverted without long delays, hangs, or any atombios error messages. Without reverting it doesn't get through many at all before experiencing the errors and long delays or hangs.
I added a printout of the connector status resulting from the logic that was changed by f8d0edd. With the logic prior to this commit it consistently returns the status as disconnected, which is correct as I have nothing connected. But with the improved logic the status is sometimes reported as connected, and these coincide with the atombios errors.
Do any of the disconnected displayport connectors get misdetected as connected during normal operation or does it only happen during suspend/resume?
Alex
On Fri, Jan 20, 2012 at 02:38:37PM -0500, Alex Deucher wrote:
On Fri, Jan 20, 2012 at 10:53 AM, Seth Forshee seth.forshee@canonical.com wrote:
On Thu, Jan 19, 2012 at 02:53:17PM -0600, Seth Forshee wrote:
2. Occasional long delays when suspending. When this happens I see messages like following in dmesg:
[drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 5secs aborting [drm:atom_execute_table_locked] *ERROR* atombios stuck executing D44E (len 62, WS 0, PS 0) @ 0xD46A
Sometimes one of suspend or resume hangs completely, but I can't tell which and am not sure whether or not it's related. I'm also testing a Mac Mini with the exact same card which does not seem to suffer from this issue.
I ran a bisections that identified f8d0edd (drm/radeon/kms: improve DP detect logic) as introducing problems with suspend, and reverting this patch on top of 3.2.1 does seem to eliminate both issues.
That patch doesn't really affect the modesetting paths directly; it looks like a red herring to me.
Perhaps. I just started a run of 200 s3 cycles with the patch reverted to see if I can reproduce the issues. I can usually trigger the problem with 15 or fewer s3 cycles.
The machine completed 200 s3 cycles with the patch reverted without long delays, hangs, or any atombios error messages. Without reverting it doesn't get through many at all before experiencing the errors and long delays or hangs.
I added a printout of the connector status resulting from the logic that was changed by f8d0edd. With the logic prior to this commit it consistently returns the status as disconnected, which is correct as I have nothing connected. But with the improved logic the status is sometimes reported as connected, and these coincide with the atombios errors.
Do any of the disconnected displayport connectors get misdetected as connected during normal operation or does it only happen during suspend/resume?
So far I've only seen them during suspend/resume.
On Fri, Jan 20, 2012 at 4:12 PM, Seth Forshee seth.forshee@canonical.com wrote:
On Fri, Jan 20, 2012 at 02:38:37PM -0500, Alex Deucher wrote:
On Fri, Jan 20, 2012 at 10:53 AM, Seth Forshee seth.forshee@canonical.com wrote:
On Thu, Jan 19, 2012 at 02:53:17PM -0600, Seth Forshee wrote:
2. Occasional long delays when suspending. When this happens I see messages like following in dmesg:
[drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 5secs aborting [drm:atom_execute_table_locked] *ERROR* atombios stuck executing D44E (len 62, WS 0, PS 0) @ 0xD46A
Sometimes one of suspend or resume hangs completely, but I can't tell which and am not sure whether or not it's related. I'm also testing a Mac Mini with the exact same card which does not seem to suffer from this issue.
I ran a bisections that identified f8d0edd (drm/radeon/kms: improve DP detect logic) as introducing problems with suspend, and reverting this patch on top of 3.2.1 does seem to eliminate both issues.
That patch doesn't really affect the modesetting paths directly; it looks like a red herring to me.
Perhaps. I just started a run of 200 s3 cycles with the patch reverted to see if I can reproduce the issues. I can usually trigger the problem with 15 or fewer s3 cycles.
The machine completed 200 s3 cycles with the patch reverted without long delays, hangs, or any atombios error messages. Without reverting it doesn't get through many at all before experiencing the errors and long delays or hangs.
I added a printout of the connector status resulting from the logic that was changed by f8d0edd. With the logic prior to this commit it consistently returns the status as disconnected, which is correct as I have nothing connected. But with the improved logic the status is sometimes reported as connected, and these coincide with the atombios errors.
Do any of the disconnected displayport connectors get misdetected as connected during normal operation or does it only happen during suspend/resume?
So far I've only seen them during suspend/resume.
Can you track down who is calling the connector->detect() callbacks during suspend and resume?
Alex
On Fri, Jan 20, 2012 at 04:39:31PM -0500, Alex Deucher wrote:
On Fri, Jan 20, 2012 at 4:12 PM, Seth Forshee seth.forshee@canonical.com wrote:
On Fri, Jan 20, 2012 at 02:38:37PM -0500, Alex Deucher wrote:
On Fri, Jan 20, 2012 at 10:53 AM, Seth Forshee seth.forshee@canonical.com wrote:
On Thu, Jan 19, 2012 at 02:53:17PM -0600, Seth Forshee wrote:
> 2. Occasional long delays when suspending. When this happens I see > messages like following in dmesg: > > [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 5secs aborting > [drm:atom_execute_table_locked] *ERROR* atombios stuck executing D44E (len 62, WS 0, PS 0) @ 0xD46A > > Sometimes one of suspend or resume hangs completely, but I can't > tell which and am not sure whether or not it's related. I'm also > testing a Mac Mini with the exact same card which does not seem to > suffer from this issue. > > I ran a bisections that identified f8d0edd (drm/radeon/kms: improve > DP detect logic) as introducing problems with suspend, and reverting > this patch on top of 3.2.1 does seem to eliminate both issues. >
That patch doesn't really affect the modesetting paths directly; it looks like a red herring to me.
Perhaps. I just started a run of 200 s3 cycles with the patch reverted to see if I can reproduce the issues. I can usually trigger the problem with 15 or fewer s3 cycles.
The machine completed 200 s3 cycles with the patch reverted without long delays, hangs, or any atombios error messages. Without reverting it doesn't get through many at all before experiencing the errors and long delays or hangs.
I added a printout of the connector status resulting from the logic that was changed by f8d0edd. With the logic prior to this commit it consistently returns the status as disconnected, which is correct as I have nothing connected. But with the improved logic the status is sometimes reported as connected, and these coincide with the atombios errors.
Do any of the disconnected displayport connectors get misdetected as connected during normal operation or does it only happen during suspend/resume?
So far I've only seen them during suspend/resume.
Can you track down who is calling the connector->detect() callbacks during suspend and resume?
I got two different stack traces, see below.
And to slightly amend my statement above, I'm only seeing the wrong status returned on the suspend side of things. The status during resume always seems to be correct.
Pid: 49, comm: kworker/0:2 Tainted: G C O 3.2.0-10-generic #17-Ubuntu Call Trace: [<ffffffffa03f5e1e>] radeon_dp_detect+0x1de/0x230 [radeon] [<ffffffffa014ac6d>] output_poll_execute+0xbd/0x1a0 [drm_kms_helper] [<ffffffffa014abb0>] ? drm_helper_mode_fill_fb_struct+0x30/0x30 [drm_kms_helper] [<ffffffff81083dca>] process_one_work+0x11a/0x480 [<ffffffff81084b74>] worker_thread+0x164/0x370 [<ffffffff81084a10>] ? manage_workers.isra.30+0x130/0x130 [<ffffffff810893cc>] kthread+0x8c/0xa0 [<ffffffff81660674>] kernel_thread_helper+0x4/0x10 [<ffffffff81089340>] ? flush_kthread_worker+0xa0/0xa0 [<ffffffff81660670>] ? gs_change+0x13/0x13
Pid: 49, comm: kworker/0:2 Tainted: G C O 3.2.0-10-generic #17-Ubuntu Call Trace: [<ffffffffa03f5e1e>] radeon_dp_detect+0x1de/0x230 [radeon] [<ffffffffa014b6b3>] drm_helper_probe_single_connector_modes+0x2c3/0x380 [drm_kms_helper] [<ffffffffa0149d42>] drm_fb_helper_hotplug_event+0xf2/0x150 [drm_kms_helper] [<ffffffffa03fe8d5>] radeon_fb_output_poll_changed+0x15/0x20 [radeon] [<ffffffffa03f7b65>] radeon_output_poll_changed+0x15/0x20 [radeon] [<ffffffffa014ad40>] output_poll_execute+0x190/0x1a0 [drm_kms_helper] [<ffffffffa014abb0>] ? drm_helper_mode_fill_fb_struct+0x30/0x30 [drm_kms_helper] [<ffffffff81083dca>] process_one_work+0x11a/0x480 [<ffffffff81084b74>] worker_thread+0x164/0x370 [<ffffffff81084a10>] ? manage_workers.isra.30+0x130/0x130 [<ffffffff810893cc>] kthread+0x8c/0xa0 [<ffffffff81660674>] kernel_thread_helper+0x4/0x10 [<ffffffff81089340>] ? flush_kthread_worker+0xa0/0xa0 [<ffffffff81660670>] ? gs_change+0x13/0x13
On Fri, Jan 20, 2012 at 05:08:31PM -0600, Seth Forshee wrote:
Can you track down who is calling the connector->detect() callbacks during suspend and resume?
I got two different stack traces, see below.
And to slightly amend my statement above, I'm only seeing the wrong status returned on the suspend side of things. The status during resume always seems to be correct.
Pid: 49, comm: kworker/0:2 Tainted: G C O 3.2.0-10-generic #17-Ubuntu Call Trace: [<ffffffffa03f5e1e>] radeon_dp_detect+0x1de/0x230 [radeon] [<ffffffffa014ac6d>] output_poll_execute+0xbd/0x1a0 [drm_kms_helper] [<ffffffffa014abb0>] ? drm_helper_mode_fill_fb_struct+0x30/0x30 [drm_kms_helper] [<ffffffff81083dca>] process_one_work+0x11a/0x480 [<ffffffff81084b74>] worker_thread+0x164/0x370 [<ffffffff81084a10>] ? manage_workers.isra.30+0x130/0x130 [<ffffffff810893cc>] kthread+0x8c/0xa0 [<ffffffff81660674>] kernel_thread_helper+0x4/0x10 [<ffffffff81089340>] ? flush_kthread_worker+0xa0/0xa0 [<ffffffff81660670>] ? gs_change+0x13/0x13
Pid: 49, comm: kworker/0:2 Tainted: G C O 3.2.0-10-generic #17-Ubuntu Call Trace: [<ffffffffa03f5e1e>] radeon_dp_detect+0x1de/0x230 [radeon] [<ffffffffa014b6b3>] drm_helper_probe_single_connector_modes+0x2c3/0x380 [drm_kms_helper] [<ffffffffa0149d42>] drm_fb_helper_hotplug_event+0xf2/0x150 [drm_kms_helper] [<ffffffffa03fe8d5>] radeon_fb_output_poll_changed+0x15/0x20 [radeon] [<ffffffffa03f7b65>] radeon_output_poll_changed+0x15/0x20 [radeon] [<ffffffffa014ad40>] output_poll_execute+0x190/0x1a0 [drm_kms_helper] [<ffffffffa014abb0>] ? drm_helper_mode_fill_fb_struct+0x30/0x30 [drm_kms_helper] [<ffffffff81083dca>] process_one_work+0x11a/0x480 [<ffffffff81084b74>] worker_thread+0x164/0x370 [<ffffffff81084a10>] ? manage_workers.isra.30+0x130/0x130 [<ffffffff810893cc>] kthread+0x8c/0xa0 [<ffffffff81660674>] kernel_thread_helper+0x4/0x10 [<ffffffff81089340>] ? flush_kthread_worker+0xa0/0xa0 [<ffffffff81660670>] ? gs_change+0x13/0x13
From these traces it looks like all that really needs to happen is to
disable the output polling during suspend. The following patch seems to get rid of the problems I'm seeing. Does this look okay to you?
From 0c01950f248c541198b7560793cf57c59b2c11f8 Mon Sep 17 00:00:00 2001
From: Seth Forshee seth.forshee@canonical.com Date: Tue, 31 Jan 2012 15:37:02 -0600 Subject: [PATCH 1/1] drm/radeon/kms: disable output polling when suspended
Polling the outputs when the device is suspended can result in erroneous status updates. Disable output polling during suspend to prevent this from happening.
Signed-off-by: Seth Forshee seth.forshee@canonical.com --- drivers/gpu/drm/radeon/radeon_device.c | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_device.c b/drivers/gpu/drm/radeon/radeon_device.c index cec51a5..49f7cb7 100644 --- a/drivers/gpu/drm/radeon/radeon_device.c +++ b/drivers/gpu/drm/radeon/radeon_device.c @@ -883,6 +883,8 @@ int radeon_suspend_kms(struct drm_device *dev, pm_message_t state) if (dev->switch_power_state == DRM_SWITCH_POWER_OFF) return 0;
+ drm_kms_helper_poll_disable(dev); + /* turn off display hw */ list_for_each_entry(connector, &dev->mode_config.connector_list, head) { drm_helper_connector_dpms(connector, DRM_MODE_DPMS_OFF); @@ -972,6 +974,8 @@ int radeon_resume_kms(struct drm_device *dev) list_for_each_entry(connector, &dev->mode_config.connector_list, head) { drm_helper_connector_dpms(connector, DRM_MODE_DPMS_ON); } + + drm_kms_helper_poll_enable(dev); return 0; }
On Tue, Jan 31, 2012 at 8:06 PM, Seth Forshee seth.forshee@canonical.com wrote:
On Fri, Jan 20, 2012 at 05:08:31PM -0600, Seth Forshee wrote:
Can you track down who is calling the connector->detect() callbacks during suspend and resume?
I got two different stack traces, see below.
And to slightly amend my statement above, I'm only seeing the wrong status returned on the suspend side of things. The status during resume always seems to be correct.
Pid: 49, comm: kworker/0:2 Tainted: G C O 3.2.0-10-generic #17-Ubuntu Call Trace: [<ffffffffa03f5e1e>] radeon_dp_detect+0x1de/0x230 [radeon] [<ffffffffa014ac6d>] output_poll_execute+0xbd/0x1a0 [drm_kms_helper] [<ffffffffa014abb0>] ? drm_helper_mode_fill_fb_struct+0x30/0x30 [drm_kms_helper] [<ffffffff81083dca>] process_one_work+0x11a/0x480 [<ffffffff81084b74>] worker_thread+0x164/0x370 [<ffffffff81084a10>] ? manage_workers.isra.30+0x130/0x130 [<ffffffff810893cc>] kthread+0x8c/0xa0 [<ffffffff81660674>] kernel_thread_helper+0x4/0x10 [<ffffffff81089340>] ? flush_kthread_worker+0xa0/0xa0 [<ffffffff81660670>] ? gs_change+0x13/0x13
Pid: 49, comm: kworker/0:2 Tainted: G C O 3.2.0-10-generic #17-Ubuntu Call Trace: [<ffffffffa03f5e1e>] radeon_dp_detect+0x1de/0x230 [radeon] [<ffffffffa014b6b3>] drm_helper_probe_single_connector_modes+0x2c3/0x380 [drm_kms_helper] [<ffffffffa0149d42>] drm_fb_helper_hotplug_event+0xf2/0x150 [drm_kms_helper] [<ffffffffa03fe8d5>] radeon_fb_output_poll_changed+0x15/0x20 [radeon] [<ffffffffa03f7b65>] radeon_output_poll_changed+0x15/0x20 [radeon] [<ffffffffa014ad40>] output_poll_execute+0x190/0x1a0 [drm_kms_helper] [<ffffffffa014abb0>] ? drm_helper_mode_fill_fb_struct+0x30/0x30 [drm_kms_helper] [<ffffffff81083dca>] process_one_work+0x11a/0x480 [<ffffffff81084b74>] worker_thread+0x164/0x370 [<ffffffff81084a10>] ? manage_workers.isra.30+0x130/0x130 [<ffffffff810893cc>] kthread+0x8c/0xa0 [<ffffffff81660674>] kernel_thread_helper+0x4/0x10 [<ffffffff81089340>] ? flush_kthread_worker+0xa0/0xa0 [<ffffffff81660670>] ? gs_change+0x13/0x13
From these traces it looks like all that really needs to happen is to disable the output polling during suspend. The following patch seems to get rid of the problems I'm seeing. Does this look okay to you?
Looks great. Thanks for tracking this down. We should probably cc stable as well when this gets committed.
Reviewed-by: Alex Deucher alexander.deucher@amd.com
From 0c01950f248c541198b7560793cf57c59b2c11f8 Mon Sep 17 00:00:00 2001 From: Seth Forshee seth.forshee@canonical.com Date: Tue, 31 Jan 2012 15:37:02 -0600 Subject: [PATCH 1/1] drm/radeon/kms: disable output polling when suspended
Polling the outputs when the device is suspended can result in erroneous status updates. Disable output polling during suspend to prevent this from happening.
Signed-off-by: Seth Forshee seth.forshee@canonical.com
drivers/gpu/drm/radeon/radeon_device.c | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_device.c b/drivers/gpu/drm/radeon/radeon_device.c index cec51a5..49f7cb7 100644 --- a/drivers/gpu/drm/radeon/radeon_device.c +++ b/drivers/gpu/drm/radeon/radeon_device.c @@ -883,6 +883,8 @@ int radeon_suspend_kms(struct drm_device *dev, pm_message_t state) if (dev->switch_power_state == DRM_SWITCH_POWER_OFF) return 0;
- drm_kms_helper_poll_disable(dev);
/* turn off display hw */ list_for_each_entry(connector, &dev->mode_config.connector_list, head) { drm_helper_connector_dpms(connector, DRM_MODE_DPMS_OFF); @@ -972,6 +974,8 @@ int radeon_resume_kms(struct drm_device *dev) list_for_each_entry(connector, &dev->mode_config.connector_list, head) { drm_helper_connector_dpms(connector, DRM_MODE_DPMS_ON); }
- drm_kms_helper_poll_enable(dev);
return 0; }
-- 1.7.8.3
On Thu, Jan 19, 2012 at 02:53:17PM -0600, Seth Forshee wrote:
On Thu, Jan 19, 2012 at 02:48:52PM -0500, Alex Deucher wrote:
On Thu, Jan 19, 2012 at 12:18 PM, Seth Forshee seth.forshee@canonical.com wrote:
I'm seeing several issues related to the radeon driver on a MacBook Pro 8,2 with the following graphics card:
ATI Technologies Inc Whistler [AMD Radeon HD 6600M Series] [1002:6741]
All problems were observed when using kernel version 3.2.1. None are seen when using fglrx.
1. Excessive power draw. When using the radeon driver ACPI reports a power draw of about 30W on an idle desktop. Using fglrx brings this number down to 15W.
The power saving features of the open source driver are not yet as good as the closed source driver. Please see the power management section of this page (http://wiki.x.org/wiki/RadeonFeature) for more info on the options currently available.
The dynpm option makes a small difference, saving about 2W. I did notice an ocassional flash on the screen with this option, and the same flash each time I changed the power options.
Btw how do you measure the power draw?
The only thing that improves things significatnly is the "low" profile method, which gets it down to about 18.5W.
I have older radeon (Mobility HD3650) and only the "low" profile makes it usable.. the "default" profile will overheat the laptop and crash it, or then Linux does automatic emergency thermal shutdown to protect the laptop.
If I boot some Linux livecd the laptop will basicly overheat and shutdown by itself before the desktop is loaded from the livecd.. :(
-- Pasi
On Fri, Jan 20, 2012 at 11:09:29PM +0200, Pasi Kärkkäinen wrote:
On Thu, Jan 19, 2012 at 02:53:17PM -0600, Seth Forshee wrote:
On Thu, Jan 19, 2012 at 02:48:52PM -0500, Alex Deucher wrote:
On Thu, Jan 19, 2012 at 12:18 PM, Seth Forshee seth.forshee@canonical.com wrote:
I'm seeing several issues related to the radeon driver on a MacBook Pro 8,2 with the following graphics card:
ATI Technologies Inc Whistler [AMD Radeon HD 6600M Series] [1002:6741]
All problems were observed when using kernel version 3.2.1. None are seen when using fglrx.
1. Excessive power draw. When using the radeon driver ACPI reports a power draw of about 30W on an idle desktop. Using fglrx brings this number down to 15W.
The power saving features of the open source driver are not yet as good as the closed source driver. Please see the power management section of this page (http://wiki.x.org/wiki/RadeonFeature) for more info on the options currently available.
The dynpm option makes a small difference, saving about 2W. I did notice an ocassional flash on the screen with this option, and the same flash each time I changed the power options.
Btw how do you measure the power draw?
You can get the instantaneous rate from the data under /proc/acpi/battery, but I use a tool called powerstat [1], written by my colleague Colin King. The advantage of powerstat is that it samples the ACPI data over a period of time and reports the average and standard deviation. That way I have a better idea of how much power is really being drawn and the quality of the value reported.
dri-devel@lists.freedesktop.org
-
Alex Deucher -
Pasi Kärkkäinen -
Seth Forshee