From mboxrd@z Thu Jan 1 00:00:00 1970 From: Seth Forshee Subject: Re: radeon issues on MacBook Pro 8,2 Date: Fri, 20 Jan 2012 17:08:31 -0600 Message-ID: <20120120230831.GA2292@ubuntu-macmini> References: <20120119171808.GB23144@ubuntu-macmini> <20120119205317.GC23144@ubuntu-macmini> <20120120155318.GA8162@ubuntu-macmini> <20120120211214.GC8162@ubuntu-macmini> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Alex Deucher Cc: Dave Airlie , Alex Deucher , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, Seth Forshee List-Id: dri-devel@lists.freedesktop.org On Fri, Jan 20, 2012 at 04:39:31PM -0500, Alex Deucher wrote: > On Fri, Jan 20, 2012 at 4:12 PM, Seth Forshee > 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 > >> wrote: > >> > On Thu, Jan 19, 2012 at 02:53:17PM -0600, Seth Forshee wrote: > >> >> > > =C2=A02. Occasional long delays when suspending. When this = happens I see > >> >> > > =C2=A0 =C2=A0messages like following in dmesg: > >> >> > > > >> >> > > =C2=A0 =C2=A0 =C2=A0[drm:atom_op_jump] *ERROR* atombios stu= ck in loop for more than 5secs aborting > >> >> > > =C2=A0 =C2=A0 =C2=A0[drm:atom_execute_table_locked] *ERROR*= atombios stuck executing D44E (len 62, WS 0, PS 0) @ 0xD46A > >> >> > > > >> >> > > =C2=A0 =C2=A0Sometimes one of suspend or resume hangs compl= etely, but I can't > >> >> > > =C2=A0 =C2=A0tell which and am not sure whether or not it's= related. I'm also > >> >> > > =C2=A0 =C2=A0testing a Mac Mini with the exact same card wh= ich does not seem to > >> >> > > =C2=A0 =C2=A0suffer from this issue. > >> >> > > > >> >> > > =C2=A0 =C2=A0I ran a bisections that identified f8d0edd (dr= m/radeon/kms: improve > >> >> > > =C2=A0 =C2=A0DP detect logic) as introducing problems with = suspend, and reverting > >> >> > > =C2=A0 =C2=A0this patch on top of 3.2.1 does seem to elimin= ate both issues. > >> >> > > > >> >> > > >> >> > That patch doesn't really affect the modesetting paths direct= ly; it > >> >> > looks like a red herring to me. > >> >> > >> >> Perhaps. I just started a run of 200 s3 cycles with the patch r= everted > >> >> 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 with= out long > >> > delays, hangs, or any atombios error messages. Without reverting= it > >> > doesn't get through many at all before experiencing the errors a= nd long > >> > delays or hangs. > >> > > >> > I added a printout of the connector status resulting from the lo= gic that > >> > was changed by f8d0edd. With the logic prior to this commit it > >> > consistently returns the status as disconnected, which is correc= t as I > >> > have nothing connected. But with the improved logic the status i= s > >> > sometimes reported as connected, and these coincide with the ato= mbios > >> > 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. >=20 > 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: [] radeon_dp_detect+0x1de/0x230 [radeon] [] output_poll_execute+0xbd/0x1a0 [drm_kms_helper] [] ? drm_helper_mode_fill_fb_struct+0x30/0x30 [drm_= kms_helper] [] process_one_work+0x11a/0x480 [] worker_thread+0x164/0x370 [] ? manage_workers.isra.30+0x130/0x130 [] kthread+0x8c/0xa0 [] kernel_thread_helper+0x4/0x10 [] ? flush_kthread_worker+0xa0/0xa0 [] ? gs_change+0x13/0x13 Pid: 49, comm: kworker/0:2 Tainted: G C O 3.2.0-10-generic #17= -Ubuntu Call Trace: [] radeon_dp_detect+0x1de/0x230 [radeon] [] drm_helper_probe_single_connector_modes+0x2c3/0x= 380 [drm_kms_helper] [] drm_fb_helper_hotplug_event+0xf2/0x150 [drm_kms_= helper] [] radeon_fb_output_poll_changed+0x15/0x20 [radeon] [] radeon_output_poll_changed+0x15/0x20 [radeon] [] output_poll_execute+0x190/0x1a0 [drm_kms_helper] [] ? drm_helper_mode_fill_fb_struct+0x30/0x30 [drm_= kms_helper] [] process_one_work+0x11a/0x480 [] worker_thread+0x164/0x370 [] ? manage_workers.isra.30+0x130/0x130 [] kthread+0x8c/0xa0 [] kernel_thread_helper+0x4/0x10 [] ? flush_kthread_worker+0xa0/0xa0 [] ? gs_change+0x13/0x13