similar to: GT 730 freeze : how do diagnose / debug ?

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

Some additional data: - putting LIBGL_ALWAYS_SOFTWARE=1 in /etc/environment makes indeed the system work (for my current usage, the slowness is acceptable in exchange of stabillity) - I still get lock-up using mesa from git (17.2~git1705081930.25d2 from this repository https://launchpad.net/~oibaf/+archive/ubuntu/graphics-drivers) I have another question (probably Ben Skeggs could also give an

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. Solution to #2: Ben Skeggs will hopefully have something clever to say. The recovery logic was recently beefed up considerably,

https://bugs.freedesktop.org/show_bug.cgi?id=100567 Bug ID: 100567 Summary: Nouveau system freeze fifo: SCHED_ERROR 0a [CTXSW_TIMEOUT] Product: xorg Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Driver/nouveau

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

https://bugs.freedesktop.org/show_bug.cgi?id=104222 Bug ID: 104222 Summary: GNOME/Wayland desktop freezes when resizing Firefox window Product: xorg Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Driver/nouveau

https://bugs.freedesktop.org/show_bug.cgi?id=108080 Bug ID: 108080 Summary: GK106 [GeForce GTX 660] System Freeze - warp 3d0009 [ILLEGAL_INSTR_ENCODING] Product: xorg Version: unspecified Hardware: x86-64 (AMD64) OS: All Status: NEW Severity: critical Priority: medium

https://bugs.freedesktop.org/show_bug.cgi?id=99900 --- Comment #26 from kenorb at gmail.com --- Similar problem, described in: https://bugs.freedesktop.org/show_bug.cgi?id=100567#c18 Call Trace: __schedule+0x29e/0x840 schedule+0x2c/0x80 schedule_timeout+0x258/0x360 ? nv50_wndw_atomic_destroy_state+0x1d/0x20 [nouveau] dma_fence_default_wait+0x1fc/0x260 ? dma_fence_release+0xa0/0xa0

Use the new atomic iterator macros, the old ones are about to be removed. With the new macros, it's more easy to get old and new state so get them from the macros instead of from obj->state. Signed-off-by: Maarten Lankhorst <maarten.lankhorst at linux.intel.com> Cc: Ben Skeggs <bskeggs at redhat.com> Cc: nouveau at lists.freedesktop.org ---

Use the new atomic iterator macros, the old ones are about to be removed. With the new macros, it's more easy to get old and new state so get them from the macros instead of from obj->state. Changes since v1: - Don't mix up old and new state. (danvet) - Rebase on top of interruptible swap_state changes. Signed-off-by: Maarten Lankhorst <maarten.lankhorst at linux.intel.com> Cc:

Hello, Commit 2541626cfb79 breaks GM20B probe with the following kernel log: [ 2.153892] ------------[ cut here ]------------ [ 2.153897] WARNING: CPU: 1 PID: 36 at drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgf100.c:273 gf100_vmm_valid+0x2c4/0x390 [ 2.153916] Modules linked in: [ 2.153922] CPU: 1 PID: 36 Comm: kworker/u8:1 Not tainted 6.1.0+ #1 [ 2.153929] Hardware name: Google

On Thu, Jul 12, 2018 at 01:02:53PM -0400, Lyude Paul wrote: > --- a/drivers/gpu/drm/nouveau/dispnv50/disp.c > +++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c > @@ -1878,7 +1878,7 @@ nv50_disp_atomic_commit(struct drm_device *dev, > nv50_disp_atomic_commit_tail(state); > > drm_for_each_crtc(crtc, dev) { > - if (crtc->state->enable) { > + if

Just some runtime PM fixes for some much less noticeable runtime PM ref tracking issues that I got reminded of when fixing some unrelated issues with nouveau. Changes since v1: * Don't fix CRTC RPM code in dispnv04, because it's not actually doing anything in the first place. Just get rid of it. - imirkin Lyude Paul (2): drm/nouveau/dispnv04: Remove runtime PM drm/nouveau/dispnv50:

Just some runtime PM fixes for some much less noticeable runtime PM ref tracking issues that I got reminded of when fixing some unrelated issues with nouveau. Lyude Paul (2): drm/nouveau/dispnv04: Grab/put runtime PM refs on DPMS on/off drm/nouveau/dispnv50: Fix runtime PM ref tracking for non-blocking modesets drivers/gpu/drm/nouveau/dispnv04/crtc.c | 18 +++---------

On Wed, Jul 12, 2017 at 10:13:43AM +0200, Maarten Lankhorst wrote: > Use the new atomic iterator macros, the old ones are about to be > removed. With the new macros, it's more easy to get old and new state so > get them from the macros instead of from obj->state. > > Signed-off-by: Maarten Lankhorst <maarten.lankhorst at linux.intel.com> > Cc: Ben Skeggs <bskeggs

This is the latest version of https://patchwork.freedesktop.org/series/45862/ . One new patch has been added that also addresses some additional issues I found with pmops_runtime_idle that would stop nouveau from suspending the GPU when running under X. Additionally, "drm/nouveau: Fix runtime PM leak in nv50_disp_atomic_commit()" has had it's CC to stable removed. Lyude Paul (3):

No problemos with x86_64, however on i686 kworker/u16:57: page allocation failure: order:0, mode:0x284000 CPU: 0 PID: 1425 Comm: kworker/u16:57 Not tainted 3.18.0-0.rc5.git0.1.fc22.i686+debug #1 Workqueue: events_unbound async_run_entry_fn Call Trace: [<c0b2b55a>] dump_stack+0x48/0x60 [<c056f3d4>] warn_alloc_failed+0xd4/0x110 [<c0571ade>] __alloc_pages_nodemask+0x81e/0xc30

On Thu, Dec 29, 2022 at 12:58 AM Diogo Ivo <diogo.ivo at tecnico.ulisboa.pt> wrote: > > Hello, > > Commit 2541626cfb79 breaks GM20B probe with > the following kernel log: > > [ 2.153892] ------------[ cut here ]------------ > [ 2.153897] WARNING: CPU: 1 PID: 36 at drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgf100.c:273 gf100_vmm_valid+0x2c4/0x390 > [

On Mon, Jan 22, 2018 at 10:38 PM, Nathan March <nathan at gt.net> wrote: > Just a heads up that I'm seeing major stability problems on these builds. > Didn't have console capture setup unfortunately, but have seen my test > hypervisor hard lock twice over the weekend. > > This is with xpti being used, rather than the shim. Thanks for the heads-up. It's been

While I had thought I'd tested this before, it looks like this one issue slipped by my original CRC patches. Basically, there seem to be a few rules we need to follow when sending CRC commands to the display controller: * CRCs cannot be both disabled and enabled for a single head in the same flush * If a head with CRC reporting enabled switches from one OR to another, there must be a