Tried updating my developer box to Linux LTS 6.6.2 last week, and it looks like I cannot get the nouveau driver included in that series to work with a low-end MSI GeForce GT 710 2GB GPU in the system, specifically for a console. The system does not have X11 installed, and I CAN get a standard VESA/VGA console up in 640x480 mode, but it never switches over to the higher-res 1280x1024 resolution specified in my bootloader config. FWIW, this system was built three years ago (2020) and has used the same GPU for LTS kernels 5.4, 5.10, 5.15, and 6.1 w/o issue. As far as I can tell, it isn't probing the connector ports correctly and thus, can't read EDID information. Given this for loop: > for x in $(find /sys -name card0-\* -type d | sort); do echo "${x##*/}: $(cat ${x}/status)"; done This is what it shows for the working kernel (6.1.63) and impacted kernel (6.6.2(: > 6.1.63 > card0-DVI-D-1: disconnected > card0-HDMI-A-1: disconnected > card0-VGA-1: connected > > 6.6.2 > card0-DVI-D-1: disconnected > card0-HDMI-A-1: disconnected > card0-VGA-1: disconnected VGA-1 is what a monitor is plugged into, and that is detected correctly on 6.1.63, and I get the higher resolution and SMP penguins. Under 6.6.2, the display does work, just at the classic VGA 640x480 resolution. No higher resolution, and no SMP penguins at the top. Kernel command line passed by the bootloader: > console=tty0 video=VGA-1:1280x1024-32@75m consoleblank=0 root=ZFS Working dmesg (6.1.63), grep "nouveau": > nouveau 0000:07:00.0: DRM: VRAM: 2048 MiB > nouveau 0000:07:00.0: DRM: GART: 1048576 MiB > nouveau 0000:07:00.0: DRM: TMDS table version 2.0 > nouveau 0000:07:00.0: DRM: DCB version 4.0 > nouveau 0000:07:00.0: DRM: DCB outp 00: 01000f02 00020030 > nouveau 0000:07:00.0: DRM: DCB outp 01: 02011f62 00020010 > nouveau 0000:07:00.0: DRM: DCB outp 02: 02022f10 00000000 > nouveau 0000:07:00.0: DRM: DCB conn 00: 00001031 > nouveau 0000:07:00.0: DRM: DCB conn 01: 00002161 > nouveau 0000:07:00.0: DRM: DCB conn 02: 00000200 > nouveau 0000:07:00.0: DRM: MM: using COPY for buffer copies > nouveau 0000:07:00.0: DRM: [DRM/00000002:dac-0000-0f02] [LOAD_DETECT data:00000154] load:07 (ret:7) > nouveau 0000:07:00.0: DRM: allocated 1280x1024 fb: 0x80000, bo 000000005f8a6586 > nouveau 0000:07:00.0: DRM: [DRM/00000002:dac-0000-0f02] [LOAD_DETECT data:00000154] load:07 (ret:7) > nouveau 0000:07:00.0: DRM: [DRM/00000002:dac-0000-0f02] [LOAD_DETECT data:00000154] load:07 (ret:7) > nouveau 0000:07:00.0: [drm] fb0: nouveaudrmfb frame buffer device Non-working dmesg (6.6.2), grep "nouveau": > nouveau 0000:07:00.0: DRM: VRAM: 2048 MiB > nouveau 0000:07:00.0: DRM: GART: 1048576 MiB > nouveau 0000:07:00.0: DRM: TMDS table version 2.0 > nouveau 0000:07:00.0: DRM: DCB version 4.0 > nouveau 0000:07:00.0: DRM: DCB outp 00: 01000f02 00020030 > nouveau 0000:07:00.0: DRM: DCB outp 01: 02011f62 00020010 > nouveau 0000:07:00.0: DRM: DCB outp 02: 02022f10 00000000 > nouveau 0000:07:00.0: DRM: DCB conn 00: 00001031 > nouveau 0000:07:00.0: DRM: DCB conn 01: 00002161 > nouveau 0000:07:00.0: DRM: DCB conn 02: 00000200 > nouveau 0000:07:00.0: DRM: MM: using COPY for buffer copies > nouveau 0000:07:00.0: DRM: [DRM/00000002:dac-0000-0f02] [LOAD_DETECT data:00000154] load:07 (ret:-5) > nouveau 0000:07:00.0: [drm] Cannot find any crtc or sizes > nouveau 0000:07:00.0: DRM: [DRM/00000002:dac-0000-0f02] [LOAD_DETECT data:00000154] load:07 (ret:-5) > nouveau 0000:07:00.0: [drm] Cannot find any crtc or sizes > nouveau 0000:07:00.0: DRM: [DRM/00000002:dac-0000-0f02] [LOAD_DETECT data:00000154] load:07 (ret:-5) > nouveau 0000:07:00.0: [drm] Cannot find any crtc or sizes > nouveau 0000:07:00.0: DRM: [DRM/00000002:dac-0000-0f02] [LOAD_DETECT data:00000154] load:07 (ret:-5) > nouveau 0000:07:00.0: [drm] Cannot find any crtc or sizes > nouveau 0000:07:00.0: DRM: [DRM/00000002:dac-0000-0f02] [LOAD_DETECT data:00000154] load:07 (ret:-5) > nouveau 0000:07:00.0: [drm] Cannot find any crtc or sizes Cranking up the debug output under 6.6.2, I can see that the kernel can pull other information off of the card, including fan status and GPU temperature, so it's definitely able to talk to and access the card. Not sure where else to poke, though.
Can you please attach the full dmesg ?
Anything like shown here ? https://gitlab.freedesktop.org/drm/nouveau/-/issues/282
The dmesg snippets I included were the only relevant changed bits between 6.1.63 and 6.6.2. Checked them w/ diff to make sure, after normalizing the dmesg output to get a clean comparison. No BUG() or WARN() output like in your link, unfortunately. If that were the case, I'd have at least had some code to dive into. Chief difference is in 6.6.2 where it starts saying "[drm] Cannot find any crtc or sizes", whereas in 6.1.63, in place of that line, it correctly probes the attached monitor. Which is actually a Cybex Secure KVM, and I don't *think* that allows EDID to transfer over, but I've had that KVM attached to this dev box for 3+ years, and my previous dev box for 5+ years, and the console worked fine the entire time. Both using nVidia cards and nouveau, so I'm leaning towards that not being the problem. The monitor that's attached to the KVM is a Westinghouse LCM 19v1 SL -- LCD 19" 4:3, that I got from an old job almost 15 years ago. Supports 1280x1024 @ 32bpp, attached via VGA. It's only ever turned on if I need to access the console for something, otherwise it stays off. Also tried 6.6.3, and no change. Currently running 6.1.64. I've googled the daylights out of that "Cannot find any crtc or sizes" error, but most of the hits have to do w/ X11, and this machine doesn't have X11 installed, so no dice. I gave up when Google started throwing captchas at me.
bisect time?
(In reply to Mike Pagano from comment #4) > bisect time? Hoping to avoid that...I only run the LTS kernels lately, so am jumping from 6.1 to 6.6. Bisecting that wide of a version range would not be a lot of fun. I figure, if I wait around long enough, maybe upstream will find and fix the bug on their own, since we're pretty early in the 6.6.x cycle. Hence I am going to be keeping an eye on the git changelogs w/ each new 6.6.x release for the next few weeks to see if anything pops up that may be a cause. My other option is I dig in some boxes and see if I can find an old amdgpu or radeon card to use instead (all the newer ones are double PCI slot, which won't fit in this particular build). Everything else w/ 6.6 seems to work fine, so it's not a show-stopping issue or anything. I just wanted to get a bug opened on it in case anyone else runs into it. At the very worst, I just learn to live with it. I'll probably be rebuilding that box sometime next year anyways, since it's coming up on ~4 years of age. Probably just go w/ a Ryzen w/ integrated GPU next time, like my NAS server has.
Alright, it looks like the problem is because my secure KVM does not allow EDID info to pass through. I connected a VGA cable from my dev box directly to the monitor, and under 6.6.4, nouveau inits correctly and it switches to the drmfb driver, so high-res output and SMP penguins. If I go through the KVM, I get classic 640x480 VGA and no SMP penguins. My guess is that sometime between 6.1 and 6.6, either drm or nouveau was changed to regard lack of EDID info as implying that there is no output device attached. I've also, for the past few years, been supplying "video=VGA-1:1280x1024-32@75m" to the kernel via my bootloader (lilo), and it looks like with 6.6, that parameter is completely ignored if the driver doesn't get any EDID data from a monitor or other such output device. As a workaround, adding the 'e' flag to that modestring to force the output connector to be enabled at the specified resolution works. So now it reads "video=VGA-1:1280x1024-32@75me". So yeah, definitely a bug, cause relying on the presence of EDID to determine if an output connector is actually connected to something is not 100% reliable. Especially if you're connecting through a secure KVM that doesn't wire those VGA pins up. That said, it's a pretty minor bug in the grand scheme of things. Easily fixed on my end by updating my bootloader configuration. The kernel should, if it gets a modestring passed in via "video=", attempt to set the specified mode parameters, regardless if it gets any EDID data sent to it or not. If I get bored, I may go and dig further to see if I can find a commit that changed the original behavior that's worked fine across the last five-plus years of kernels, then complain upstream. Up to you all if you'd like to keep this open, otherwise, I'll close with RESOLVED::WONTFIX, since it's nothing in Gentoo proper causing the breakage. If I stumble across any explanation from upstream or related commits, I'll add them regardless if the bug is open or closed, so that if someone else ever runs into this, maybe it'll save them some headaches.
I think were safe to close this one. Thanks.
