From: Jamie Heilman <jamie@audible.transient.net>
To: dri-devel@lists.freedesktop.org, airlied@gmail.com,
dakr@kernel.org, nouveau@lists.freedesktop.org,
linux-kernel@vger.kernel.org, lyude@redhat.com
Subject: Re: trapped reads in 7.3-rc1 since nv50 instmem handling change
Date: Mon, 21 Sep 2026 07:22:05 +0000 [thread overview]
Message-ID: <arDbHfeXuHDCKQNS@audible.transient.net> (raw)
In-Reply-To: <apnNRjrFPD48m4hO@audible.transient.net>
Jamie Heilman wrote:
> On my workstation with a Quadro NVS 290 running 7.3-rc1 I'm seeing
> this sort of thing show up spuriously:
>
> kernel: nouveau 0000:01:00.0: fb: trapped read at 0100ef56e0 on channel -1 [0fee0000 unknown] engine 06 [BAR] client 08 [PFIFO_READ] subclient 01 [IN] reason 00000002 [PAGE_NOT_PRESENT]
> kernel: nouveau 0000:01:00.0: fb: trapped read at 0100f85788 on channel -1 [0fee0000 unknown] engine 06 [BAR] client 08 [PFIFO_READ] subclient 01 [IN] reason 00000002 [PAGE_NOT_PRESENT]
> (repeated 16 times)
>
> I bisected it back to 34e27b90552a (nouveau/instmem: use iomapping
> interface for instmem handling). The rest of the salient dmesg during
> initialization is:
>
> kernel: nouveau 0000:01:00.0: NVIDIA G86 (086f00a2)
> kernel: nouveau 0000:01:00.0: bios: version 60.86.6c.00.21
> kernel: nouveau 0000:01:00.0: vgaarb: deactivate vga console
> kernel: Console: switching to colour dummy device 80x25
> kernel: nouveau 0000:01:00.0: bios: M0203T not found
> kernel: nouveau 0000:01:00.0: bios: M0203E not matched!
> kernel: nouveau 0000:01:00.0: fb: 256 MiB DDR2
> kernel: nouveau 0000:01:00.0: drm: VRAM: 256 MiB
> kernel: nouveau 0000:01:00.0: drm: GART: 1048576 MiB
> kernel: nouveau 0000:01:00.0: drm: TMDS table version 2.0
> kernel: nouveau 0000:01:00.0: drm: MM: using CRYPT for buffer copies
> kernel: [drm] Initialized nouveau 1.4.3 for 0000:01:00.0 on minor 0
> kernel: Console: switching to colour frame buffer device 240x75
> kernel: nouveau 0000:01:00.0: [drm] fb0: nouveaudrmfb frame buffer device
>
> It doesn't always happen at boot, sometimes it takes a while to show
> up as it seems to be related to how much I have going on at any point
> in time. That commit reverts cleanly for the moment, but I'm happy to
> test any ideas or enable further debugging as needed, assuming this
> wasn't intentional.
This is still present after deced5fa01c5 ("nouveau/instmem: handle
iomapping already existing") and in 7.3-rc4. Apart from the log spam
(which has made journald angry once by flooding the buffer) it doesn't
seem to have any other serious consequences yet though.
--
Jamie Heilman http://audible.transient.net/~jamie/
prev parent reply other threads:[~2026-09-21 14:46 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-03 19:40 trapped reads in 7.3-rc1 since nv50 instmem handling change Jamie Heilman
2026-09-21 7:22 ` Jamie Heilman [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=arDbHfeXuHDCKQNS@audible.transient.net \
--to=jamie@audible.transient.net \
--cc=airlied@gmail.com \
--cc=dakr@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lyude@redhat.com \
--cc=nouveau@lists.freedesktop.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.