(In reply to bruno.pagani from comment #0)
> [  454.919271] nouveau 0000:02:00.0: bus: MMIO write of 00000002 FAULT at
> 4188ac [ IBUS ]

That's bad.

4188ac = PGRAPH.GPC_BROADCAST.FFB.PART_CONFIG

I believe we do this here:

drm/nouveau/nvkm/engine/gr/gk104.c:     nvkm_wr32(device, GPC_BCAST(0x08ac), nvkm_rd32(device, 0x100800));

> [  454.989954] nouveau 0000:02:00.0: DRM: Pointer to TMDS table invalid
> [  454.989957] nouveau 0000:02:00.0: DRM: Pointer to flat panel table invalid

These are (semi-)expected. Should probably just make them no longer errors.

> [  470.245180] nouveau 0000:02:00.0: bus: MMIO write of ffffff1f FAULT at
> 6013d4 [ IBUS ]

That's bad too. This is related to the legacy 0x3d4 VGA IO port (which still has to be used for various display-related things). Unless you've skimped on the dmesg, you don't have any DCB entries and it may be reasonable to believe you don't have a display block at all. (I assume there are no outputs wired up to the NVIDIA GPU?) In that case, we should probably track down where we're trying to do this from and skip it. Based on the location in the logs, probably something VBIOS- or other early-init-related.

Unfortunately I don't have any actual debugging steps for you. Perhaps Ben will.

(In reply to Ilia Mirkin from comment #1)
> (In reply to bruno.pagani from comment #0)
> > [  454.919271] nouveau 0000:02:00.0: bus: MMIO write of 00000002 FAULT at
> > 4188ac [ IBUS ]
> 
> That's bad.
> 
> 4188ac = PGRAPH.GPC_BROADCAST.FFB.PART_CONFIG
> 
> I believe we do this here:
> 
> drm/nouveau/nvkm/engine/gr/gk104.c:     nvkm_wr32(device, GPC_BCAST(0x08ac),
> nvkm_rd32(device, 0x100800));
> 
> > [  470.245180] nouveau 0000:02:00.0: bus: MMIO write of ffffff1f FAULT at
> > 6013d4 [ IBUS ]
> 
> That's bad too. This is related to the legacy 0x3d4 VGA IO port (which still
> has to be used for various display-related things). Unless you've skimped on
> the dmesg, you don't have any DCB entries and it may be reasonable to
> believe you don't have a display block at all. (I assume there are no
> outputs wired up to the NVIDIA GPU?) In that case, we should probably track
> down where we're trying to do this from and skip it. Based on the location
> in the logs, probably something VBIOS- or other early-init-related.
> 
> Unfortunately I don't have any actual debugging steps for you. Perhaps Ben
> will.

Indeed, this is an Optimus laptop with no output wired to the NVIDIA GPU.

Also, now that you mention it, the second hex chain is indeed always 6013d4 on following attempts (only the first hex chain changes).

Will wait for Ben requests of information/debug trial then. ;)

This one:

nouveau 0000:02:00.0: bus: MMIO write of 00000002 FAULT at 4188ac [ IBUS ]

also appears when resuming from suspend.

Seeing this same issue in the latest Fedora 25 updates.

Will post dmesg output.

This is for a NVE7 (GK107) GK107GLM [Quadro K1100M] chip.
It is a hybrid solution with an Intel i915 (VGA) in front of the nVidia chip.
The nVidia chips is not usable as a display device, it just handles 3D for the intel chip.

# inxi -Fzx
System:    Host: xyzzy Kernel: 4.9.14-200.fc25.x86_64 x86_64 (64 bit gcc: 6.3.1)
           Desktop: Cinnamon 3.2.8 (Gtk 3.22.10) Distro: Fedora release 25 (Twenty Five)
Machine:   Device: portable System: Dell product: Dell Precision M3800 v: A09
           Mobo: Dell model: Dell Precision M3800 v: A09 BIOS: Dell v: A09 date: 01/08/2015
CPU:       Quad core Intel Core i7-4712HQ (-HT-MCP-) cache: 6144 KB
           flags: (lm nx sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx) bmips: 18358
           clock speeds: max: 3300 MHz 1: 799 MHz 2: 799 MHz 3: 799 MHz 4: 799 MHz 5: 800 MHz 6: 799 MHz
           7: 800 MHz 8: 799 MHz
