You are not logged in.
Pages: 1
I have started experiencing kernel panics on almost every boot after a recent update. It only happens when I use nouveau with my Nvidia GT 630. Unfortunately I can't tell which packages have been upgraded, because I did a fresh install in the meantime to rule out any errors on my end, which destroyed the update logs.
I have tried my Intel IGPU: no kernel panics. I have also tried using the proprietary Nvidia driver with my GT 630: no kernel panics. It seems to definitely be related to nouveau (also mentioned in the kernel panic).
I have tried using the LTS kernel, but with the same results. I assume that means it's not a problem within the kernel?
Just to rule out my hardware as the culprit, I installed a different Linux distribution (Ubuntu) and also Windows. Both work fine, without problems.
Picture of the kernel panic (on a fresh install, during first boot):
http://preview.ibb.co/mb2oJF/DSC_0007_1.jpg
Kernel version: 4.11.3-1 (latest from the repository)
Link to the bug report I opened upstream: https://bugs.freedesktop.org/show_bug.cgi?id=101273
Does anyone else with the same or similar hardware experience this problem?
Last edited by justasug (2017-06-15 06:56:09)
Offline
Hallo justasug,
Yes I have this problem too. I use lib32-mesa 17.1.0-1, mesa 17.1.0-1 and xf86-video-nouveau 1.0.15-1. My VGA compatible controller is NVIDIA Corporation GF108 [GeForce GT 630] (rev a1).
Since I upgraded to linux 4.11.3-1 I have kernel panic too. A temporary solution for me is a downgrade to linux 4.11.2-1. I have no idea what can I do. I don't want install the proprietary driver.
Offline
Have you tried the LTS kernel? I did and was still getting the kernel panics. I however didn't try to downgrade the "regular" kernel.
Is there an explanation why the LTS kernel doesn't work, but the previous version of the stock kernel does?
Offline
Hello justasug,
Yes I have also tested linux-lts 4.9.30-1 and with this I have kernel panic too.
Offline
Another solution is to switch to nvivida drivers.
cu Peje
Offline
Have you tried bisecting between 4.11.2 and 4.11.3? From the changelog these four commits seem the most relevant to me:
commit 33f379db4711fe71b9a107256fd07ffd040b9735
Author: Ben Skeggs <bskeggs@redhat.com>
Date: Thu May 11 17:19:48 2017 +1000
drm/nouveau/tmr: handle races with hw when updating the next alarm time
commit 1b0f84380b10ee97f7d2dd191294de9017e94d1d upstream.
If the time to the next alarm is short enough, we could race with HW and
end up with an ~4 second delay until it triggers.
Fix this by checking again after we update HW.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 53b8e320383bf7b4311be9ab188515538e712a18
Author: Ben Skeggs <bskeggs@redhat.com>
Date: Thu May 11 17:13:29 2017 +1000
drm/nouveau/tmr: avoid processing completed alarms when adding a new one
commit 330bdf62fe6a6c5b99a647f7bf7157107c9348b3 upstream.
The idea here was to avoid having to "manually" program the HW if there's
a new earliest alarm. This was lazy and bad, as it leads to loads of fun
races between inter-related callers (ie. therm).
Turns out, it's not so difficult after all. Go figure ;)
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 952030b868e98659836dac836648ca815c1631ce
Author: Ben Skeggs <bskeggs@redhat.com>
Date: Thu May 11 17:03:05 2017 +1000
drm/nouveau/tmr: fix corruption of the pending list when rescheduling an alarm
commit 9fc64667ee48c9a25e7dca1a6bcb6906fec5bcc5 upstream.
At least therm/fantog "attempts" to work around this issue, which could
lead to corruption of the pending alarm list.
Fix it properly by not updating the timestamp without the lock held, or
trying to add an already pending alarm to the pending alarm list....
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 4c168033dd9a0ef770095461a664cbc860c625b7
Author: Ben Skeggs <bskeggs@redhat.com>
Date: Thu May 11 16:53:42 2017 +1000
drm/nouveau/tmr: ack interrupt before processing alarms
commit 3733bd8b407211739e72d051e5f30ad82a52c4bc upstream.
Fixes a race where we can miss an alarm that triggers while we're already
processing previous alarms.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>Offline
Have you tried bisecting between 4.11.2 and 4.11.3
Nope, but someone else did on the upstream bug tracker. There is more information about the bug, on the upstream bug tracker here:
https://bugs.freedesktop.org/show_bug.cgi?id=101184
There's a potential fix, but it needs testing/verification.
Last edited by justasug (2017-06-05 18:23:37)
Offline
I have tested linux 4.11.3 by applying the patch provided on the bug report (see above). And voilà it works!
$ uname -a
Linux home-pc 4.11.3-1-ARCH #1 SMP PREEMPT Tue Jun 6 23:32:03 CEST 2017 x86_64 GNU/Linux$ pacman -Qs nouveau
local/lib32-mesa 17.1.1-1
an open-source implementation of the OpenGL specification (32-bit)
local/mesa 17.1.1-1
an open-source implementation of the OpenGL specification
local/xf86-video-nouveau 1.0.15-1 (xorg-drivers)
Open Source 2D acceleration driver for nVidia cardsOffline
I have tested linux 4.11.3 by applying the patch provided on the bug report (see above). And voilà it works!
$ uname -a Linux home-pc 4.11.3-1-ARCH #1 SMP PREEMPT Tue Jun 6 23:32:03 CEST 2017 x86_64 GNU/Linux$ pacman -Qs nouveau local/lib32-mesa 17.1.1-1 an open-source implementation of the OpenGL specification (32-bit) local/mesa 17.1.1-1 an open-source implementation of the OpenGL specification local/xf86-video-nouveau 1.0.15-1 (xorg-drivers) Open Source 2D acceleration driver for nVidia cards
how to apply this patch?
Offline
how to apply this patch?
Offline
This has been fixed with kernel 4.11.5-1.
Offline
Pages: 1