https://bugzilla.kernel.org/show_bug.cgi?id=207901

--- Comment #2 from Maurice Gale (mauricegale1@gmail.com) --- Created attachment 289313 --> https://bugzilla.kernel.org/attachment.cgi?id=289313&action=edit PCI Information

https://bugzilla.kernel.org/show_bug.cgi?id=207901

--- Comment #4 from Maurice Gale (mauricegale1@gmail.com) --- Created attachment 289317 --> https://bugzilla.kernel.org/attachment.cgi?id=289317&action=edit CPU Information

https://bugzilla.kernel.org/show_bug.cgi?id=207901

--- Comment #6 from Maurice Gale (mauricegale1@gmail.com) --- (In reply to Ilia Mirkin from comment #5)

Does this continue to occur on recent kernels? e.g. 5.6 or 5.7-rc?

It looks like aux port 9 is stuck somehow, not 100% sure that's something that'd have been addressed, but DP stuff definitely got improvements.

I will install install 5.7 to give that a shot, Thanks!

https://bugzilla.kernel.org/show_bug.cgi?id=207901

--- Comment #8 from Maurice Gale (mauricegale1@gmail.com) --- Created attachment 289347 --> https://bugzilla.kernel.org/attachment.cgi?id=289347&action=edit Log for 5.6

https://bugzilla.kernel.org/show_bug.cgi?id=207901

--- Comment #10 from Ilia Mirkin (imirkin@alum.mit.edu) --- It looks like you don't have firmware present, which starting with v5.6 fails the whole module load. (I believe that's a separate bug.)