Graphics:  Card-1: Intel 4th Gen Core Processor Integrated Graphics Controller bus-ID: 00:02.0
           Card-2: NVIDIA GK107GLM [Quadro K1100M] bus-ID: 02:00.0
           Display Server: Fedora X.org 119.1 drivers: nouveau,intel (unloaded: modesetting,fbdev,vesa)
           Resolution: 1920x1080@60.00hz, 2560x1440@59.95hz
           GLX Renderer: Mesa DRI Intel Haswell Mobile GLX Version: 3.0 Mesa 13.0.4 Direct Rendering: Yes

Will post dmesg output.

Created attachment 130485 [details]
dmesg output

[  383.017431] nouveau 0000:02:00.0: DRM: evicting buffers...
[  383.017436] nouveau 0000:02:00.0: DRM: waiting for kernel channels to go idle...
[  383.017485] nouveau 0000:02:00.0: DRM: suspending client object trees...
[  383.023473] nouveau 0000:02:00.0: DRM: suspending kernel object tree...
[  467.070587] nouveau 0000:02:00.0: DRM: resuming kernel object tree...
[  467.386991] nouveau 0000:02:00.0: bus: MMIO write of 00000002 FAULT at 4188ac [ IBUS ]
[  467.408872] nouveau 0000:02:00.0: DRM: resuming client object trees...

Benchmark test: "export vblank_mode=0; glxgears"

Normally get 12,000 FPS.

With this bug, 1,000 FPS.

