radeon issues on MacBook Pro 8,2

radeon issues on MacBook Pro 8,2

[Seth Forshee]

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

Re: radeon issues on MacBook Pro 8,2

[Alex Deucher]

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

Re: radeon issues on MacBook Pro 8,2

[Seth Forshee]

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

Re: radeon issues on MacBook Pro 8,2

[Seth Forshee]

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

Re: radeon issues on MacBook Pro 8,2

[Alex Deucher]

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

Re: radeon issues on MacBook Pro 8,2

[Seth Forshee]

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.

Re: radeon issues on MacBook Pro 8,2

[Alex Deucher]

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

Re: radeon issues on MacBook Pro 8,2

[Seth Forshee]

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

Re: radeon issues on MacBook Pro 8,2

[Seth Forshee]

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;
 }
 
-- 
1.7.8.3

Re: radeon issues on MacBook Pro 8,2

[Alex Deucher]

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
>

Re: radeon issues on MacBook Pro 8,2

[Pasi Kärkkäinen]

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

Re: radeon issues on MacBook Pro 8,2

[Seth Forshee]

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.

[1] http://kernel.ubuntu.com/git?p=cking/powerstat.git