https://bugs.freedesktop.org/show_bug.cgi?id=101368
Bug ID: 101368 Summary: Nouveau regression GT218M in Kernel 4.11 Won't Boot Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Keywords: regression Severity: normal Priority: medium Component: DRM/other Assignee: dri-devel@lists.freedesktop.org Reporter: bhs_suse@precisionforesight.com CC: tiwai@suse.de
Created attachment 131838 --> https://bugs.freedesktop.org/attachment.cgi?id=131838&action=edit dmesg output from the earlier 4.10 kernel showing correct functioning
Kernel 4.11.3-1 on a Lenovo Thinkpad T510 requires nomodeset to boot. Kernel 4.10.13-1 was fine. The T510 uses an NVIDIA Quadro NVS 3100M with 512MB. The OS is OpenSUSE Tumbleweed (a semi-tested rolling release for the brave). A dmesg from the working 4.10 kernel is attached. Downstream bug report is bugzilla.opensuse.org #1043280.
https://bugs.freedesktop.org/show_bug.cgi?id=101368
--- Comment #1 from Ilia Mirkin imirkin@alum.mit.edu --- Any particular reason you're blaming nouveau?
From the 4.10 log, it appears that i915 is the primary drm driver.
What does "won't boot" mean?
What happens if you specify 'nouveau.modeset=0' (which has the effect of disabling nouveau entirely but leaving i915 as it was)?
https://bugs.freedesktop.org/show_bug.cgi?id=101368
--- Comment #2 from Ben Steel bhs_suse@precisionforesight.com --- Thanks for the prompt response.
nouveau.modeset=0 allows it to successfully boot all the way into the GUI.
In successful 4.10 kernel boots, nouveau console messages are present. In unsuccessful 4.11 boots with console logging, the console messages would stop and the screen would experience bad scrolling (redraw problems) at unpredictable points in the list but never mentioning nouveau. I know that it didn't complete booting without the screen because the ssh daemon never came up, dashing my hopes for better logging.
https://bugs.freedesktop.org/show_bug.cgi?id=101368
--- Comment #3 from Ilia Mirkin imirkin@alum.mit.edu --- OK, so after booting with nouveau.modeset=0, rmmod nouveau, and reinsert it without that option. As your system should be fully up, you should get the relevant info of what fails.
https://bugs.freedesktop.org/show_bug.cgi?id=101368
--- Comment #4 from Ben Steel bhs_suse@precisionforesight.com --- Created attachment 131881 --> https://bugs.freedesktop.org/attachment.cgi?id=131881&action=edit dmesg after rmmod and insmod of nouveau
Tried the command sudo rmmod -v nouveau followed by sudo insmod /lib/modules/4.11.3-1-default/kernel/drivers/gpu/drm/nouveau/nouveau.ko
X was not running and I was on console. In each case stdout and stderr were redirected, but results were zero-length, so omitted for clarity. Results of insmod: Visibly, the four dmesg items from 1763.415095 to 1763.417364 were shown, the dispay froze up and the fan turned on, blowing very warm air. SSH was very slow, taking around a minute to get a prompt. Each command typed could take a similar amount of time. A shutdown command was never able to complete. Dmesg output during the ssh session after insmod is attached. Hope this helps.
https://bugs.freedesktop.org/show_bug.cgi?id=101368
--- Comment #5 from Ilia Mirkin imirkin@alum.mit.edu --- Can you see if this patch helps any?
https://github.com/skeggsb/linux/commit/a7cb78bab3671dbad08e5b2f5fd83a6dbda9...
If not, please boot with nouveau.debug=trace as well.
https://bugs.freedesktop.org/show_bug.cgi?id=101368
--- Comment #6 from Ben Steel bhs_suse@precisionforesight.com --- Created attachment 131935 --> https://bugs.freedesktop.org/attachment.cgi?id=131935&action=edit dmesg with debug=trace
Thanks for your efforts. Boot with patched driver unsuccessful. Dmesg from rmmod and insmod with debug trace attached. Thanks also to Takashi Iwai for the build of the patched kernel.
https://bugs.freedesktop.org/show_bug.cgi?id=101368
--- Comment #7 from Ilia Mirkin imirkin@alum.mit.edu --- Interesting. Dies in PMU preinit somewhere, which in turn calls nkvm_pmu_reset. I don't see an obvious reason for that to die except ... if PTIMER is somehow off?
The only difference is from 1e2115d8c0c0da62405400316f5499d909e479bc which makes it so that nvkm_falcon_v1_new is now being called, although I can't imagine what would go wrong there.
This will require someone who knows what they're doing to figure out ... i.e. not me. Hopefully Ben can take a look.
https://bugs.freedesktop.org/show_bug.cgi?id=101368
Ilia Mirkin imirkin@alum.mit.edu changed:
What |Removed |Added ---------------------------------------------------------------------------- QA Contact| |xorg-team@lists.x.org Product|DRI |xorg Assignee|dri-devel@lists.freedesktop |nouveau@lists.freedesktop.o |.org |rg Component|DRM/other |Driver/nouveau
dri-devel@lists.freedesktop.org
-
bugzilla-daemon＠freedesktop.org