(In reply to Bob Bugzilla from comment #6)
> Benchmark test: "export vblank_mode=0; glxgears"
> 
> Normally get 12,000 FPS.
> 
> With this bug, 1,000 FPS.

With PRIME, that's a benchmark of PCIe bandwidth. Probably stuck at 2.5 GT/s if you didn't reclock.

Not using Optimus or Prime.  Have never needed that.  The second cpu (nvidia) is not directly usable for x display.  The benchmark is being run on the Intel chip (which hands 3D requests back to the nvidia chip).

(In reply to Bob Bugzilla from comment #8)
> on the Intel chip (which hands 3D requests back to the nvidia chip).

Aka "PRIME".

Hum, shouldn’t there be some DRI_PRIME=1 for the Nvidia GPU to be used?

Anyway, you’re having almost the same laptop than mine, which is the XPS 15 9530 version while you have the Precision M3800, the main difference is thus the GPU, but even there it’s just the same chip but within the Quadro range for you (which means basically FP64 enabled FWIU) while I have the regular one.

So we’re still at the same point that 5 months ago, just needing Ben to come by and fix this or ask for us to run debugging steps.

While those errors are undesirable, do they end up in any actual issues beyond the error logs themselves? Just want to make sure I understand this bug report properly.

(In reply to Ilia Mirkin from comment #11)
> While those errors are undesirable, do they end up in any actual issues
> beyond the error logs themselves? Just want to make sure I understand this
> bug report properly.

Not that I’m aware of. But OTOH I’ve haven’t played a lot if at all with my Nvidia GPU, so…

I have the noted graphics performance issue.  I attribute this to the errors, as I believe that the errors are new.  However, I do not know enough about the errors to correlate them to the performance issue directly.

Running "export vblank_mode=0; DRI_PRIME=1 glxgears" yields about 4,000 FPS.

Better but not the 12,000 FPS as previously bench marked.

@Bob Bugzilla: I’m not sure glxgears can be considered as a proper benchmark…

Anyway, I think it’s really unlikely an issue on your Nvidia card affects the performances of your Intel one, which is what you’re currently saying.

Also, are you sure this issue is new? What did you have before? Because AFAIR, I had this for as long as https://bugzilla.freedesktop.org/show_bug.cgi?id=70354 has been solved, and prior to that, well…

Hi @Bruno Pagani

I used glxgears as a relative benchmark (not absolute). Previously had 12,000 FPS.  Now get 1,000 FPS.

This is new and the timing correlates with the arrival of the nouveau faults in dmesg, and both correlate with applying the latest updates via Fedora 25.

I did try the "options nouveau config=War00C800_0=1" modprobe.d patch from bug 70354, but no change.

Looking for things to try, but don't know where to look.  Ideas?

(In reply to Bob Bugzilla from comment #16)
> I used glxgears as a relative benchmark (not absolute). Previously had
> 12,000 FPS.  Now get 1,000 FPS.
> 
> This is new and the timing correlates with the arrival of the nouveau faults
> in dmesg, and both correlate with applying the latest updates via Fedora 25.

So what is happening is that you got a bunch of updates, and now are linking uncorrelated things together, because the only correlation I see here is that both problems are related to this update, but I don’t think they have any other sort of links between them. A being correlated to B and C being also correlated to B doesn’t imply that A and C are correlated together. It would be like saying “Hey my new car cannot drive as fast as my previous one, this must has something to do with the fact I can get the music volume to the same level as in my previous one”. This are two unrelated things that both link to the fact you’ve changed your car, but there is no any kind of connection that could be made between those two things otherwise.

> I did try the "options nouveau config=War00C800_0=1" modprobe.d patch from
> bug 70354, but no change.

Yes, and you had no reason to try that, don’t know what you expected… If you had read the bug report, you would have seen that the main issue has been fixed for everyone quite some time ago, and that the bug report we are currently discussing over is for this MMIO error that has in fact been present even before 70354 was solved (https://bugzilla.freedesktop.org/show_bug.cgi?id=70354#c53, https://bugzilla.freedesktop.org/show_bug.cgi?id=87942), and is still present today.

> Looking for things to try, but don't know where to look.  Ideas?

So let me recap that again. You’ve updated your system, and because of that your glxgears perfs decreased. If you want to do something about it, then you should report a regression bug against the component that is responsible for that, which require you to rollover your system to its previous state, verify whether things are OK and not, and then as much as possible upgrade packages one by one and verify whether perfs change, and when they do you’ll have found what package is responsible for this. But please stop reporting this to this thread, this is unrelated.

Now, regarding the issue in this thread, are you sure you never had this issue before? Do you have kernel log from prior to the update? Maybe through journalctl -k?

I find it unlikely that this issue started occurring at some point and wasn’t present from the start (since it has been for me), but I’m no kernel dev so I might very well be wrong on this. Or maybe your previous kernel was so old that the card wasn’t initialized at all and thus you didn’t see any issue.

I am having the exact same error:
[  255.209084] IPv6: ADDRCONF(NETDEV_UP): wlp4s0: link is not ready
[  255.301306] wlp4s0: authenticate with 58:8b:f3:66:30:a9
[  255.304574] wlp4s0: send auth to 58:8b:f3:66:30:a9 (try 1/3)
[  255.305597] wlp4s0: authenticated
[  255.307531] wlp4s0: associate with 58:8b:f3:66:30:a9 (try 1/3)
[  255.310428] wlp4s0: RX AssocResp from 58:8b:f3:66:30:a9 (capab=0x511 status=0 aid=105)
[  255.311686] wlp4s0: associated
[  255.311719] IPv6: ADDRCONF(NETDEV_CHANGE): wlp4s0: link becomes ready
[  259.246451] nouveau 0000:01:00.0: DRM: resuming kernel object tree...
[  259.942027] nouveau 0000:01:00.0: bus: MMIO write of 00000002 FAULT at 4188ac [ IBUS ]

mind you, I am no linux specialist. but sys specs are:
Asus N550-JV, gt750m. I am scared my video card is burned through extensive deeplearning tho. Matlab gave some really weird errors.
ubuntu version 17.04 (same errors on 16.04) 
did a full reinstall. same errors.
Do you need more info, and if so: please tell me how to get it ;)

cheers,
cory

I own an HP Envy 17 with a Geforce 750M and i'm still getting this bug as of latest stable version.

[    8.645369] nouveau: detected PR support, will not use DSM
[    8.645393] nouveau 0000:01:00.0: enabling device (0006 -> 0007)
[    8.645549] nouveau 0000:01:00.0: NVIDIA GK107 (0e7240a2)
[    8.692092] nouveau 0000:01:00.0: bios: version 80.07.b6.00.0e
[    8.779211] nouveau 0000:01:00.0: fb: 2048 MiB DDR3
[    8.779496] nouveau 0000:01:00.0: bus: MMIO write of 00000002 FAULT at 4188ac [ IBUS ]
[    8.866980] nouveau 0000:01:00.0: DRM: VRAM: 2048 MiB
[    8.866981] nouveau 0000:01:00.0: DRM: GART: 1048576 MiB
[    8.866985] nouveau 0000:01:00.0: DRM: Pointer to TMDS table invalid
[    8.866986] nouveau 0000:01:00.0: DRM: DCB version 4.0
[    8.869447] nouveau 0000:01:00.0: DRM: MM: using COPY for buffer copies
[    8.869457] [drm] Initialized nouveau 1.3.1 20120801 for 0000:01:00.0 on minor 1

I can use nouveau fine with DRI_PRIME=1 (it's very slow however). However, any attempt at reclocking the card, even at the lowest speed possible (07), results in a freeze.
However, i am unsure if this is caused by this bug or another one.
The proprietary driver works fine with this card.

Just tested it again on the same laptop with Linux 4.16.6 and Mesa 18.0.1 with latest Xorg stable version.
My Nvidia card is now working properly, even after i reclock it to 0f.
After looking at my kernel logs with dmesg, i've noticed i don't get the error anymore.
I'm so happy it finally got fixed...

I think the issue can be closed.

Nevermind, i spoke a bit too fast...
I had nouveau.runpm=0 set and that indeed fixed this MMIO write FAULT issue.
Also, i had it set before (on older kernels) and it used to do nothing.
But that's now working.

Without nouveau.runpm=0, i still get this issue.

The lockups i had were not related to that issue and it was due to the fact that i enabled NvBoost.
When NvBoost is enabled, i get the lockups. (either it set to 1 or 2 will freeze the Xorg)

I also have this issue. Dell M3800 here, Intel Core i7-4702HQ, Nvidia Quadro K1100M, Lynx Point PCH. As already stated earlier in this thread, this laptop's Nvidia GPU only provides 3D acceleration, but is neither directly connected to the screen, nor to any outputs (aka "muxless", iirc). I run Arch Linux, kernel 4.19.2.

I also get the issue:
[   21.893456] nouveau 0000:02:00.0: bus: MMIO write of 00000002 FAULT at 4188ac [ IBUS ]

This happens during boot, aswell as after resume from S3. I've noticed power usage is higher after S3 resume, since nouveau fails to power down the dGPU. It successfully powers down the GPU on first boot though. Doesn't happen with bbswitch.

I've tested kernel 4.14, where this issue doesn't happen. Nouveau successfully powers down the GPU both on first boot and on S3 resume. This seems to be a regression.

I'm not entirely sure, if this behaviour *really* is related to the nouveau error message. Please let me know, if there are any patches I can test or and debug information I can provide.

Cheers,
Tolga

I just started getting these FAULTS
Running openSUSE Tumbelweed
kernel 4.19.5-1-default

Dec 05 07:35:28 flisk kernel: nouveau 0000:01:00.0: fb: 4096 MiB GDDR5
Dec 05 07:35:28 flisk kernel: nouveau 0000:01:00.0: bus: MMIO read of 00000000 FAULT at 022554 [ IBUS ]
Dec 05 07:35:28 flisk kernel: fbcon: Taking over console
Dec 05 07:35:28 flisk kernel: nouveau 0000:01:00.0: bus: MMIO read of 00000000 FAULT at 10ac08 [ IBUS ]
Dec 05 07:35:28 flisk kernel: usb 1-4: New USB device found, idVendor=8087, idProduct=0a2b, bcdDevice= 0.10
Dec 05 07:35:28 flisk kernel: usb 1-4: New USB device strings: Mfr=0, Product=0, SerialNumber=0
Dec 05 07:35:28 flisk kernel: usb 3-1: New USB device found, idVendor=0424, idProduct=2137, bcdDevice=60.80
Dec 05 07:35:28 flisk kernel: usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Dec 05 07:35:28 flisk kernel: usb 3-1: Product: USB2137B
Dec 05 07:35:28 flisk kernel: usb 3-1: Manufacturer: SMSC
Dec 05 07:35:28 flisk kernel: hub 3-1:1.0: USB hub found
Dec 05 07:35:28 flisk kernel: hub 3-1:1.0: 7 ports detected
Dec 05 07:35:28 flisk kernel: vga_switcheroo: enabled
Dec 05 07:35:28 flisk kernel: [TTM] Zone  kernel: Available graphics memory: 16391158 kiB
Dec 05 07:35:28 flisk kernel: [TTM] Zone   dma32: Available graphics memory: 2097152 kiB
Dec 05 07:35:28 flisk kernel: [TTM] Initializing pool allocator
Dec 05 07:35:28 flisk kernel: [TTM] Initializing DMA pool allocator
Dec 05 07:35:28 flisk kernel: nouveau 0000:01:00.0: DRM: VRAM: 4096 MiB
Dec 05 07:35:28 flisk kernel: nouveau 0000:01:00.0: DRM: GART: 1048576 MiB
Dec 05 07:35:28 flisk kernel: nouveau 0000:01:00.0: DRM: Pointer to TMDS table invalid
Dec 05 07:35:28 flisk kernel: nouveau 0000:01:00.0: DRM: DCB version 4.0
Dec 05 07:35:28 flisk kernel: nouveau 0000:01:00.0: DRM: MM: using COPY for buffer copies
Dec 05 07:35:28 flisk kernel: [drm] Initialized nouveau 1.3.1 20120801 for 0000:01:00.0 on minor 1
Dec 05 07:35:28 flisk kernel: usb 2-2: new SuperSpeed Gen 1 USB device number 2 using xhci_hcd
Dec 05 07:35:28 flisk kernel: usb 4-1: new SuperSpeed Gen 1 USB device number 2 using xhci_hcd

Should I try passing the nouveau.runpm=0 to see if that helps?

(In reply to Cameron from comment #23)
> I just started getting these FAULTS
> Running openSUSE Tumbelweed
> kernel 4.19.5-1-default

Those are not the ones you should have reported here (this bug is about 4188ac and 6013d4); the one you have that matches this is the one you’ve posted on https://bugs.freedesktop.org/show_bug.cgi?id=100423#c21

> Dec 05 07:35:28 flisk kernel: nouveau 0000:01:00.0: bus: MMIO read of
> 00000000 FAULT at 022554 [ IBUS ]

This time, this is actually https://bugs.freedesktop.org/show_bug.cgi?id=100423

> Dec 05 07:35:28 flisk kernel: nouveau 0000:01:00.0: bus: MMIO read of
> 00000000 FAULT at 10ac08 [ IBUS ]

This is https://bugs.freedesktop.org/show_bug.cgi?id=104835
 
> Should I try passing the nouveau.runpm=0 to see if that helps?

No, those errors are not related to PM AFAIK.

Have it on Dell Latitude E5450

00:02.0 VGA compatible controller [0300]: Intel Corporation HD Graphics 5500 [8086:1616] (rev 09)
03:00.0 3D controller [0302]: NVIDIA Corporation GM108M [GeForce 830M] [10de:1340] (rev a2)

VERSION="18.04.1 LTS (Bionic Beaver)"
Linux bor-Latitude-E5450 4.18.0-13-generic #14~18.04.1-Ubuntu SMP Thu Dec 6 14:09:52 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

Dec 20 21:10:10 bor-Latitude-E5450 kernel: fb: switching to inteldrmfb from EFI VGA
Dec 20 21:10:10 bor-Latitude-E5450 kernel: Console: switching to colour dummy device 80x25
Dec 20 21:10:10 bor-Latitude-E5450 kernel: [drm] Replacing VGA console driver
Dec 20 21:10:10 bor-Latitude-E5450 kernel: [drm] ACPI BIOS requests an excessive sleep of 20000 ms, using 1500 ms instead
Dec 20 21:10:10 bor-Latitude-E5450 kernel: MXM: GUID detected in BIOS
Dec 20 21:10:10 bor-Latitude-E5450 kernel: ACPI Warning: \_SB.PCI0.RP05.PEGP._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20180531/nsarguments-66)
Dec 20 21:10:10 bor-Latitude-E5450 kernel: [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
Dec 20 21:10:10 bor-Latitude-E5450 kernel: [drm] Driver supports precise vblank timestamp query.
Dec 20 21:10:10 bor-Latitude-E5450 kernel: pci 0000:03:00.0: optimus capabilities: enabled, status dynamic power, hda bios codec supported
Dec 20 21:10:10 bor-Latitude-E5450 kernel: VGA switcheroo: detected Optimus DSM method \_SB_.PCI0.RP05.PEGP handle
Dec 20 21:10:10 bor-Latitude-E5450 kernel: nouveau: detected PR support, will not use DSM
Dec 20 21:10:10 bor-Latitude-E5450 kernel: nouveau 0000:03:00.0: enabling device (0006 -> 0007)
Dec 20 21:10:10 bor-Latitude-E5450 kernel: nouveau 0000:03:00.0: NVIDIA GM108 (118000a2)
Dec 20 21:10:10 bor-Latitude-E5450 kernel: i915 0000:00:02.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:owns=io+mem
Dec 20 21:10:10 bor-Latitude-E5450 kernel: [drm] Initialized i915 1.6.0 20180514 for 0000:00:02.0 on minor 0
Dec 20 21:10:10 bor-Latitude-E5450 kernel: nouveau 0000:03:00.0: bios: version 82.08.18.00.2a
Dec 20 21:10:10 bor-Latitude-E5450 kernel: ACPI: Video Device [GFX0] (multi-head: yes  rom: no  post: no)
Dec 20 21:10:10 bor-Latitude-E5450 kernel: nouveau 0000:03:00.0: fb: 2048 MiB DDR3
Dec 20 21:10:10 bor-Latitude-E5450 kernel: nouveau 0000:03:00.0: bus: MMIO read of 00000000 FAULT at 6013d4 [ IBUS ]
Dec 20 21:10:10 bor-Latitude-E5450 kernel: input: Video Bus as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input7
Dec 20 21:10:10 bor-Latitude-E5450 kernel: ACPI: Video Device [PEGP] (multi-head: no  rom: yes  post: no)
Dec 20 21:10:10 bor-Latitude-E5450 kernel: input: Video Bus as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:1d/LNXVIDEO:01/input/input8
Dec 20 21:10:10 bor-Latitude-E5450 kernel: fbcon: inteldrmfb (fb0) is primary device
Dec 20 21:10:10 bor-Latitude-E5450 kernel: Console: switching to colour frame buffer device 240x67
Dec 20 21:10:10 bor-Latitude-E5450 kernel: i915 0000:00:02.0: fb0: inteldrmfb frame buffer device
Dec 20 21:10:10 bor-Latitude-E5450 kernel: nouveau 0000:03:00.0: bus: MMIO read of 00000000 FAULT at 10ac08 [ IBUS ]
Dec 20 21:10:10 bor-Latitude-E5450 kernel: vga_switcheroo: enabled
Dec 20 21:10:10 bor-Latitude-E5450 kernel: nouveau 0000:03:00.0: DRM: GART: 1048576 MiB
Dec 20 21:10:10 bor-Latitude-E5450 kernel: nouveau 0000:03:00.0: DRM: Pointer to TMDS table invalid
Dec 20 21:10:10 bor-Latitude-E5450 kernel: nouveau 0000:03:00.0: DRM: DCB version 4.0
Dec 20 21:10:10 bor-Latitude-E5450 kernel: nouveau 0000:03:00.0: DRM: MM: using COPY for buffer copies
Dec 20 21:10:10 bor-Latitude-E5450 kernel: [drm] Initialized nouveau 1.3.1 20120801 for 0000:03:00.0 on minor 1

The read fault at 10ac08 happens only ones during system boot, read fault 6013d4 happens apparently every time I suspend/resume.

A followup to comment #22: I'm now running stable kernel 4.20.6 and no longer experience issues with power management after S3 resume. But I still get

[  318.816664] nouveau 0000:02:00.0: bus: MMIO write of 00000002 FAULT at 4188ac [ IBUS ]

Looks like they were unrelated. Not aware of any further issues.

kubuntu 19.04
ASUS K56CB-XO100H
persist
nouveau 0000:01:00.0: bus: MMIO write of 8000001f FAULT at 6013d4 [ IBUS ]
lsd@lsd-K56CB:~/q2jump/src$ lspci -nnk | grep -iA2 vga 
00:02.0 VGA compatible controller [0300]: Intel Corporation 3rd Gen Core processor Graphics Controller [8086:0166] (rev 09)
        Subsystem: ASUSTeK Computer Inc. 3rd Gen Core processor Graphics Controller [1043:1587]
        Kernel driver in use: i915
lsd@lsd-K56CB:~/q2jump/src$ inxi -Gx
Graphics:  Device-1: Intel 3rd Gen Core processor Graphics vendor: ASUSTeK driver: i915 v: kernel bus ID: 00:02.0 
           Device-2: NVIDIA GK107M [GeForce GT 740M] vendor: ASUSTeK driver: nouveau v: kernel bus ID: 01:00.0 
           Display: x11 server: X.Org 1.20.4 driver: modesetting unloaded: fbdev,vesa resolution: 1366x768~60Hz 
           OpenGL: renderer: Mesa DRI Intel Ivybridge Mobile v: 4.2 Mesa 19.0.2 direct render: Yes 
lsd@lsd-K56CB:~/q2jump/src$

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-video-nouveau/issues/292.