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?
