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 m
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.
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 dr
Is this confined to systemd 241-4? Will back-revving to 241-3 be a
sufficient workaround?
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
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
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
y 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:
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 cons
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 wr
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 amd64
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.
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 gr
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
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
15 matches
Mail list logo
