Created attachment 104148 [details] When the DP screen doesn't light up Hey Ben, Oddly-enough, my DP screen at work does not want to light up after a cold boot but works if I reboot right away. As I told you before, this screen is weird when it comes to coming back from sleep mode. The DVI screen lights up correctly but I doubt this issue is related to dual screen because I tried unplugging the DVI screen a while ago to investigate the resume issue and it didn't help. I attached to the bug the kernel logs with nouveau.debug="PDISP=trace,I2C=trace,VBIOS=trace" for both the case when the screen doesn't light up and when it does.
Created attachment 104149 [details] When the screen does come up
My work around: turn off and on again the screen before nouveau loads. That does the trick to force the screen out of the sleep mode before the modeset.
This bug may not be limited to DP. A friend of mine has the same problem with his laptop's panel... I couldn't get traces yet, but just wanted to let you know that it may be a broader problem.
Oh, and funnily-enough, this may be a problem with the nva8 since my friend also has one of those in his laptop.
Bad case: [ +0,000009] nouveau D[ I2C][0000:01:00.0] PAD:S:01: -> PORT:0b [ +0,000002] nouveau D[ I2C][0000:01:00.0] AUXCH(1): 9: 0x00000000 16 [ +0,000563] nouveau D[ I2C][0000:01:00.0] AUXCH(1): 00 0x0110900f 0x10000010 [ +0,000002] nouveau D[ I2C][0000:01:00.0] AUXCH(1): rd 0x01010101 [ +0,000002] nouveau D[ I2C][0000:01:00.0] AUXCH(1): rd 0x01010101 [ +0,000002] nouveau D[ I2C][0000:01:00.0] AUXCH(1): rd 0x01010101 [ +0,000002] nouveau D[ I2C][0000:01:00.0] AUXCH(1): rd 0x01010101 [ +0,000003] nouveau D[ PDISP][0000:01:00.0] 02:0006:0344: aux power -> always [ +0,000002] nouveau D[ I2C][0000:01:00.0] AUXCH(1): 9: 0x00000100 2 [ +0,000144] nouveau D[ I2C][0000:01:00.0] AUXCH(1): 00 0x01109001 0x10000002 [ +0,000002] nouveau D[ I2C][0000:01:00.0] AUXCH(1): rd 0x0101840a [ +0,000003] nouveau D[ I2C][0000:01:00.0] AUXCH(1): rd 0x01010101 [ +0,000002] nouveau D[ I2C][0000:01:00.0] AUXCH(1): rd 0x01010101 [ +0,000012] nouveau D[ I2C][0000:01:00.0] AUXCH(1): rd 0x01010101 [ +0,000003] nouveau D[ I2C][0000:01:00.0] AUXCH(1): 9: 0x00000202 3 [ +0,000154] nouveau D[ I2C][0000:01:00.0] AUXCH(1): 00 0x01109002 0x10000003 [ +0,000002] nouveau D[ I2C][0000:01:00.0] AUXCH(1): rd 0x01800000 [ +0,000002] nouveau D[ I2C][0000:01:00.0] AUXCH(1): rd 0x01010101 [ +0,000003] nouveau D[ I2C][0000:01:00.0] AUXCH(1): rd 0x01010101 [ +0,000002] nouveau D[ I2C][0000:01:00.0] AUXCH(1): rd 0x01010101 Good case: [ +0,000009] nouveau D[ I2C][0000:01:00.0] PAD:S:01: -> PORT:0b [ +0,000002] nouveau D[ I2C][0000:01:00.0] AUXCH(1): 9: 0x00000000 16 [ +0,000258] nouveau D[ I2C][0000:01:00.0] AUXCH(1): 00 0x0110900f 0x10000010 [ +0,000002] nouveau D[ I2C][0000:01:00.0] AUXCH(1): rd 0x01840a11 [ +0,000002] nouveau D[ I2C][0000:01:00.0] AUXCH(1): rd 0x00010000 [ +0,000002] nouveau D[ I2C][0000:01:00.0] AUXCH(1): rd 0x00060202 [ +0,000002] nouveau D[ I2C][0000:01:00.0] AUXCH(1): rd 0x00000000 [ +0,000003] nouveau D[ PDISP][0000:01:00.0] 02:0006:0344: aux power -> always [ +0,000002] nouveau D[ I2C][0000:01:00.0] AUXCH(1): 9: 0x00000100 2 [ +0,000144] nouveau D[ I2C][0000:01:00.0] AUXCH(1): 00 0x01109001 0x10000002 [ +0,000003] nouveau D[ I2C][0000:01:00.0] AUXCH(1): rd 0x0184840a [ +0,000002] nouveau D[ I2C][0000:01:00.0] AUXCH(1): rd 0x00010000 [ +0,000002] nouveau D[ I2C][0000:01:00.0] AUXCH(1): rd 0x00060202 [ +0,000002] nouveau D[ I2C][0000:01:00.0] AUXCH(1): rd 0x00000000 [ +0,000002] nouveau D[ I2C][0000:01:00.0] AUXCH(1): 9: 0x00000202 3 [ +0,000152] nouveau D[ I2C][0000:01:00.0] AUXCH(1): 00 0x01109002 0x10000003 [ +0,000003] nouveau D[ I2C][0000:01:00.0] AUXCH(1): rd 0x01800000 [ +0,000002] nouveau D[ I2C][0000:01:00.0] AUXCH(1): rd 0x00010000 [ +0,000002] nouveau D[ I2C][0000:01:00.0] AUXCH(1): rd 0x00060202 [ +0,000002] nouveau D[ I2C][0000:01:00.0] AUXCH(1): rd 0x00000000 Those 01010101's seem unhealthy... And then later, the bad case has [ +0,000002] nouveau D[ PDISP][0000:01:00.0] 02:0006:0344: 0 lanes at 0 KB/s ... [ +0,000002] nouveau E[ PDISP][0000:01:00.0] 02:0006:0344: link training failed And then later when it tries to train again with 0 lanes one or two more times, and the training actually succeeds but it says there's not enough bw. And then the last time everything works. I think the number of lanes is being computed based on some sort of stale value, I wonder if that's affecting things.
-- 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/126.
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.