Bug#991941: linux: Don't use nouveau with Nvidia GeForce 8500 GT or alert in dmesg that firmware is needed
Hello again El 10 de agosto de 2021 2:56:01 CEST, Ben Hutchings escribió: >Control: tag -1 moreinfo > >On Fri, 2021-08-06 at 12:03 +0200, Laura Arjona Reina wrote: >> Source: linux >> Severity: normal >> >> Dear Maintainer, >> >> *** Reporter, please consider answering these questions, where >> appropriate *** >> >> * What led up to the situation? >> >> I have installed Debian 11 (debian installer RC3) on a PC having a >> Nvidia GeForce 8500 GT as main graphics card. >> The graphicall install process went well. After finishing the >> installation and reboot, I got a blank screen and "Input not supported" >> on my monitor. >> I changed to tty2 and logged in, and saved the dmesg output (attached), >> I noticed that "nouveau" driver was loaded but there was no info about >> my card not supported or needing additional firmware. > >The missing firmware should have been fixed in installer RC3 *if* you >use an installer image that includes firmware, but not if you use the >default images. Which did you use? > I used the official image without firmware but was expecting that using isenkram-autoinstall-firmware afterwards was equivalent. >On the kernel side we should try to fix the blank screen with an >earlier check for firmware in nouveau, similarly to the way we patch >the amdgpu and radeon drivers. (Although those patches now seem not to >be completely effective.) > >> * What exactly did you do (or not do) that was effective (or >> ineffective)? >> >> I have rebooted and edited the "linux" line during Grub menu, to add >> "nomodeset" and then I could have a fallback graphics mode. >> I have installed the isenkram-cli package and ran >> isenkram-autoinstall-firmware as suggested in the release notes and it >> installed firmware for my realtek card (unrelated) and >> firmware-misc-nonfree, but rebooting makes Linux pick the nouveau driver >> again. >[...] > >Well that's expected. The kernel driver and firmware are two different >things that work together. Installing the firmware should allow >nouveau to work properly. > >Are you saying that even with firmware-misc-nonfree installed, you >still get a black screen when you don't use "nomodeset"? > Exactly. At the end of August or beginning of September I can do an install using the image with firmware but I'll suspect that the results will be the same, because the needed firmware is not in Debian non-free either (card not supported in Bullseye). I think that nouveau should somehow output that message (card not supported) so the user gets a hint about what's happening. Kind regards -- Laura Arjona Reina https://wiki.debian.org/LauraArjona Sent with K-9 mail
Bug#991941: attaching dmesg and lspci output
I'm attaching the dmesg and lspci output for the case they are useful. Kind regards -- Laura Arjona Reina https://wiki.debian.org/LauraArjona Sent with K-9 mail[0.00] Linux version 5.10.0-8-amd64 (debian-kernel@lists.debian.org) (gcc-10 (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP Debian 5.10.46-3 (2021-07-28) [0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-5.10.0-8-amd64 root=UUID=02117186-1520-493e-b434-e6e4c856a515 ro quiet [0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers' [0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers' [0.00] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers' [0.00] x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256 [0.00] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'standard' format. [0.00] BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0009d7ff] usable [0.00] BIOS-e820: [mem 0x0009d800-0x0009] reserved [0.00] BIOS-e820: [mem 0x000e-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0xb9aa1fff] usable [0.00] BIOS-e820: [mem 0xb9aa2000-0xb9aa8fff] ACPI NVS [0.00] BIOS-e820: [mem 0xb9aa9000-0xba2d7fff] usable [0.00] BIOS-e820: [mem 0xba2d8000-0xba4f3fff] reserved [0.00] BIOS-e820: [mem 0xba4f4000-0xca8befff] usable [0.00] BIOS-e820: [mem 0xca8bf000-0xca956fff] reserved [0.00] BIOS-e820: [mem 0xca957000-0xca993fff] usable [0.00] BIOS-e820: [mem 0xca994000-0xcaa56fff] ACPI NVS [0.00] BIOS-e820: [mem 0xcaa57000-0xcaffefff] reserved [0.00] BIOS-e820: [mem 0xcafff000-0xcaff] usable [0.00] BIOS-e820: [mem 0xcb80-0xcf9f] reserved [0.00] BIOS-e820: [mem 0xf800-0xfbff] reserved [0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved [0.00] BIOS-e820: [mem 0xfed0-0xfed03fff] reserved [0.00] BIOS-e820: [mem 0xfed1c000-0xfed1] reserved [0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved [0.00] BIOS-e820: [mem 0xff00-0x] reserved [0.00] BIOS-e820: [mem 0x0001-0x00012f5f] usable [0.00] NX (Execute Disable) protection: active [0.00] SMBIOS 2.7 present. [0.00] DMI: Gigabyte Technology Co., Ltd. H81M-S1/H81M-S1, BIOS FH 08/10/2015 [0.00] tsc: Fast TSC calibration using PIT [0.00] tsc: Detected 3392.039 MHz processor [0.000461] e820: update [mem 0x-0x0fff] usable ==> reserved [0.000464] e820: remove [mem 0x000a-0x000f] usable [0.000469] last_pfn = 0x12f600 max_arch_pfn = 0x4 [0.000472] MTRR default type: uncachable [0.000473] MTRR fixed ranges enabled: [0.000474] 0-9 write-back [0.000475] A-B uncachable [0.000475] C-C write-protect [0.000476] D-E7FFF uncachable [0.000477] E8000-F write-protect [0.000477] MTRR variable ranges enabled: [0.000478] 0 base 00 mask 7F write-back [0.000479] 1 base 01 mask 7FE000 write-back [0.000480] 2 base 012000 mask 7FF000 write-back [0.000481] 3 base 00E000 mask 7FE000 uncachable [0.000481] 4 base 00D000 mask 7FF000 uncachable [0.000482] 5 base 00CC00 mask 7FFC00 uncachable [0.000483] 6 base 00CB80 mask 7FFF80 uncachable [0.000483] 7 base 012F80 mask 7FFF80 uncachable [0.000484] 8 base 012F60 mask 7FFFE0 uncachable [0.000485] 9 disabled [0.000746] x86/PAT: Configuration [0-7]: WB WC UC- UC WB WP UC- WT [0.000947] e820: update [mem 0xcb80-0x] usable ==> reserved [0.000952] last_pfn = 0xcb000 max_arch_pfn = 0x4 [0.006871] found SMP MP-table at [mem 0x000fd6c0-0x000fd6cf] [0.013870] Using GB pages for direct mapping [0.014409] RAMDISK: [mem 0x33041000-0x35817fff] [0.014411] ACPI: Early table checksum verification disabled [0.014414] ACPI: RSDP 0x000F0490 24 (v02 ALASKA) [0.014417] ACPI: XSDT 0xCAA24078 6C (v01 ALASKA A M I 01072009 AMI 00010013) [0.014421] ACPI: FACP 0xCAA30620 00010C (v05 ALASKA A M I 01072009 AMI 00010013) [0.014425] ACPI: DSDT 0xCAA24178 00C4A7 (v02 ALASKA A M I 0088 INTL 20091112) [0.014427] ACPI: FACS 0xCAA55080 40 [0.014429] ACPI: APIC 0xCAA30730 72 (v03 ALASKA A M I 01072009 AMI 00010013) [0.014431] ACPI: FPDT 0xCAA307A8
Bug#991941: linux: Don't use nouveau with Nvidia GeForce 8500 GT or alert in dmesg that firmware is needed
Source: linux Severity: normal Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? I have installed Debian 11 (debian installer RC3) on a PC having a Nvidia GeForce 8500 GT as main graphics card. The graphicall install process went well. After finishing the installation and reboot, I got a blank screen and "Input not supported" on my monitor. I changed to tty2 and logged in, and saved the dmesg output (attached), I noticed that "nouveau" driver was loaded but there was no info about my card not supported or needing additional firmware. * What exactly did you do (or not do) that was effective (or ineffective)? I have rebooted and edited the "linux" line during Grub menu, to add "nomodeset" and then I could have a fallback graphics mode. I have installed the isenkram-cli package and ran isenkram-autoinstall-firmware as suggested in the release notes and it installed firmware for my realtek card (unrelated) and firmware-misc-nonfree, but rebooting makes Linux pick the nouveau driver again. I have installed manually the nvidia-detect package and then I learned that this card needs the nvidia-legacy-340xx package, which is not present in bullseye. I tried to install manually the nvidia-legacy-340xx-driver package from sid and got the system showing a graphical environment without the need of adding "nomodeset" to the grub linux line. However later I read https://wiki.debian.org/NvidiaGraphicsDrivers and found: "Version 340.108 (legacy GPUs) (supported devices) Older legacy driver, for GeForce 8 series through GeForce 300 series. No Vulkan support, supports up to OpenGL 3.3 depending on your card. Use of the 340-series driver is strongly discouraged. It is not included in stable releases of Debian anymore, has serious unfixable security vulnerabilities, and may not be updated for new kernels in a timely manner. You are highly recommended to use the built-in Nouveau driver if security is a priority. " So I uninstalled the package. * What was the outcome of this action? I'm not sure which is the best way to get this system working, but anyway I think the average user would get puzzled about dmesg not alerting anything wrong but the system not showing graphics unless "nomodeset". * What outcome did you expect instead? I think that dmesg should alert the user that the card is not well supported by nouveau and/or would need to install additional firmware or be used in fallback mode. Kind regards, -- Laura Arjona Reina https://wiki.debian.org/LauraArjona -- System Information: Debian Release: 11.0 APT prefers testing-security APT policy: (500, 'testing-security'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Re: Scheduling 9.5
El 12 de junio de 2018 13:44:52 CEST, "Adam D. Barratt" escribió: >On 2018-06-08 18:51, Adam D. Barratt wrote: >> [Cc += debian-kernel] >> >> On Sun, 2018-05-20 at 12:04 +0200, Joerg Jaspert wrote: >>> On 15037 March 1977, Jonathan Wiltshire wrote: >[...] >> We're past any of the above by now, and while looking through the >to-do >> list for the final jessie point release, I noticed that we currently >> have some packages in opu with versions higher than stable. >> >> We can either accept the packages and put up with the situation for a >> short while, or do 9.5 before 8.11. In practical terms, that would >> likely mean both 9.5 and 8.11 on June 23rd, freezing both next >weekend. >> How do people feel about that? > >After discussions on IRC, it appears unlikely that the currently WIP >kernel update will be ready in sufficient time to be happy with it on >all architectures. > >So the possible options are: > >- go ahead with freezing 9.5 this weekend, and hope the kernel's ready >in time >- go ahead with freezing 9.5 this weekend, and update the kernel via >stable-updates later >- just do 8.11 this weekend, accept the version skew and get 9.5 >released as soon as we can > >To be entirely honest, I'm not that comfortable with announcing a >freeze >this close to the actual date. In terms of packages with version skew, >we have: > >- packages from the security archive, where users upgrading should >already have the jessie-security package installed in any case >- intel-microcode, src:patch and clamav, where it looks like the jessie > >package should work on stretch without issues >- tzdata, which is already available from stretch-updates. > >Given all of the above, I think the sanest option is to concentrate on >getting 8.11 done and jessie off our radar and then get 9.5 sorted. > >For suggested dates for 9.5, we know that June 30th is a no-go, Debcamp > >starts on July 21st and then Debconf on the 28th. So that leaves us >with: > >- July 7th This we (publicity) can, and prefer it. >- July 14th This, could be possible, but only one of us is available. Cheers -- Laura Arjona Reina https://wiki.debian.org/LauraArjona Sent with K-9 mail
Re: Scheduling 9.5
El 8 de junio de 2018 19:51:18 CEST, "Adam D. Barratt" escribió: >[Cc += debian-kernel] > >On Sun, 2018-05-20 at 12:04 +0200, Joerg Jaspert wrote: >> On 15037 March 1977, Jonathan Wiltshire wrote: >> > - May 26th (meaning freeze this coming weekend, which might be a >> > big >> > ask) >> >> No. >> >> > - Jun 2nd (which may require an unusual SRM) >> >> Possible. >> >> > - Jun 9th (getting quite a way out of cadence, but maybe that >> > can't be >> > helped) >> >> Possible. > >We're past any of the above by now, and while looking through the to-do > >list for the final jessie point release, I noticed that we currently >have some packages in opu with versions higher than stable. > >We can either accept the packages and put up with the situation for a >short while, or do 9.5 before 8.11. In practical terms, that would >likely mean both 9.5 and 8.11 on June 23rd, freezing both next weekend. >How do people feel about that? > Ok for publicity. Cheers -- Laura Arjona Reina https://wiki.debian.org/LauraArjona Sent with K-9 mail
