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@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxx> 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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/