Suspend lockup: How to bisect d-r-t specific commits?

[Rafał Miłecki]

W dniu 24 lipca 2010 22:41 użytkownik Alex Deucher
<alexdeucher at gmail.com> napisał:
> 2010/7/24 Rafał Miłecki <zajec5 at gmail.com>:
>> W dniu 21 lipca 2010 19:23 użytkownik Alex Deucher
>> <alexdeucher at gmail.com> napisał:
>>> 2010/7/21 Rafał Miłecki <zajec5 at gmail.com>:
>>>> W dniu 21 lipca 2010 11:30 użytkownik Rafał Miłecki <zajec5 at gmail.com> napisał:
>>>>> First bisect try gave me:
>>>>> bad: [d8c253f30d0eb975e5c42c31587ef718517f5067]
>>>>> drm/radeon: optimize default 3D state for r6xx/r7xx blits
>>>>>
>>>>> I'm leaving today, not sure if I manage to confirm this before next week.
>>>>
>>>> I switched back to rebased drm-radeon-testing and confirmed lockup.
>>>> Then reverted that single patch and it helped. I'm quite sure it's the
>>>> "bad one".
>>>>
>>>> I use KDE4 with effects enabled, so 3D is enabled here.
>>>>
>>>> Not time to dig into this problem deeper, leaving now.
>>>
>>> When you get back can you revert the original and test version 2 of
>>> that patch (attached).  It puts back the original state, but
>>> reorganizes the emit order to reduce the number of dwords.
>>
>> Applied V2 instead of V1 and got lockup again (on resume). Reverting
>> applied V2 (so without V1 and without V2) "fixes" lockup.
>
> I see the problem.  The original waited for idle at the top of the
> default state.  This new patch is v1 + wait for idle.  Please remove
> v1 and v2 and then apply v3.

Whoops, still no luck with V3 (applied as only version of patch) :| Is
that possible to split changes in r6xx_default_state to track down
problematic one?

The difference I noticed with V3 is that I got 5-6 screen flashes
after resuming. Earlier it was about 3. However I tested it just once,
can be not related.

-- 
Rafał