Try installing linux-firmware, and making the firmware available in /lib/firmware at nouveau module load time (so if it's loaded from initrd, it needs to be in initrd).

https://bugzilla.kernel.org/show_bug.cgi?id=207901

--- Comment #12 from Maurice Gale (mauricegale1@gmail.com) --- Created attachment 289357 --> https://bugzilla.kernel.org/attachment.cgi?id=289357&action=edit Log after firmware installation

https://bugzilla.kernel.org/show_bug.cgi?id=207901

Lyude Paul (thatslyude@gmail.com) changed:

What |Removed |Added ---------------------------------------------------------------------------- CC| |thatslyude@gmail.com

--- Comment #14 from Lyude Paul (thatslyude@gmail.com) --- Hi! I was wondering if you could give this a try with the closed source nvidia driver and see if your displays work there? I mainly ask because I'm suspicious that the stuck i2c aux channel we're seeing might just be throwing some status we don't handle correctly in nouveau, and I'd also like to make sure there isn't something strange going on with the monitors here.

https://bugzilla.kernel.org/show_bug.cgi?id=207901

--- Comment #16 from Lyude Paul (lyude@redhat.com) --- (In reply to Maurice Gale from comment #15)

Hi! I have installed the closed source nvidia driver(nvidia-driver-440), and I am able to successfully get every display on every single boot.

Cool-so we at least should be able to trace the nvidia blob to figure out what's going on. Do you think you could grab an mmiotrace of the nvidia blob with all of your displays hooked up?

https://wiki.ubuntu.com/X/MMIOTracing

You might also need to add:

iomem=relaxed

To get that working. fwiw as well, that guide says somewhere to stop X afterwards before stopping the trace. That may or may not work, and it should be fine if you just leave X running when stopping the trace instead.

For submitting the mmiotrace to me, it's probably going to be somewhat large so I would recommend compressing it with xz and just sending it directly to my email.

https://bugzilla.kernel.org/show_bug.cgi?id=207901

--- Comment #18 from Maurice Gale (mauricegale1@gmail.com) --- That's awesome. Thanks!

https://bugzilla.kernel.org/show_bug.cgi?id=207901

--- Comment #20 from Maurice Gale (mauricegale1@gmail.com) --- Hi,

I tried the patch, but I am still missing two displays. I have attached the new log.

https://bugzilla.kernel.org/show_bug.cgi?id=207901

--- Comment #22 from Lyude Paul (lyude@redhat.com) --- Hi! Sorry this took me a little bit to reply to. So-it looks like we did indeed fix the i2c timeout issue that I was seeing on your board, so the next suspicious thing in your log seems to be the fact one of your DP ports (DP-7 in particular) appears to think it's being continuously hotplugged:

[ 90.996867] nouveau 0000:01:00.0: DRM: unplugged DP-7 [ 91.191704] [drm:drm_add_display_info [drm]] non_desktop set to 0 [ 91.191711] [drm:drm_add_display_info [drm]] HDMI: DVI dual 0, max TMDS clock 300000 kHz [ 91.297638] [drm:drm_dp_dpcd_access [drm_kms_helper]] Too many retries, giving up. First error: -110 [ 91.297642] [drm:drm_helper_hpd_irq_event [drm_kms_helper]] [CONNECTOR:73:DP-4] status updated from connected to connected [ 91.493173] [drm:drm_add_display_info [drm]] non_desktop set to 0 [ 91.493179] [drm:drm_add_display_info [drm]] HDMI: DVI dual 0, max TMDS clock 300000 kHz [ 91.599120] [drm:drm_dp_dpcd_access [drm_kms_helper]] Too many retries, giving up. First error: -110 [ 91.599123] [drm:drm_helper_hpd_irq_event [drm_kms_helper]] [CONNECTOR:76:DP-5] status updated from connected to connected [ 91.599335] nouveau 0000:01:00.0: DRM: display: 4x540000 dpcd 0x12 [ 91.599336] nouveau 0000:01:00.0: DRM: encoder: 4x810000 [ 91.599336] nouveau 0000:01:00.0: DRM: maximum: 4x540000 [ 91.605980] [drm:drm_add_display_info [drm]] non_desktop set to 0 [ 91.605986] [drm:drm_add_display_info [drm]] HDMI: DVI dual 0, max TMDS clock 0 kHz [ 91.606300] [drm:drm_helper_hpd_irq_event [drm_kms_helper]] [CONNECTOR:79:DP-6] status updated from connected to connected [ 91.606518] nouveau 0000:01:00.0: DRM: display: 4x540000 dpcd 0x12 [ 91.606519] nouveau 0000:01:00.0: DRM: encoder: 4x810000 [ 91.606519] nouveau 0000:01:00.0: DRM: maximum: 4x540000 [ 91.613389] [drm:drm_add_display_info [drm]] non_desktop set to 0 [ 91.613394] [drm:drm_add_display_info [drm]] HDMI: DVI dual 0, max TMDS clock 0 kHz [ 91.613722] [drm:drm_helper_hpd_irq_event [drm_kms_helper]] [CONNECTOR:82:DP-7] status updated from connected to connected [ 91.614016] nouveau 0000:01:00.0: DRM: plugged DP-7

What kind of setup do you have your monitors hooked up through? Are they on any laptop docks/standalone MST hubs, do they go through any video adaptors, what models/brands and what kind of connectors do they use, etc.

As well, do you think you can grab another log from your system but using:

log_buf_len=50M drm.debug=0x116 nouveau.debug=disp=trace

(include the full log from your boot if you can and don't trim it, since it's likely going to be a big log)

I have a feeling one of your MST devices is doing some weird out-of-spec behavior that we might need to teach nouveau to handle

https://bugzilla.kernel.org/show_bug.cgi?id=207901

--- Comment #24 from Maurice Gale (mauricegale1@gmail.com) --- Created attachment 290253 --> https://bugzilla.kernel.org/attachment.cgi?id=290253&action=edit New log with drm 116

https://bugzilla.kernel.org/show_bug.cgi?id=207901

--- Comment #26 from Maurice Gale (mauricegale1@gmail.com) --- Sorry for the delay and the mistake. It loaded the 5.3 kernel by default. I recreated the log using 5.7-rc5 with the i2c timeout patch. I also added the new grub options. The file size is much larger than the old one, so it should be correct this time.

I noticed that I have more luck getting all monitors displayed when I do not have the Display->MiniDisplay connected (Swap it out for Display->HDMI). It seems as though mini display is causing some issues.

Again, thank you so much for your help, and please let me know if you need anything else.

https://bugzilla.kernel.org/show_bug.cgi?id=207901

--- Comment #28 from Lyude Paul (lyude@redhat.com) --- (In reply to Ilia Mirkin from comment #27)

DP -> HDMI is, most likely, just passive, so the displays are being driven as HDMI rather than as DP. DP is the problematic protocol...

Hi-so, my first guess then might actually be a bad DP adapter. In my experience DP cables (usually the full-size ones, but I've had it happen with one or two passive adapters as well) have a bad habit of breaking really easily. One time I actually spent a week trying to fix a bug that'd I'd already tried troubleshooting by replacing the DP cable, only to eventually find out the cable I replaced it with also magically went bad.

Mind posting one more log with the same parameters as last time? I probably can't tell for sure but usually you'll see a lot of link training failures or timeouts when the cable has gone bad (but sometimes the symptoms are a lot more sinister...). As well, I'd also try another adapter of course.

https://bugzilla.kernel.org/show_bug.cgi?id=207901

--- Comment #30 from Lyude Paul (lyude@redhat.com) --- Hi! Sorry for the long wait, I got distracted with some other work that needed to be done. Also, sorry for making you buy that adapter since it looks like things aren't working still. So I took a look at the logs that you gave me and noticed some interesting things that didn't catch my eye before. In the last log you gave me with the new DP adapter I can't see nouveau noticing any of the monitors. On the log before that though, I actually see it detect all four monitors. I also see it actually turn all four on successfully, huh.

The other thing I noticed is that it looks like you're using the nouveau DDX in your X config. That makes me wonder, do the screens come up -at all- during the boot process before the GUI comes up? As well, have you tried the modesetting DDX to see if that makes any difference, or perhaps wayland?