search for: hw_done

Without waiting for hw_done, previous atomic updates may dereference the wrong state and cause a lot of confusion. The real fix is fixing all obj->state to use the accessor macros, but for now wait indefinitely and interruptibly. Cc: Boris Brezillon <boris.brezillon at free-electrons.com> Cc: David Airlie <airlie...

...012] nouveau 0000:01:00.0: gr: TRAP ch 6 [023f718000 systemd-logind[757]] [ +0.000008] nouveau 0000:01:00.0: gr: GPC1/PROP trap: 00000020 [RT_HEIGHT_OVERRUN] x = 1888, y = 1056, format = 2a, storage type = 0 [May28 12:01] [drm:drm_atomic_helper_swap_state [drm_kms_helper]] *ERROR* [CRTC:37:head-0] hw_done timed out [ +10.240079] [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] *ERROR* [CRTC:37:head-0] hw_done timed out [May28 12:02] [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] *ERROR* [CRTC:37:head-0] flip_done timed out [ +10.240040] [drm:drm_atomic_helper_swap_state...

We want to change swap_state to wait indefinitely, but to do this swap_state should wait interruptibly. This requires propagating the error to each driver. All drivers have changes to deal with the clean up. In order to allow easy reverting, the commit that changes behavior is separate so someone only has to revert that for testing. Nouveau has a small bugfix, if drm_atomic_helper_wait_for_fences

On 07/05/2017 23:50, Ilia Mirkin wrote: > You have two issues: > > (a) nouveau's GL driver messed something up, causing a read fault error > (b) nouveau's kernel driver tried to recover. It failed. > > Solution to #1: None, really. You can try updating mesa, and hope it > helps. Not sure what version you're on. Here's my packages version: ii

...m_atomic_helper_swap_state(state, true); > Push the swap_state up over the commit setup (but after the allocation) > and there's no more a problem with unrolling. This can't be done higher up because of the interruptible wait. Unless we change the patch series to move the waiting for hw_done to a separate step and get rid of the stall argument to swap_state once everything is converted. This could be useful for all drivers that have some kind of setup, because we could move the wait up slightly to suit the drivers needs. ~Maarten

...ust pushed. Or if someone forgot to fix up their mess. > > What was the conflict? > > dim push-branches was complaining that one of the commits was > missing the proper committer sign-off, it was the bottom commit under > mine (IIRC "drm/atomic-helper: WARN if fake_commit->hw_done is not > completed as expected") > and dim update-branches seemed to rebase and fix up my patches > and then everything was fine. This sounds like you (or dim?) accidentaly amended that commit (which changes the committer and results in the warning), and a rebase would indeed have fi...

https://bugs.freedesktop.org/show_bug.cgi?id=103721 Bug ID: 103721 Summary: Frequent freezes with nouveau on Thinkpad P50 Product: xorg Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Driver/nouveau Assignee: nouveau at

...). Journalctl -b -1 output is attached. Most relevant lines are: kernel: nouveau 0000:01:00.0: fifo: SCHED_ERROR 0a [CTXSW_TIMEOUT] kernel: nouveau 0000:01:00.0: fifo: gr engine fault on channel 12, recovering... kernel: [drm:drm_atomic_helper_swap_state [drm_kms_helper]] *ERROR* [CRTC:37:head-0] hw_done timed out kernel: [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] *ERROR* [CRTC:37:head-0] hw_done timed out kernel: [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] *ERROR* [CRTC:37:head-0] flip_done timed out A possibly related bug is #96562, but it is old and hasn...