[Nouveau] drm-nouveau-next - write trapped by fbcon

[Ilia Mirkin]

On Wed, Jan 1, 2014 at 3:29 PM, Michele Baldessari <michele at acksyn.org> wrote:
> On Wed, Dec 11, 2013 at 07:21:05AM -0500, Ilia Mirkin wrote:
>> >> On Thu, 5 Dec 2013 10:55:06 -0500 Ilia Mirkin wrote:
>> >> > On Thu, Dec 5, 2013 at 10:17 AM, Bruno Prémont wrote:
>> >> > > With drm-nouveau-next branch on top of 3.13-rc2 and a few sound commits
>> >> > > I get following errors in kernel log (repeating much more often).
>> >> > > (once there was a corrupted fbcon with matrix-like strings of
>> >> > > unrecognizable glyph-strings hanging down from screen top border)
>> >> > >
>> >> > > These errors do stop once I switch to Xorg.
>> >> > >
>> >> > > [   13.825627] nouveau E[     PFB][0000:02:00.0] trapped write at 0x0000408280 on channel 0x0000fee0 [unknown] BAR/PFIFO_WRITE/FB reason: PAGE_NOT_PRESENT
>> >> > > [   13.826506] nouveau E[     PFB][0000:02:00.0] trapped write at 0x0000408280 on channel 0x0000fee0 [unknown] BAR/PFIFO_WRITE/FB reason: PAGE_NOT_PRESENT
>> >> > > [   13.827319] nouveau E[     PFB][0000:02:00.0] trapped write at 0x0000408280 on channel 0x0000fee0 [unknown] BAR/PFIFO_WRITE/FB reason: PAGE_NOT_PRESENT
>> >> > > [   13.828139] nouveau E[     PFB][0000:02:00.0] trapped write at 0x0000408280 on channel 0x0000fee0 [unknown] BAR/PFIFO_WRITE/FB reason: PAGE_NOT_PRESENT
>> >> > > [   13.828957] nouveau E[     PFB][0000:02:00.0] trapped write at 0x0000400300 on channel 0x0000fee0 [unknown] BAR/PFIFO_WRITE/FB reason: PAGE_NOT_PRESENT
>> >> > >
>> >> > > System MBA2,1 with:
>> >> > > 02:00.0 VGA compatible controller [0300]: NVIDIA Corporation C79 [GeForce 9400M] [10de:0870] (rev b1)
>> >> >
>> >> > Do you also see these in 3.13-rc2 +
>> >> > http://cgit.freedesktop.org/nouveau/linux-2.6/commit/?h=drm-nouveau-next&id=a7e4201f0f7d47e03b851f06f8987856e8d33083
>> >> > ? If not, you can reorder the patches (git rebase -i) and bisect the
>> >> > rest. Basically the GPU is trying to write to some address that is
>> >> > either completely bogus or is stale, and its internal MMU won't let
>> >> > it.
>> >>
>> >> If I remember correctly these did not happen with Linus' rc2 but only
>> >> do happen with drm-nouveau-next on top of it.
>> >>
>> >> I will check and bisect though probably will not get time to complete
>> >> bisect before late Saturday.
>> >>
>> >>
>> >> A display glitch during kernel boot with fbcon might be related to this.
>> >> (very wild guess based on when the trapped writes happen)
>> >> The penguin logo shown by fbcon looks like memcopy'ed to a tiled
>> >> framebuffer without respecting the fact that framebuffer is tiled.
>> >
>> > It was introduced somewhere between 3.12 and 3.13-rc2 though does not happen
>> > on every boot and when it happens it might be only a couple of trapped writes
>> > or a whole lot flooding complete log buffer.
>> >
>> > Visually it manifests itself as a scrambled framebuffer
>> > (looking like tiled versus untiled writing to framebuffer).
>> > When it happens, it seem to be correlated to call to dialog to ask for
>> > luks password and screen scrambling happens when boot messages
>> > (kernel/userspace) show/scroll by [they wipe out some scrambled area
>> > when scrolling by].
>> >
>> > Unfortunately it will be rather hard to bisect because sometimes it does not
>> > happen.
>> > Adding drm-nouveau-next on top of rc2/rc3 does no apparent difference.
>>
>> A shot in the dark -- try booting with nouveau.config=NvMSI=0. We
>> already disable MSI for NVAA, perhaps we should do it for NVAC as
>> well. Although the blob drivers have it enabled... but we could be
>> doing something wrong.
>
> Hi Ilia,
>
> FWIW a Fedora user got those messages on stock 3.13-rc6 with and without the
> "nouveau.config=nvMSI=0" boot option:
> [   10.812029] nouveau E[     PFB][0000:01:00.0] trapped write at 0x0000525500 on channel 0x0001fed0 [unknown] BAR/PFIFO_WRITE/FB reason: PAGE_NOT_PRESENT
>
> This is via BZ https://bugzilla.redhat.com/show_bug.cgi?id=927451

That bug is about someone with a NV84, so my comment about NVAA/NVAC
similarities doesn't apply. But it's good to know that MSI isn't at
fault (probably). I guess it's bisect time.

  -ilia