Bug 98386 - [NVE7] bus: MMIO write of FAULT at [ IBUS ], Pointer to {TDMS,flat panel} table invalid
Summary: [NVE7] bus: MMIO write of FAULT at [ IBUS ], Pointer to {TDMS,flat panel} tab...
Status: REOPENED
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/nouveau (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: high major
Assignee: Nouveau Project
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-10-22 16:32 UTC by Bruno Pagani
Modified: 2018-12-05 15:35 UTC (History)
4 users (show)

See Also:
i915 platform:
i915 features:


Attachments
dmesg output (75.86 KB, text/plain)
2017-03-27 17:21 UTC, Bob Bugzilla
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Bruno Pagani 2016-10-22 16:32:51 UTC
Hi, following https://bugzilla.freedesktop.org/show_bug.cgi?id=70354, I’m still having some error messages in dmesg.

This is on first loading:
[  454.756165] MXM: GUID detected in BIOS
[  454.756253] ACPI Warning: \_SB.PCI0.PEG0.PEGP._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20160422/nsarguments-95)
[  454.756309] ACPI Warning: \_SB.PCI0.PEG0.PEGP._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20160422/nsarguments-95)
[  454.756430] pci 0000:02:00.0: optimus capabilities: enabled, status dynamic power, hda bios codec supported
[  454.756432] VGA switcheroo: detected Optimus DSM method \_SB_.PCI0.PEG0.PEGP handle
[  454.756433] nouveau: detected PR support, will not use DSM
[  454.756510] nouveau 0000:02:00.0: NVIDIA GK107 (0e7240a2)
[  454.775702] nouveau 0000:02:00.0: bios: version 80.07.b3.00.21
[  454.919182] nouveau 0000:02:00.0: fb: 2048 MiB GDDR5
[  454.919271] nouveau 0000:02:00.0: bus: MMIO write of 00000002 FAULT at 4188ac [ IBUS ]
[  454.989821] vga_switcheroo: enabled
[  454.989938] [TTM] Zone  kernel: Available graphics memory: 8169036 kiB
[  454.989939] [TTM] Zone   dma32: Available graphics memory: 2097152 kiB
[  454.989940] [TTM] Initializing pool allocator
[  454.989943] [TTM] Initializing DMA pool allocator
[  454.989951] nouveau 0000:02:00.0: DRM: VRAM: 2048 MiB
[  454.989951] nouveau 0000:02:00.0: DRM: GART: 1048576 MiB
[  454.989954] nouveau 0000:02:00.0: DRM: Pointer to TMDS table invalid
[  454.989956] nouveau 0000:02:00.0: DRM: DCB version 4.0
[  454.989957] nouveau 0000:02:00.0: DRM: Pointer to flat panel table invalid
[  455.191639] nouveau 0000:02:00.0: DRM: MM: using COPY for buffer copies
[  455.191647] [drm] Initialized nouveau 1.3.1 20120801 for 0000:02:00.0 on minor 1
[  460.192102] nouveau 0000:02:00.0: DRM: evicting buffers...
[  460.192107] nouveau 0000:02:00.0: DRM: waiting for kernel channels to go idle...
[  460.192139] nouveau 0000:02:00.0: DRM: suspending client object trees...
[  460.198135] nouveau 0000:02:00.0: DRM: suspending kernel object tree...

Note the following lines (that appear in red in my console):
[  454.919271] nouveau 0000:02:00.0: bus: MMIO write of 00000002 FAULT at 4188ac [ IBUS ]
[  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

And then, on subsequent uses of the card:
[  470.170765] nouveau 0000:02:00.0: DRM: resuming kernel object tree...
[  470.245180] nouveau 0000:02:00.0: bus: MMIO write of ffffff1f FAULT at 6013d4 [ IBUS ]
[  470.266559] nouveau 0000:02:00.0: DRM: resuming client object trees...
[  476.071701] nouveau 0000:02:00.0: DRM: evicting buffers...
[  476.071703] nouveau 0000:02:00.0: DRM: waiting for kernel channels to go idle...
[  476.071732] nouveau 0000:02:00.0: DRM: suspending client object trees...
[  476.077132] nouveau 0000:02:00.0: DRM: suspending kernel object tree...

And again (can provide any amount you want, only the two hex chains change):
[ 6579.503383] nouveau 0000:02:00.0: DRM: resuming kernel object tree...
[ 6579.586496] nouveau 0000:02:00.0: bus: MMIO write of 8000001f FAULT at 6013d4 [ IBUS ]
[ 6579.607798] nouveau 0000:02:00.0: DRM: resuming client object trees...
[ 6585.210796] nouveau 0000:02:00.0: DRM: evicting buffers...
[ 6585.210798] nouveau 0000:02:00.0: DRM: waiting for kernel channels to go idle...
[ 6585.210825] nouveau 0000:02:00.0: DRM: suspending client object trees...
[ 6585.216211] nouveau 0000:02:00.0: DRM: suspending kernel object tree...

Not sure if it has any consequences, but since it appears in red, I supposed it was worth reporting.
Comment 1 Ilia Mirkin 2016-10-22 16:42:56 UTC
(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.
Comment 2 Bruno Pagani 2016-10-22 16:53:37 UTC
(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. ;)
Comment 3 Bruno Pagani 2016-10-22 18:27:15 UTC
This one:

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

also appears when resuming from suspend.
Comment 4 Bob Bugzilla 2017-03-27 17:19:28 UTC
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.
Comment 5 Bob Bugzilla 2017-03-27 17:21:53 UTC
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...
Comment 6 Bob Bugzilla 2017-03-27 17:25:22 UTC
Benchmark test: "export vblank_mode=0; glxgears"

Normally get 12,000 FPS.

With this bug, 1,000 FPS.
Comment 7 Ilia Mirkin 2017-03-27 17:27:57 UTC
(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.
Comment 8 Bob Bugzilla 2017-03-27 17:45:37 UTC
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).
Comment 9 Ilia Mirkin 2017-03-27 18:24:10 UTC
(In reply to Bob Bugzilla from comment #8)
> on the Intel chip (which hands 3D requests back to the nvidia chip).

Aka "PRIME".
Comment 10 Bruno Pagani 2017-03-27 20:36:34 UTC
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.
Comment 11 Ilia Mirkin 2017-03-27 20:39:55 UTC
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.
Comment 12 Bruno Pagani 2017-03-27 20:44:01 UTC
(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…
Comment 13 Bob Bugzilla 2017-03-27 20:48:09 UTC
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.
Comment 14 Bob Bugzilla 2017-03-27 20:54:28 UTC
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.
Comment 15 Bruno Pagani 2017-03-27 23:12:50 UTC
@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…
Comment 16 Bob Bugzilla 2017-03-28 15:46:07 UTC
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?
Comment 17 Bruno Pagani 2017-03-28 21:28:21 UTC
(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.
Comment 18 coristus 2017-05-10 23:12:53 UTC
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
Comment 19 baybay 2018-03-09 18:51:31 UTC
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.
Comment 20 baybay 2018-05-01 19:51:53 UTC
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.
Comment 21 baybay 2018-05-01 20:16:51 UTC
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)
Comment 22 Tolga Cakir 2018-11-21 18:20:46 UTC
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
Comment 23 Cameron 2018-12-05 15:21:23 UTC
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?
Comment 24 Bruno Pagani 2018-12-05 15:35:00 UTC
(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.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.