W dniu 24 lipca 2010 22:41 użytkownik Alex Deucher <alexdeucher@xxxxxxxxx> napisał: > 2010/7/24 Rafał Miłecki <zajec5@xxxxxxxxx>: >> W dniu 21 lipca 2010 19:23 użytkownik Alex Deucher >> <alexdeucher@xxxxxxxxx> napisał: >>> 2010/7/21 Rafał Miłecki <zajec5@xxxxxxxxx>: >>>> W dniu 21 lipca 2010 11:30 użytkownik Rafał Miłecki <zajec5@xxxxxxxxx> 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ł _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
