On Wed, 2018-07-04 at 19:44 +0200, Andreas Beckmann wrote:
> On 2018-07-04 01:54, Andreas Beckmann wrote:
> > On 2018-07-04 01:30, Andreas Beckmann wrote:
> > > I've prepared that in the 390 branch - could you give it a test
> > > run
> > > (with all workarounds disabled)?
> >
> > patch is not bac
On 2018-07-04 01:54, Andreas Beckmann wrote:
> On 2018-07-04 01:30, Andreas Beckmann wrote:
>> I've prepared that in the 390 branch - could you give it a test run
>> (with all workarounds disabled)?
>
> patch is not backwards compatible to older kernels:
I think I fixed that. I also tried to back
On 2018-07-04 01:30, Andreas Beckmann wrote:
> On 2018-07-03 20:31, Andreas Beckmann wrote:
>> On 2018-07-03 17:49, Raphael Hertzog wrote:
>>> RedHat published a much less invasive patch that you can use
>>> in the mean time:
>>> https://bugzilla.redhat.com/attachment.cgi?id=1425704
>>> (part of ht
On 2018-07-03 20:31, Andreas Beckmann wrote:
> On 2018-07-03 17:49, Raphael Hertzog wrote:
>> RedHat published a much less invasive patch that you can use
>> in the mean time:
>> https://bugzilla.redhat.com/attachment.cgi?id=1425704
>> (part of https://bugzilla.redhat.com/show_bug.cgi?id=1570493 )
On 2018-07-03 20:31:55 +0200, Andreas Beckmann wrote:
> On 2018-07-03 17:49, Raphael Hertzog wrote:
> > Hi,
> >
> > On Fri, 22 Jun 2018, Luca Boccassi wrote:
> >> I am downgrading as I verified there is a working workaround, add the
> >> following to the kernel cmdline:
> >>
> >> slab_common.userc
On 2018-07-03 17:49, Raphael Hertzog wrote:
> Hi,
>
> On Fri, 22 Jun 2018, Luca Boccassi wrote:
>> I am downgrading as I verified there is a working workaround, add the
>> following to the kernel cmdline:
>>
>> slab_common.usercopy_fallback=y
>
> It's still hitting users hard until they find out
Hi,
On Fri, 22 Jun 2018, Luca Boccassi wrote:
> I am downgrading as I verified there is a working workaround, add the
> following to the kernel cmdline:
>
> slab_common.usercopy_fallback=y
It's still hitting users hard until they find out this bug report.
> It might be possible to fix, and some
On Fri, 22 Jun 2018 10:29:14 -0500 Kent West wrote:
>
> The kernel parameter mentioned at the bottom of the bug report did not
help
> me (although, being unfamiliar with such tweaks, it's possible I did it
> wrong, but I don't think so).
After Luca's post above, I tried this parameter again. I *t
Control: reassign 901932 nvidia-driver 390.48-3
Control: reassign 901990 nvidia-driver 390.48-3
Control: forcemerge -1 901990 901932
Control: severity -1 important
Control: forwarded -1 https://devtalk.nvidia.com/default/topic/1031067
On Wed, 2018-06-20 at 11:54 +0200, Vincent Lefevre wrote:
> Pac
1. Apologies for not knowing how to properly add to this bug report.
2. I seem to be having the same issue. (Or very similar.)
I updated yesterday, got a new kernel of 4.16.0-2-amd64 #1 SMP Debian
4.16.16-1 (2018-06-19) x86_64 GNU/Linux, and on reboot just got a black
screen, with an apparently u
As a temporary workaround, we can add this paramater to the kernel:
slab_common.usercopy_fallback=Y
Worked for me.
See also https://devtalk.nvidia.com/default/topic/1031067
Package: nvidia-driver
Version: 390.59-1
Followup-For: Bug #901919
Control tag -1 confirmed
I can confirm this issue which occured with 4.16.16-1, but not with 4.16.12-1
my relevant part of kern.log
Jun 13 16:32:53 bagend kernel: [6.992399] [ cut here
]
Jun 13 16:32:
Control: retitle -1 nvidia-driver: black screen with the latest Linux kernel -
general protection fault
The kernel log was not included. It ends with:
Jun 20 11:46:59 zira kernel: [ 17.930908] usercopy: Kernel memory exposure
attempt detected from SLUB object 'nvidia_stack_cache' (offset 1144
Package: nvidia-driver
Version: 390.48-3
Severity: grave
Justification: renders package unusable
After upgrade to the Linux kernel 4.16.16-1, I get a black screen.
-- Package-specific info:
uname -a:
Linux zira 4.16.0-2-amd64 #1 SMP Debian 4.16.16-1 (2018-06-19) x86_64 GNU/Linux
/proc/version:
L
14 matches
Mail list logo
