Bug#995799: nvidia-legacy-340xx-driver startx failure on 5.14.9
Package: nvidia-legacy-340xx-driver Version: 340.108-11 Severity: serious The latest nvidia-legacy-340xx-driver succeeds in building the dkms module with kernel 5.14.9, but startx fails to locate any valid screens. This same driver works correctly with kernel 5.10.70. It appears that drm may be what is having issues here as when it is working, one can see both the nvidia and drm drivers loaded using lsmod; with kernel 5.14.9 the nvidia driver is loaded, the drm is not. Comparing dmesg output -- 5.10.70: > sudo dmesg | egrep nvidia [ 17.228869] nvidia: loading out-of-tree module taints kernel. [ 17.228932] nvidia: module license 'NVIDIA' taints kernel. [ 17.247604] nvidia :04:00.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=none:owns=io+mem [ 17.247929] [drm] Initialized nvidia-drm 0.0.0 20150116 for :04:00.0 on minor 0 [ 32.923403] caller _nv000788rm+0xe4/0x1c0 [nvidia] mapping multiple BARs [ 109.283171] caller _nv000788rm+0xe4/0x1c0 [nvidia] mapping multiple BARs 5.14.9: > sudo dmesg | egrep nvidia [ 22.765964] nvidia: loading out-of-tree module taints kernel. [ 22.766040] nvidia: module license 'NVIDIA' taints kernel. [ 22.785231] nvidia :04:00.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=none:owns=io+mem [ 53.226048] caller _nv000788rm+0xe4/0x1c0 [nvidia] mapping multiple BARs -- sRw
Bug#958446: nvidia-legacy-340xx-driver: Fails to build with kernel 5.6
DKMS works for me using kernel 5.6.8 -- sRw On 2020-04-30 06:09, Andreas Beckmann wrote: On 30/04/2020 12.09, jim_p wrote: And then the reference to #956458, which is for nvidia legacy 390xx. So I would like to ask if the bug I mentioned here is indeed fixed in the -5 revision of the package. I can't test it right now, but I probably will tomorrow or on Saturday. I backported NVIDIA's changes from 440.82 to 418.126.02 (tesla-418), then to 390.132 (legacy-390xx) then to 340.108 (copying the wrong bug number). There were always some parts being patched not yet existing in the older releases so the patches got smaller on the way. For 340.108 it was more or less a complete redo, since nvidia significantly restructured the driver source after that series. There were also some ancient bits no longer existing in newer releases that needed to be patched additionally for 5.6. So yes, it is fixed for the 340 series, too. But as always, only compile-tested. Andreas
Bug#958446: nvidia-legacy-340xx-driver: Fails to build with kernel 5.6
Just my 2d, but I am with Jim P on the whole "nouveau is something I hate even more" thing. This driver is operational in 5.5.x as we know, but since that branch went EOL I have just reverted my machines to 5.4.x for the time being )OK for now since 5.4.x is long-term). The native NVIDIA driver uses power very efficiently whereas my experience has been that nouveau does not. On 2020-04-25 01:12, jim_p wrote: Package: nvidia-legacy-340xx-driver Version: 340.108-4 Followup-For: Bug #958446 I know the command I have to run, I just don't know the path to use there. And last time I patched the file manually, because it was only one file, I wrote that one line by hand :D If you show me the way, e.e. the exact thing I have to write on the terminal to do the patching, I will test it on 5.6. If it works, will you use it? I really have no idea on how to find that offending line you mention. Also, if it breaks the kernel on another branch, simply don't use it in that branch. I have noticed that the package is not on the same (sub)version from unstable to oldstable and I assume it is because of the different patches each one can get. I also hate to do all that for something that is eol, but being forced to use nouveau is something I hate even more. In the very end, I will consider switching to another distro just to be able to use the driver, even if it means that I will have to build it myself. -- Package-specific info: uname -a: Linux mitsos 5.5.0-2-amd64 #1 SMP Debian 5.5.17-1 (2020-04-15) x86_64 GNU/Linux /proc/version: Linux version 5.5.0-2-amd64 (debian-ker...@lists.debian.org) (gcc version 9.3.0 (Debian 9.3.0-10)) #1 SMP Debian 5.5.17-1 (2020-04-15) /proc/driver/nvidia/version: NVRM version: NVIDIA UNIX x86_64 Kernel Module 340.108 Wed Dec 11 11:06:58 PST 2019 GCC version: gcc version 9.3.0 (Debian 9.3.0-10) lspci 'display controller [030?]': 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GT218 [GeForce 210] [10de:0a65] (rev a2) (prog-if 00 [VGA controller]) Subsystem: ASUSTeK Computer Inc. GT218 [GeForce 210] [1043:8490] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: nvidia Kernel modules: nvidia dmesg: [0.309604] Console: colour VGA+ 80x25 [0.746332] pci :01:00.0: vgaarb: setting as boot VGA device [0.746332] pci :01:00.0: vgaarb: VGA device added: decodes=io+mem,owns=io+mem,locks=none [0.746332] pci :01:00.0: vgaarb: bridge control possible [0.746332] vgaarb: loaded [0.932293] Linux agpgart interface v0.103 [3.347163] nvidia: loading out-of-tree module taints kernel. [3.347175] nvidia: module license 'NVIDIA' taints kernel. [3.376308] nvidia: module verification failed: signature and/or required key missing - tainting kernel [3.396473] nvidia :01:00.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=none:owns=io+mem [3.397701] [drm] Initialized nvidia-drm 0.0.0 20150116 for :01:00.0 on minor 0 [3.397714] NVRM: loading NVIDIA UNIX x86_64 Kernel Module 340.108 Wed Dec 11 11:06:58 PST 2019 [3.953374] snd_hda_intel :01:00.1: Handle vga_switcheroo audio client [5.213460] input: HDA NVidia HDMI/DP,pcm=3 as /devices/pci:00/:00:01.0/:01:00.1/sound/card1/input22 [5.214117] input: HDA NVidia HDMI/DP,pcm=7 as /devices/pci:00/:00:01.0/:01:00.1/sound/card1/input23 [5.215241] input: HDA NVidia HDMI/DP,pcm=8 as /devices/pci:00/:00:01.0/:01:00.1/sound/card1/input24 [5.215334] input: HDA NVidia HDMI/DP,pcm=9 as /devices/pci:00/:00:01.0/:01:00.1/sound/card1/input25 [7.417788] caller _nv000788rm+0xe4/0x1c0 [nvidia] mapping multiple BARs Device node permissions: crw-rw+ 1 root video 226, 0 Apr 25 07:00 /dev/dri/card0 crw-rw-rw- 1 root root 195, 0 Apr 25 07:00 /dev/nvidia0 crw-rw-rw- 1 root root 195, 255 Apr 25 07:00 /dev/nvidiactl /dev/dri/by-path: total 0 lrwxrwxrwx 1 root root 8 Apr 25 07:00 pci-:01:00.0-card -> ../card0 video:*:44:jim OpenGL and NVIDIA library files installed: lrwxrwxrwx 1 root root 15 Jan 5 09:29 /etc/alternatives/glx -> /usr/lib/nvidia lrwxrwxrwx 1 root root 44 Jan 5 09:29 /etc/alternatives/glx--libEGL.so.1-x86_64-linux-gnu -> /usr/lib/x86_64-linux-gnu/nvidia/libEGL.so.1 lrwxrwxrwx 1 root root 43 Jan 5 09:29 /etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> /usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1 lrwxrwxrwx 1 root root 43 Jan 5 09:29 /etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> /usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1 lrwxrwxrwx 1 root root 54 Jan 5 09:29 /etc/alternatives/glx--libGLESv2.so.2-x86_64-linux-gnu -> /usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2 lrwxrwxrwx 1 root root 54 Jan 5 09:29 /etc/alternatives/glx--libGLE
Bug#929229: systemd, udev -- keyboard freezes after exiting X in version 241-4
Is this confined to systemd 241-4? Will back-revving to 241-3 be a sufficient workaround?
Bug#902897: virtualbox: fails to start vm (VERR_LDRELF_RELOCATION_NOT_SUPPORTED)
Can verify, this bug is kernel independent. On Tue, 10 Jul 2018 12:15:51 +0200 Vincent Gatignol wrote: > hi there, > > running 4.9.0-6-amd64 #1 SMP Debian 4.9.88-1+deb9u1 (2018-05-07) x86_64 > GNU/Linux and having this issue too > > not specifically related to the 4.16 versions > > > Regards >
Bug#841420: Rolling Back?
On 10/31/2016 06:42 AM, Hannu wrote: How do I roll back to gcc-6.2.0-6? If you haven't cleaned package cache recently you might try this: cd /var/cache/apt/archives ls -al *6.2.0-6* and if gcc-6.2.0-6 seems to be present: dpkg -i *6.2.0-6* The packages still appear to be available at http://repo.kali.org/kali/pool/main/g/gcc-6/
Bug#841420: fix
As just a data point, when -march=i686, the kernel builds and seems to work well using 6.2.0-10 and with no patches to Makefile at all. On 10/29/2016 10:24 AM, Oswald Buddenhagen wrote: -no-pie is not a useful option here, because it's passed to the _linker_ only. i got it to build with this minimal patch: --- a/Makefile +++ b/Makefile @@ -400,5 +400,5 @@ KBUILD_CFLAGS := -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs \ -Werror-implicit-function-declaration \ -Wno-format-security \ - -std=gnu89 + -std=gnu89 -fno-PIE KBUILD_AFLAGS_KERNEL :=
Bug#841420: --enable-default-pie breaks kernel builds
I agree with Eric; while the workaround is to back rev the gcc and its associated packages, I also build kernels straight from kernel.org, usually within hours of their availability and this has been working for me for many years, and it is not sufficient to justify this change by saying doing so "isn't a good idea." A change of functionality of this scope warrants a minor version number increase, this change was not merely a bug fix. As the kernel is the most important code gcc is ever likely to compile on debian or any other distro for that matter, this change should be backed out, and not reintroduced UNTIL the *official* kernel source is ready for it. -- sRw On 10/21/2016 06:43 AM, Wolfgang Walter wrote: On Friday, 21 October 2016 14:45:25 CEST Ritesh Raj Sarraf wrote: The Debian kernel packages still have a dependency on gcc-5, which may mean that the kernels are currently only built/supported with gcc-5. vanilla kernels (Linus' tree and the stable ones) could be compiled just fine with gcc 6.2.0-6 and that now fails. I still think this is a major regression and regard gcc 6.2.0-7 simply as broken. On Thu, 2016-10-20 at 11:22 -0500, S R Wright wrote: Concurring with Wolfgang; pulling the source straight from kernel.org and using identical .config files will work with 6.2.0-6 but fail with 6.2.0-7. I was able to build and install 4.8.3 with no issues after back-revving gcc et. al. to 6.2.0-6 -- sRw On 10/20/16 11:09, Wolfgang Walter wrote: Hello, with this version of gcc-6 I can't build vanilla kernels any more. It fails with even with CC_STACKPROTECTOR_STRONG disabled: scripts/kconfig/mconf Kconfig configuration written to .config *** End of the configuration. *** Execute 'make' to start the build or try 'make help'. ksrc@ei:~/build/kernels/linux-4.8.3$ make scripts/kconfig/conf --silentoldconfig Kconfig CHK include/config/kernel.release CHK include/generated/uapi/linux/version.h CHK include/generated/utsrelease.h UPD include/generated/utsrelease.h CC kernel/bounds.s kernel/bounds.c:1:0: error: code model kernel does not support PIC mode /* Kbuild:45: recipe for target 'kernel/bounds.s' failed make[1]: *** [kernel/bounds.s] Error 1 Makefile:1015: recipe for target 'prepare0' failed make: *** [prepare0] Error 2 I think this is a major regression if you can't build vanilla and stable kernels any more. Regards, Regards,
Bug#841368: gcc-6 6.2.0-7 breaks kernel build if stack protection is enabled
I agree. When the version changes from 6.2.0-6 to 6.2.0-7, only bug fixes should be included, not changes in functionality. In this case setting enable-default-pie essentially broke backwards compatibility. Kernel code that built in -6 failed to build in -7. That, I agree, should be considered a bug, and the change should be rolled back. -- sRw On 10/20/2016 05:49 PM, Ben Hutchings wrote: On Fri, 2016-10-21 at 01:21 +0300, Konstantin Demin wrote: It's not a GCC bug but kind of new feature. It's a bug when a compiler fails to compile valid code. Ben. Take a look at this changelog entry: gcc-6 (6.2.0-7) unstable; urgency=medium [ Matthias Klose ] * Configure with --enable-default-pie and pass -z now when pie is enabled; on amd64 arm64 armel armhf i386 mips mipsel mips64el ppc64el s390x. Closes: #835148. Starting at gcc 6.2.0-7 we must provide "-fno-PIE -fno-PIC" in beginning of CFLAGS to build kernel successfully. I'm currently looking for correct way to do this trick.
Bug#841420: --enable-default-pie breaks kernel builds
Concurring with Wolfgang; pulling the source straight from kernel.org and using identical .config files will work with 6.2.0-6 but fail with 6.2.0-7. I was able to build and install 4.8.3 with no issues after back-revving gcc et. al. to 6.2.0-6 -- sRw On 10/20/16 11:09, Wolfgang Walter wrote: Hello, with this version of gcc-6 I can't build vanilla kernels any more. It fails with even with CC_STACKPROTECTOR_STRONG disabled: scripts/kconfig/mconf Kconfig configuration written to .config *** End of the configuration. *** Execute 'make' to start the build or try 'make help'. ksrc@ei:~/build/kernels/linux-4.8.3$ make scripts/kconfig/conf --silentoldconfig Kconfig CHK include/config/kernel.release CHK include/generated/uapi/linux/version.h CHK include/generated/utsrelease.h UPD include/generated/utsrelease.h CC kernel/bounds.s kernel/bounds.c:1:0: error: code model kernel does not support PIC mode /* Kbuild:45: recipe for target 'kernel/bounds.s' failed make[1]: *** [kernel/bounds.s] Error 1 Makefile:1015: recipe for target 'prepare0' failed make: *** [prepare0] Error 2 I think this is a major regression if you can't build vanilla and stable kernels any more. Regards,
Bug#808366: grub-efi-amd64 -- error: symbol 'grub_efi_find_last_device_path' not found
On 12/19/2015 09:03 AM, Colin Watson wrote: On Fri, Dec 18, 2015 at 09:26:55PM -0600, S. R. Wright wrote: dpkg -l "grub*" | egrep "^ii" ii grub-common2.02~beta2-33 amd64GRand Unified Bootloader (common files) ii grub-efi 2.02~beta2-33 amd64GRand Unified Bootloader, version 2 (dummy package) ii grub-efi-amd64 2.02~beta2-33 amd64GRand Unified Bootloader, version 2 (EFI-AMD64 version) ii grub-efi-amd64-bin 2.02~beta2-33 amd64GRand Unified Bootloader, version 2 (EFI-AMD64 binaries) ii grub2-common 2.02~beta2-33 amd64GRand Unified Bootloader (common files for version 2) On a system that dual boots Linux and Windows 10, the latest grub-efi gives this error: error: symbol 'grub_efi_find_last_device_path' not found when attempting to boot Windows 10 after an update-grub is performed. Linux will boot correctly; however, an attempt to boot Windows 10 will give this error and say "press any key..." and bring one back to the OS menu. There is a workaround, which is to downgrade back to 2.02~beta2-32, and Windows will boot correctly. This clearly indicates that GRUB is incorrectly installed in some way, because you could only get a symbol mismatch such as this if the GRUB image you're actually booting from doesn't match the modules it tries to load from /boot/grub/ at run-time. I would suggest digging around in your EFI System Partition to see if there's a manually-copied version in there somewhere. I definitely did not copy anything manually into the EFI System Partition; if a rogue file got into there -- or if something didn't get updated there that should have -- it happened via process. A downgrade back to 32 worked fine, an upgrade to 33 broke down, bothe of these performed using dpkg/apt-get. About all I can say.
Bug#808366: additional info
It's possible that Windows is not relevant here; it could be that whatever selection is last on the list that the OS prober constructs may have this issue, and in my case the last entry just happened to be Windows. Just FYI.
Bug#808366: grub-efi-amd64 -- error: symbol 'grub_efi_find_last_device_path' not found
Package: grub-efi-amd64 Version: 2.02~beta2-33 Severity: serious dpkg -l "grub*" | egrep "^ii" ii grub-common2.02~beta2-33 amd64GRand Unified Bootloader (common files) ii grub-efi 2.02~beta2-33 amd64GRand Unified Bootloader, version 2 (dummy package) ii grub-efi-amd64 2.02~beta2-33 amd64GRand Unified Bootloader, version 2 (EFI-AMD64 version) ii grub-efi-amd64-bin 2.02~beta2-33 amd64GRand Unified Bootloader, version 2 (EFI-AMD64 binaries) ii grub2-common 2.02~beta2-33 amd64GRand Unified Bootloader (common files for version 2) On a system that dual boots Linux and Windows 10, the latest grub-efi gives this error: error: symbol 'grub_efi_find_last_device_path' not found when attempting to boot Windows 10 after an update-grub is performed. Linux will boot correctly; however, an attempt to boot Windows 10 will give this error and say "press any key..." and bring one back to the OS menu. There is a workaround, which is to downgrade back to 2.02~beta2-32, and Windows will boot correctly.
Bug#762876: re: bind 9 crash / assertion failure
On Sat, 27 Sep 2014 23:48:10 -0400 Michael Gilbert wrote: > control: tag -1 moreinfo > > Could someone experiencing this please attach configuration files? > I'm not able to reproduce it with a vanilla installation. > > Best wishes, > Mike > > It pretty reliably crashed for me with the simplest of caching-only name servers; all I needed to do was start bind, then start web browsing and it would trip the assertion failure very quickly. -- sRw -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#762876: named assertion failure in bind9 1:9.9.5.dfsg-4.1 in mem.c
I can confirm that a rollback to version 1:9.9.5.dfsg-4 works correctly. My name server is just caching-only. -- sRw -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
