Suspend lockup: How to bisect d-r-t specific commits?
zajec5 at gmail.com
Sun Jul 25 05:14:33 PDT 2010
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
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.
More information about the dri-devel