Bug 1896904

@dober - collect xrandr output
grep . /sys/class/drm/*/enabled

I was able to reproduce this on the P15 as well. 
I'll attach two logs - one with xrandr and /sys/class/drm output for the USB-C into a thunderbolt port case and one where HDMI was used.

Created attachment 1730641 [details]
debug info when USB-C monitor cable connected to P15 TBT port

Created attachment 1730642 [details]
debug information when HDMI connection used

Yeah, not surprising.

grep . /sys/class/drm/*/enabled
/sys/class/drm/card0-eDP-1/enabled:enabled
/sys/class/drm/card1-DP-1/enabled:disabled
/sys/class/drm/card1-eDP-2/enabled:disabled
/sys/class/drm/card1-eDP-3/enabled:disabled
/sys/class/drm/card1-eDP-4/enabled:enabled
/sys/class/drm/card1-HDMI-A-1/enabled:disabled

On HDMI, it is clear, but here the external display is on card1-eDP-4 where eDP is embedded DisplayPort (i.e. for internal displays).

So, I think this is a nouveau kernel driver issue. CC'ing Karol.

Can you post the kernel log from loading nouveau on this system please?

Created attachment 1733389 [details]
Dmesg log from P15

dmesg-p15 attachment goes with the P15 system showing this issue:

[root@localhost banther]# grep . /sys/class/drm/*/enabled
/sys/class/drm/card0-eDP-1/enabled:enabled
/sys/class/drm/card1-DP-1/enabled:disabled
/sys/class/drm/card1-eDP-2/enabled:disabled
/sys/class/drm/card1-eDP-3/enabled:disabled
/sys/class/drm/card1-eDP-4/enabled:enabled
/sys/class/drm/card1-HDMI-A-1/enabled:disabled

Let me know if there is anything else useful I can collect or try
Thanks
Mark

(In reply to Mark Pearson from comment #7)
> Created attachment 1733389 [details]
> Dmesg log from P15

the

> [    2.962909] nouveau 0000:01:00.0: DRM: unknown connector type 48
> [    2.962942] nouveau 0000:01:00.0: DRM: unknown connector type 48
> [    2.962976] nouveau 0000:01:00.0: DRM: unknown connector type 48

stands out. And checking with the docs we got from Nvidia 48 is "0x48 = DisplayPort (Mini) External Connector" which seems to match here.

Ben I assume you already know where and what to fix? Otherwise I can probably also came up with a patch and build to test.

Created attachment 1733873 [details]
test.patch

no idea if this just works, but something along those lines is what we need. I suspect there might be more we have to change.. maybe not.

Can anybody with an affected machine give it a try? I don't think any of my laptops have this issue.

*** Bug 1902079 has been marked as a duplicate of this bug. ***

Created attachment 1733988 [details]
display settings looking good

Created attachment 1733989 [details]
dmesg log with succesful and unsuccessful monitor attach

Hi Karol,

I tried out the patch - I think it likely cures the issue, unfortunately I did see something else but my suspicion is it's a different problem.

The good bit first: The monitor is correctly detected (see the .png) and I was able to remove and reattach and the display continued to work. You should see this event in the dmesg log.

Unfortunately on the 2nd remove/attach I got a nouveau timeout and then everything stops working. I think it might be a separate issue as I also saw this issue on the first boot with no monitor attached. Let me know if you want a separate bug or any debug information to help with that.

Thanks for the patch - definitely a big step forward

mark

(In reply to Mark Pearson from comment #13)
> Created attachment 1733989 [details]
> dmesg log with succesful and unsuccessful monitor attach

huh, it seems like that this is with a stock fedora kernel.

And I still see the 

> [    2.269719] nouveau 0000:01:00.0: DRM: unknown connector type 48
> [    2.269786] nouveau 0000:01:00.0: DRM: unknown connector type 48
> [    2.269824] nouveau 0000:01:00.0: DRM: unknown connector type 48

messages.

Are you sure you compiled the kernel with the patch and booted into the correct one?

Created attachment 1734132 [details]
dmesg log

Sorry - perils of doing things late at night. Somehow I either collected or uploaded the wrong log. This version should be correct

It should show booting succesfully, and the first remove/insert working. The second remove/insert gives a timeout and everything stops working after.

Apologies for the goof. Let me know if you need anything else
Mark

(In reply to Mark Pearson from comment #16)
> Created attachment 1734132 [details]
> dmesg log
> 
> Sorry - perils of doing things late at night. Somehow I either collected or
> uploaded the wrong log. This version should be correct
> 
> It should show booting succesfully, and the first remove/insert working. The
> second remove/insert gives a timeout and everything stops working after.
> 
> Apologies for the goof. Let me know if you need anything else
> Mark

it looks like something goes wrong in the device suspend path with the firmware unloading. I'd assume that booting with nouveau.runpm=0 would workaround the issue. Mind checking that?

Thanks.

No problems. using nouveau.runpm=0 is good as a workaround - tried a bunch of times and it worked beautifully. I assume that kills power management though :)
Mark

(In reply to Mark Pearson from comment #18)
> No problems. using nouveau.runpm=0 is good as a workaround - tried a bunch
> of times and it worked beautifully. I assume that kills power management
> though :)
> Mark

glad to hear. Yeah, although it's not really a power management issue, but related to the firmware we load to the GPU. I don't think I've encountered that issue yet on my own. Any idea if other laptops are affected by the same problem?

Anyway, will send out the patch so we can get at least the display stuff fixed. Do you mind if I add your Tested-by: Tag?

Ben, are you aware of any GPUs with that gr unloading issue?

I'll have to check on the other laptops - I don't think it was reported on the P1G3 which has just completed it's run through test with Fedora (my P1G3 doesn't have an Nvidia card to confirm with). My guess is it will show up on the P17 as well, but I'm just guessing and we don't have a Fedora release there so it might get missed. I'll do some double checking and of course holler if there are things we can try.
As a note - I just suspend/resumed this and saw the issue come back (I'll upload a new dmesg, but it looks like the same trace) so the nouveau.rpm=0 isn't a full workaround either :(

No problem on the Tested-by tag (please use markpearson - it's my open source friendly email account)

Mark

Created attachment 1734180 [details]
dmesg after suspend/resume with nouveau.runpm=0

(In reply to Mark Pearson from comment #20)
> I'll have to check on the other laptops - I don't think it was reported on
> the P1G3 which has just completed it's run through test with Fedora (my P1G3
> doesn't have an Nvidia card to confirm with). My guess is it will show up on
> the P17 as well, but I'm just guessing and we don't have a Fedora release
> there so it might get missed. I'll do some double checking and of course
> holler if there are things we can try.
> As a note - I just suspend/resumed this and saw the issue come back (I'll
> upload a new dmesg, but it looks like the same trace) so the nouveau.rpm=0
> isn't a full workaround either :(
> 

yeah, not surprised by that. Mind opening a new bug for that, so we can close this one once the fixes land for the eDP vs mDP issue? Thanks.

> No problem on the Tested-by tag (please use markpearson - it's my
> open source friendly email account)
> 
> Mark

clearing my need info flag as Mark has provided it

I created https://bugzilla.redhat.com/show_bug.cgi?id=1902798 to track the timeout issue.
Thanks
Mark

I think we can close this bug now, no?

Yes. Moving to verified - I assume you close it? Or do I?

yeah, I think I just close it then :) Bug was fixed inside kernel 5.10.20 and 5.11.3, and Fedora 33 shipped 5.10.20 and later 5.11.7.