|
Bugzilla – Full Text Bug Listing |
| Summary: | latest 4.12.14-lp151.28.4-default , gets kernel NULL pointer dereference during nouveau drm establishment. | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE Distribution | Reporter: | Ross Green <greenfross> |
| Component: | Kernel | Assignee: | E-mail List <kernel-maintainers> |
| Status: | RESOLVED DUPLICATE | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Critical | ||
| Priority: | P5 - None | CC: | greenfross, meissner, mrmazda, paul.richards, ralf.koelmel, tcj, tiwai |
| Version: | Leap 15.1 | ||
| Target Milestone: | --- | ||
| Hardware: | x86-64 | ||
| OS: | Other | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: |
copy of boot.msg on failed boot
journalctl -b -1 after previously booted to lp151.28.4 journalctl -b via remote login booted to lp151.28.4 boot.msg from NVIDIA geforce RTX 2070 card showing stack trace. |
||
|
Description
Ross Green
2019-06-02 16:47:36 UTC
Created attachment 806604 [details]
copy of boot.msg on failed boot
Another problem associated with the nouveau driver seems to be the loading of the firmware for the nouveau hardware. I believe this use to not be a problem, however it may cause some extra complications. In general the nouveau driver seems to less stable in Leap 15.1 compared to Leap 15.0 or even 42.3. This system runs well on older releases. Other hardware with NVIDIA drivers or radeon hardware has no problems with Leap 15.1 kernel. Created attachment 806608 [details]
journalctl -b -1 after previously booted to lp151.28.4
reproduces with NVIDIA GT218 [GeForce 210] chip ID: 10de:0a65
Looking at both these stack traces it appears that these systems are caught somewhere within the KMS as drm_kms_helper is caught in the stack call unwind. Seems like the nouveau_connector_detect area is involved. Might be worth looking at drm_nouveau changes in this area between the kernel releases. Thanks Felix for verifying the above condition on different hardware, all be it with a NVIDIA display adapter. On the whole the nouveau driver seems much less stable in Leap 15.1 compared to Leap 15.0. Often get lookups in 15.1 where the display just completely freezes and can't even get back to a virtual terminal to investigate. Ross Jun 02 15:17:24 p5bse kernel: ? drm_dp_dpcd_access+0x69/0xf0 [drm_kms_helper] Jun 02 15:17:24 p5bse kernel: ? drm_dp_dpcd_read+0x2e/0xc0 [drm_kms_helper] Jun 02 15:17:24 p5bse kernel: ? drm_dp_cec_set_edid+0x4e/0x140 [drm_kms_helper] Jun 02 15:17:24 p5bse kernel: ? nouveau_connector_detect+0x1fd/0x440 [nouveau] Jun 02 15:17:24 p5bse kernel: ? drm_helper_probe_single_connector_modes+0xc3/0x6b0 [drm_kms_helper] Jun 02 15:17:24 p5bse kernel: ? nouveau_connector_force+0x80/0x80 [nouveau] Jun 02 15:17:24 p5bse kernel: ? drm_helper_probe_single_connector_modes+0xc3/0x6b0 [drm_kms_helper] Jun 02 15:17:24 p5bse kernel: ? dev_vprintk_emit+0x108/0x220 Jun 02 15:17:24 p5bse kernel: ? drm_setup_crtcs+0x139/0xa80 [drm_kms_helper] Jun 02 15:17:24 p5bse kernel: ? __drm_fb_helper_initial_config_and_unlock+0x2d/0x400 [drm_kms_helper] Jun 02 15:17:24 p5bse kernel: ? mutex_lock+0xe/0x30 Jun 02 15:17:24 p5bse kernel: ? nouveau_fbcon_init+0x14f/0x1c0 [nouveau] I have just been checking the upstream additions to the drm/nouveau driver in linus' git tree. There have not been a lot of new code changes to the nouveau drivers during May, April, or March. In fact I had to go all the way back to 2019-02-20 before I found any large amount of code added to this driver. So I suspect if this has crept in to the nouveau area it goes way back to at least kernel 5.0 development or earlier, maybe 4.19 or 4.20. Of course there may be a problem in more generic code, but on the whole there has not been a lot of fixes directly to the nouveau area over quite some period. Have not had time to go back further than 2019-02-20 kernel changes on linus git tree. It may be useful to talk to some of the up stream kernel developers who have worked in this area. Maybe Ben Skeggs, Colin Ian King, Daniel Vetter, ... To see if they can shed some more light on this problem. The stack traces may help the above people understand what might be happening here. There are lots more people using 4.19+ kernels in other distributions these days so looking to some of the upstream kernel people could be useful. Certainly the kernel used in the release Leap 15.1 did not exhibit this problem. It is just the latest update where I noticed it. Very obvious, it happens during boot up. That is to say 4.12.14-lp151.27-default boots but 4.12.14-lp151.28.4-default does not. The other thing to note is in the earlier 4.12.14-lp151.27-default kernel there are still freezes that occur during usage. On the whole Leap 15.1 has not been a happy experience regarding the nouveau driver. I have been using NVIDIA drivers on other 15.1 systems and have no such freezes. So there are several problems in this area I suspect. But failing to boot is obviously the most pressing. ;-) Ross Created attachment 806612 [details]
journalctl -b via remote login booted to lp151.28.4
Also reproduces with NVIDIA G98 [GeForce 8400 GS Rev. 2] chip ID: 10de:06e4.
lp151.28.4 does boot with usable video using nomodeset.
Yes I suspected calling with nomodeset might work. If you look at the stack unwind the first three calls come from drm_kms_helper. So Kernel modesetting was likely to be involved. I guess the point is we have a reproducible stack trace for kernel 4.12.14-lp151.28.4-default. So it should be possible to work out what has happened here. This problem did not happen with the earlier 15.1 kernel 4.12.14-lp151.27-default, so a few people who work closely with the nouveau driver might have a few ideas as to what changes have brought upon this outcome. With the exception of some of the additions for newer hardware there has not been a lot of activity in the nouveau driver for several months. Most of the major changes happened way back during the 5.0 release cycle. Likewise the 4.20 and 4.19 releases might be useful candidate changes that bought upon the problem. I think I did notice there were also a few kernel modeset changes along the way as well, when looking at kernel updates to the drm driver. So I suspect a few of the driver maintainers might be able to quickly shed some light on some likely potential changes that have brought on this problem. Ross Does this differ from bug 1136978 ? Just looked at the Stack Trace unwind and it does look similar to bug 1136978. In particular to the calls from drm_kms_helper. While setting nomodeset might make some of the driver work. It really is just hiding the problem considering that the earlier release kernel functioned better, i.e booted cleanly. As mentioned before the stack trace should help work exactly what the problem is. I understand this later kernel has drawn heavily from 5.0 kernel driver, it may pay to check further with both 5.1 and 5.2 updates to see if there is already an upstream fix. It may also be that there are other things missing from upstream kernels that might be required Ross 2019-05-31T11:08:23.970542+02:00 linux-ilj4 kernel: [ 3.574019] BUG: unable to handle kernel NULL pointer dereference at (null) 2019-05-31T11:08:23.970543+02:00 linux-ilj4 kernel: [ 3.574023] IP: (null) 2019-05-31T11:08:23.970543+02:00 linux-ilj4 kernel: [ 3.574025] PGD 0 P4D 0 2019-05-31T11:08:23.970544+02:00 linux-ilj4 kernel: [ 3.574027] Oops: 0010 [#1] SMP PTI 2019-05-31T11:08:23.970546+02:00 linux-ilj4 kernel: [ 3.574030] CPU: 1 PID: 312 Comm: systemd-udevd Not tainted 4.12.14-lp151.28. 4-default #1 openSUSE Leap 15.1 2019-05-31T11:08:23.970546+02:00 linux-ilj4 kernel: [ 3.574032] Hardware name: Hewlett-Packard HP Z420 Workstation/1589, BIOS J61 v03.15 05/09/2013 2019-05-31T11:08:23.970547+02:00 linux-ilj4 kernel: [ 3.574033] task: ffff880808c04040 task.stack: ffffc90004090000 2019-05-31T11:08:23.970547+02:00 linux-ilj4 kernel: [ 3.574035] RIP: 0010: (null) 2019-05-31T11:08:23.970547+02:00 linux-ilj4 kernel: [ 3.574036] RSP: 0018:ffffc900040937d8 EFLAGS: 00010246 2019-05-31T11:08:23.970548+02:00 linux-ilj4 kernel: [ 3.574038] RAX: 0000000000000000 RBX: 0000000000000020 RCX: ffffc9000409386f 2019-05-31T11:08:23.970548+02:00 linux-ilj4 kernel: [ 3.574040] RDX: ffff880808c04040 RSI: ffffc900040937e8 RDI: ffff88080766b490 2019-05-31T11:08:23.970550+02:00 linux-ilj4 kernel: [ 3.574042] RBP: 0000000000000001 R08: 0000000000000001 R09: ffff88080f223980 2019-05-31T11:08:23.970551+02:00 linux-ilj4 kernel: [ 3.574043] R10: 0000000000000000 R11: 0000000000000040 R12: 00000000fffffffb 2019-05-31T11:08:23.970551+02:00 linux-ilj4 kernel: [ 3.574045] R13: ffff88080766b490 R14: 0000000000000000 R15: ffff880808b5b218 2019-05-31T11:08:23.970552+02:00 linux-ilj4 kernel: [ 3.574047] FS: 00007f2be4dfed40(0000) GS:ffff88080f240000(0000) knlGS:00000 00000000000 2019-05-31T11:08:23.970552+02:00 linux-ilj4 kernel: [ 3.574049] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 2019-05-31T11:08:23.970552+02:00 linux-ilj4 kernel: [ 3.574050] CR2: 0000000000000000 CR3: 0000000808aa4001 CR4: 00000000000606e0 2019-05-31T11:08:23.970554+02:00 linux-ilj4 kernel: [ 3.574052] Call Trace: 2019-05-31T11:08:23.970555+02:00 linux-ilj4 kernel: [ 3.574063] ? drm_dp_dpcd_access+0x69/0xf0 [drm_kms_helper] 2019-05-31T11:08:23.970555+02:00 linux-ilj4 kernel: [ 3.574067] ? drm_dp_dpcd_read+0x2e/0xc0 [drm_kms_helper] 2019-05-31T11:08:23.970556+02:00 linux-ilj4 kernel: [ 3.574072] ? drm_dp_cec_set_edid+0x4e/0x140 [drm_kms_helper] 2019-05-31T11:08:23.970556+02:00 linux-ilj4 kernel: [ 3.574116] ? nouveau_connector_detect+0x1fd/0x440 [nouveau] 2019-05-31T11:08:23.970557+02:00 linux-ilj4 kernel: [ 3.574123] ? drm_helper_probe_single_connector_modes+0xc3/0x6b0 [drm_kms_he lper] 2019-05-31T11:08:23.970557+02:00 linux-ilj4 kernel: [ 3.574152] ? nouveau_connector_force+0x80/0x80 [nouveau] 2019-05-31T11:08:23.970559+02:00 linux-ilj4 kernel: [ 3.574158] ? drm_helper_probe_single_connector_modes+0xc3/0x6b0 [drm_kms_he lper] 2019-05-31T11:08:23.970560+02:00 linux-ilj4 kernel: [ 3.574164] ? dev_vprintk_emit+0x108/0x220 2019-05-31T11:08:23.970560+02:00 linux-ilj4 kernel: [ 3.574170] ? drm_setup_crtcs+0x139/0xa80 [drm_kms_helper] 2019-05-31T11:08:23.970560+02:00 linux-ilj4 kernel: [ 3.574176] ? __drm_fb_helper_initial_config_and_unlock+0x2d/0x400 [drm_kms_ helper] 2019-05-31T11:08:23.970561+02:00 linux-ilj4 kernel: [ 3.574182] ? mutex_lock+0xe/0x30 2019-05-31T11:08:23.970561+02:00 linux-ilj4 kernel: [ 3.574210] ? nouveau_fbcon_init+0x14f/0x1c0 [nouveau] 2019-05-31T11:08:23.970563+02:00 linux-ilj4 kernel: [ 3.574236] ? nouveau_drm_device_init+0x184/0x7f0 [nouveau] 2019-05-31T11:08:23.970564+02:00 linux-ilj4 kernel: [ 3.574263] ? nouveau_drm_probe+0x1eb/0x2b0 [nouveau] 2019-05-31T11:08:23.970564+02:00 linux-ilj4 kernel: [ 3.574266] ? __pm_runtime_resume+0x54/0x70 2019-05-31T11:08:23.970565+02:00 linux-ilj4 kernel: [ 3.574271] ? local_pci_probe+0x42/0xa0 2019-05-31T11:08:23.970565+02:00 linux-ilj4 kernel: [ 3.574274] ? pci_device_probe+0x13c/0x160 2019-05-31T11:08:23.970566+02:00 linux-ilj4 kernel: [ 3.574279] ? driver_probe_device+0x2f7/0x440 2019-05-31T11:08:23.970566+02:00 linux-ilj4 kernel: [ 3.574282] ? __driver_attach+0xb8/0xe0 2019-05-31T11:08:23.970568+02:00 linux-ilj4 kernel: [ 3.574285] ? driver_probe_device+0x440/0x440 2019-05-31T11:08:23.970568+02:00 linux-ilj4 kernel: [ 3.574288] ? bus_for_each_dev+0x5e/0x90 2019-05-31T11:08:23.970569+02:00 linux-ilj4 kernel: [ 3.574291] ? bus_add_driver+0x161/0x260 2019-05-31T11:08:23.970569+02:00 linux-ilj4 kernel: [ 3.574293] ? 0xffffffffa05cf000 2019-05-31T11:08:23.970570+02:00 linux-ilj4 kernel: [ 3.574296] ? driver_register+0x57/0xc0 2019-05-31T11:08:23.970570+02:00 linux-ilj4 kernel: [ 3.574299] ? 0xffffffffa05cf000 2019-05-31T11:08:23.970570+02:00 linux-ilj4 kernel: [ 3.574303] ? do_one_initcall+0x4e/0x190 2019-05-31T11:08:23.970573+02:00 linux-ilj4 kernel: [ 3.574308] ? __vunmap+0x6d/0xb0 2019-05-31T11:08:23.970574+02:00 linux-ilj4 kernel: [ 3.574310] ? __vunmap+0x6d/0xb0 2019-05-31T11:08:23.970574+02:00 linux-ilj4 kernel: [ 3.574314] ? do_init_module+0x5b/0x1e4 2019-05-31T11:08:23.970575+02:00 linux-ilj4 kernel: [ 3.574319] ? load_module+0x18ec/0x1f80 2019-05-31T11:08:23.970575+02:00 linux-ilj4 kernel: [ 3.574324] ? SYSC_finit_module+0xb7/0xd0 2019-05-31T11:08:23.970575+02:00 linux-ilj4 kernel: [ 3.574327] ? SYSC_finit_module+0xb7/0xd0 2019-05-31T11:08:23.970577+02:00 linux-ilj4 kernel: [ 3.574330] ? do_syscall_64+0x7b/0x160 2019-05-31T11:08:23.970578+02:00 linux-ilj4 kernel: [ 3.574334] ? entry_SYSCALL_64_after_hwframe+0x3d/0xa2 Just looked at the Stack Trace unwind and it does look similar to bug 1136978. In particular to the calls from drm_kms_helper. While setting nomodeset might make some of the driver work. It really is just hiding the problem considering that the earlier release kernel functioned better, i.e booted cleanly. As mentioned before the stack trace should help work exactly what the problem is. I understand this later kernel has drawn heavily from 5.0 kernel driver, it may pay to check further with both 5.1 and 5.2 updates to see if there is already an upstream fix. It may also be that there are other things missing from upstream kernels that might be required Ross 2019-05-31T11:08:23.970542+02:00 linux-ilj4 kernel: [ 3.574019] BUG: unable to handle kernel NULL pointer dereference at (null) 2019-05-31T11:08:23.970543+02:00 linux-ilj4 kernel: [ 3.574023] IP: (null) 2019-05-31T11:08:23.970543+02:00 linux-ilj4 kernel: [ 3.574025] PGD 0 P4D 0 2019-05-31T11:08:23.970544+02:00 linux-ilj4 kernel: [ 3.574027] Oops: 0010 [#1] SMP PTI 2019-05-31T11:08:23.970546+02:00 linux-ilj4 kernel: [ 3.574030] CPU: 1 PID: 312 Comm: systemd-udevd Not tainted 4.12.14-lp151.28. 4-default #1 openSUSE Leap 15.1 2019-05-31T11:08:23.970546+02:00 linux-ilj4 kernel: [ 3.574032] Hardware name: Hewlett-Packard HP Z420 Workstation/1589, BIOS J61 v03.15 05/09/2013 2019-05-31T11:08:23.970547+02:00 linux-ilj4 kernel: [ 3.574033] task: ffff880808c04040 task.stack: ffffc90004090000 2019-05-31T11:08:23.970547+02:00 linux-ilj4 kernel: [ 3.574035] RIP: 0010: (null) 2019-05-31T11:08:23.970547+02:00 linux-ilj4 kernel: [ 3.574036] RSP: 0018:ffffc900040937d8 EFLAGS: 00010246 2019-05-31T11:08:23.970548+02:00 linux-ilj4 kernel: [ 3.574038] RAX: 0000000000000000 RBX: 0000000000000020 RCX: ffffc9000409386f 2019-05-31T11:08:23.970548+02:00 linux-ilj4 kernel: [ 3.574040] RDX: ffff880808c04040 RSI: ffffc900040937e8 RDI: ffff88080766b490 2019-05-31T11:08:23.970550+02:00 linux-ilj4 kernel: [ 3.574042] RBP: 0000000000000001 R08: 0000000000000001 R09: ffff88080f223980 2019-05-31T11:08:23.970551+02:00 linux-ilj4 kernel: [ 3.574043] R10: 0000000000000000 R11: 0000000000000040 R12: 00000000fffffffb 2019-05-31T11:08:23.970551+02:00 linux-ilj4 kernel: [ 3.574045] R13: ffff88080766b490 R14: 0000000000000000 R15: ffff880808b5b218 2019-05-31T11:08:23.970552+02:00 linux-ilj4 kernel: [ 3.574047] FS: 00007f2be4dfed40(0000) GS:ffff88080f240000(0000) knlGS:00000 00000000000 2019-05-31T11:08:23.970552+02:00 linux-ilj4 kernel: [ 3.574049] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 2019-05-31T11:08:23.970552+02:00 linux-ilj4 kernel: [ 3.574050] CR2: 0000000000000000 CR3: 0000000808aa4001 CR4: 00000000000606e0 2019-05-31T11:08:23.970554+02:00 linux-ilj4 kernel: [ 3.574052] Call Trace: 2019-05-31T11:08:23.970555+02:00 linux-ilj4 kernel: [ 3.574063] ? drm_dp_dpcd_access+0x69/0xf0 [drm_kms_helper] 2019-05-31T11:08:23.970555+02:00 linux-ilj4 kernel: [ 3.574067] ? drm_dp_dpcd_read+0x2e/0xc0 [drm_kms_helper] 2019-05-31T11:08:23.970556+02:00 linux-ilj4 kernel: [ 3.574072] ? drm_dp_cec_set_edid+0x4e/0x140 [drm_kms_helper] 2019-05-31T11:08:23.970556+02:00 linux-ilj4 kernel: [ 3.574116] ? nouveau_connector_detect+0x1fd/0x440 [nouveau] 2019-05-31T11:08:23.970557+02:00 linux-ilj4 kernel: [ 3.574123] ? drm_helper_probe_single_connector_modes+0xc3/0x6b0 [drm_kms_he lper] 2019-05-31T11:08:23.970557+02:00 linux-ilj4 kernel: [ 3.574152] ? nouveau_connector_force+0x80/0x80 [nouveau] 2019-05-31T11:08:23.970559+02:00 linux-ilj4 kernel: [ 3.574158] ? drm_helper_probe_single_connector_modes+0xc3/0x6b0 [drm_kms_he lper] 2019-05-31T11:08:23.970560+02:00 linux-ilj4 kernel: [ 3.574164] ? dev_vprintk_emit+0x108/0x220 2019-05-31T11:08:23.970560+02:00 linux-ilj4 kernel: [ 3.574170] ? drm_setup_crtcs+0x139/0xa80 [drm_kms_helper] 2019-05-31T11:08:23.970560+02:00 linux-ilj4 kernel: [ 3.574176] ? __drm_fb_helper_initial_config_and_unlock+0x2d/0x400 [drm_kms_ helper] 2019-05-31T11:08:23.970561+02:00 linux-ilj4 kernel: [ 3.574182] ? mutex_lock+0xe/0x30 2019-05-31T11:08:23.970561+02:00 linux-ilj4 kernel: [ 3.574210] ? nouveau_fbcon_init+0x14f/0x1c0 [nouveau] 2019-05-31T11:08:23.970563+02:00 linux-ilj4 kernel: [ 3.574236] ? nouveau_drm_device_init+0x184/0x7f0 [nouveau] 2019-05-31T11:08:23.970564+02:00 linux-ilj4 kernel: [ 3.574263] ? nouveau_drm_probe+0x1eb/0x2b0 [nouveau] 2019-05-31T11:08:23.970564+02:00 linux-ilj4 kernel: [ 3.574266] ? __pm_runtime_resume+0x54/0x70 2019-05-31T11:08:23.970565+02:00 linux-ilj4 kernel: [ 3.574271] ? local_pci_probe+0x42/0xa0 2019-05-31T11:08:23.970565+02:00 linux-ilj4 kernel: [ 3.574274] ? pci_device_probe+0x13c/0x160 2019-05-31T11:08:23.970566+02:00 linux-ilj4 kernel: [ 3.574279] ? driver_probe_device+0x2f7/0x440 2019-05-31T11:08:23.970566+02:00 linux-ilj4 kernel: [ 3.574282] ? __driver_attach+0xb8/0xe0 2019-05-31T11:08:23.970568+02:00 linux-ilj4 kernel: [ 3.574285] ? driver_probe_device+0x440/0x440 2019-05-31T11:08:23.970568+02:00 linux-ilj4 kernel: [ 3.574288] ? bus_for_each_dev+0x5e/0x90 2019-05-31T11:08:23.970569+02:00 linux-ilj4 kernel: [ 3.574291] ? bus_add_driver+0x161/0x260 2019-05-31T11:08:23.970569+02:00 linux-ilj4 kernel: [ 3.574293] ? 0xffffffffa05cf000 2019-05-31T11:08:23.970570+02:00 linux-ilj4 kernel: [ 3.574296] ? driver_register+0x57/0xc0 2019-05-31T11:08:23.970570+02:00 linux-ilj4 kernel: [ 3.574299] ? 0xffffffffa05cf000 2019-05-31T11:08:23.970570+02:00 linux-ilj4 kernel: [ 3.574303] ? do_one_initcall+0x4e/0x190 2019-05-31T11:08:23.970573+02:00 linux-ilj4 kernel: [ 3.574308] ? __vunmap+0x6d/0xb0 2019-05-31T11:08:23.970574+02:00 linux-ilj4 kernel: [ 3.574310] ? __vunmap+0x6d/0xb0 2019-05-31T11:08:23.970574+02:00 linux-ilj4 kernel: [ 3.574314] ? do_init_module+0x5b/0x1e4 2019-05-31T11:08:23.970575+02:00 linux-ilj4 kernel: [ 3.574319] ? load_module+0x18ec/0x1f80 2019-05-31T11:08:23.970575+02:00 linux-ilj4 kernel: [ 3.574324] ? SYSC_finit_module+0xb7/0xd0 2019-05-31T11:08:23.970575+02:00 linux-ilj4 kernel: [ 3.574327] ? SYSC_finit_module+0xb7/0xd0 2019-05-31T11:08:23.970577+02:00 linux-ilj4 kernel: [ 3.574330] ? do_syscall_64+0x7b/0x160 2019-05-31T11:08:23.970578+02:00 linux-ilj4 kernel: [ 3.574334] ? entry_SYSCALL_64_after_hwframe+0x3d/0xa2 Sorry typo accident Created attachment 806836 [details]
boot.msg from NVIDIA geforce RTX 2070 card showing stack trace.
This attachment shows the stack trace after boot with
kernel 4.12.14-lp151.28.4-default , gets kernel NULL pointer dereference during nouveau drm establishment.
The last few function calls are from within drm_kms_helper.
Ross
After doing a new install from the usb .iso on new hardware with AMD 2700X and the NVIDIA geforce RTX 2070. If you select network configuration and updates from update repository, the new kernel 4.12.14-lp151.28.4-default is one of the new updates downloaded and installed. The installation goes as planned with all the graphics working and presenting as expected. The installation finished the system then does its first reboot. After the reboot, the poor user is left with nothing ... but a blank screen! Virtually no indication what has gone on or in what state the machine is in. Not a comfortable or informative state for a new user experience with openSuSE. Even an experienced user is left just wondering what has just happened. I just got trapped with such a scenario with the above installation and I knew about the problem! Ross If the bug I just reported ( https://bugzilla.opensuse.org/show_bug.cgi?id=1137512 ) is a dupe of this, I'd be happy to help investigate further. In particular, I'd be happy to bisect the kernel versions between these two releases to help isolate the offending changes. I suspect this is the same problem. The trick to finding out for sure is have a look at the stack trace. Even though the nouveau driver baffs, with a little bit of luck you might get enough written to the /var/log/boot.msg that will include the stack trace of the Null pointer. If you look for the nouveau establishment announcments, you might see the lines: Call Trace: <4>[ 5.990122] ? drm_dp_dpcd_access+0x69/0xf0 [drm_kms_helper] <4>[ 5.990129] ? drm_dp_dpcd_read+0x2e/0xc0 [drm_kms_helper] <4>[ 5.990137] ? drm_dp_cec_set_edid+0x4e/0x140 [drm_kms_helper] <4>[ 5.990183] ? nouveau_connector_detect+0x1fd/0x440 [nouveau] <4>[ 5.990220] ? nouveau_connector_detect_lvds+0x132/0x180 [nouveau] <4>[ 5.990254] ? nouveau_connector_detect_lvds+0x132/0x180 [nouveau] <4>[ 5.990262] ? drm_helper_probe_single_connector_modes+0xc3/0x6b0 [drm_kms_helper] <4>[ 5.990270] ? __alloc_pages_nodemask+0xda/0x230 <4>[ 5.990278] ? drm_setup_crtcs+0x139/0xa80 [drm_kms_helper] <4>[ 5.990285] ? __drm_fb_helper_initial_config_and_unlock+0x2d/0x400 [drm_kms_helper] <4>[ 5.990293] ? mutex_lock+0xe/0x30 <4>[ 5.990327] ? nouveau_fbcon_init+0x14f/0x1c0 [nouveau] <4>[ 5.990361] ? nouveau_drm_device_init+0x184/0x7f0 [nouveau] <4>[ 5.990396] ? nouveau_drm_probe+0x1eb/0x2b0 [nouveau] this is the stack unwind of the calls leading up to the problem. there are several calls from within drm_kms_helper. plus nouveau_connector_dector calls. This would indicate kernel modeset is involved, with spurious data. Indeed if you set nomodeset you can boot the kernel, but you end up with a screen that is usually in a VGA resolution and not the real functionality you want from the system. Paul if you are happy to undertake a bisect to narrow down the offending problem code by all means do. I suspect part of the problem might be using some of the upstream nouveau driver code without all the required extras. I now have several systems that exhibit the above problem. Unfortunately from a work perspective NVIDIA drivers are used to allow use with various bits of CUDA hardware and software. What I find very frustrating with this bug is that it can affect standard installs, where the newer driver gets downloaded and the resulting system ends with just a blank screen and no other visible information to tell what is going on. I spent several hours the other day looking at Linus' tree following all the updates to the nouveau driver. It might be worth trying one of the more recent kernels with nouveau driver and see if the problem does exist in the upstream code. Ross > Even though the nouveau driver baffs, with a little bit of luck you might get enough written to the /var/log/boot.msg that will include the stack trace of the Null pointer. In my case "/" isn't mounted yet (encrypted LVM partition hasn't been unlocked yet), so I don't expect anything in /var/log to be present. > Paul if you are happy to undertake a bisect to narrow down the offending problem code by all means do. I'd be happy to. I am a software engineer by trade, but I don't have any specific openSUSE or kernel development experience. I assume I can rebuild kernel RPMs locally from source somehow, and do a bisect. Are there any instructions for that? If not, I'll try to figure out something following the instructions here: https://en.opensuse.org/openSUSE:Kernel_git Paul in my case I construct ext4 file systems for /, /var, /usr/local, and /home. Certainly lvm plus encryption adds an extra couple of layers of complications that might get in the way. I do notice even with a blank screen, there is at least some periodic disk activity going on that hopefully allows enough of the data to end up in the file system or at least in journals that can be recovered. There seems to be a number of "problems" that have crept into the nouveau driver. Another annoying habit seems to be "lockups" that occur after the driver has returned from suspend. All in all, this driver is now very unstable. At least under Leap 15.0 it was usable. Now it is very difficult to use for normal expected usage. Not quite fit for purpose! As an alternative NVIDIA propriety drivers could be used, but that does not suit everyone. In terms of building kernels, I will normally compile and install by hand, placing all the components including kernel modules into appropriate places. I don't worry too much about producing rpms. However if you want to share with other people packaged rpms can allow other people to easily test your efforts. Bisects will be good to help narrow down explicit code additions that have caused the issues. However, good old fashioned eye balling the code helps to clarify in your mind as to what is actually happening and intended with the code additions. As I mention earlier I suspect there might be some missing pieces that are necessary with this code that have some how not made it into the blended driver that has come from younger kernel drivers. Please report back any findings and I am sure there will be a few people that a re more than willing to test anything you produce. I have not yet tried a tumbleweed install to see how a more recent kernel behaves with nouveau. Should do this as it has a complete nouveau driver that is from later kernels. The difficulty of cherry picking fixes from later kernels is that there is always a chance that not all of the fixes make it into the back port. Given the range of NVIDIA graphics cards that seem to be affected it should not be too difficult to find a few test environments and people willing to give it a burn. Ross I notice that there appears to be a number of sync problems with the NVIDIA firmware blobs. Getting the right versions of those binaries should be necessary to at least handle some of the clock frequency changes that might be required. Especially in the area with Power Management will adjust clocks to save or match power budget. A number of the freezes associated with a running nouveau driver seem to occur after the system has been in suspend or hibernate. While this is just another problem within the nouveau drm driver it should be addressed. The following warnings occur on booted system with NVIDIA card and nouveau DRM driver. 019-06-01T22:21:29.800857+10:00 red plasmashell[4432]: trying to show an empty dialog 2019-06-01T22:21:30.027741+10:00 red plasmashell[4432]: libpng warning: iCCP: known incorrect sRGB profile 2019-06-01T22:21:31.760431+10:00 red kwin_x11[4426]: qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 16110, resource id: 37748815, major code: 18 (ChangeProperty), minor code: 0 2019-06-01T22:21:32.835597+10:00 red kernel: [ 329.854993] nouveau 0000:01:00.0: Direct firmware load for nouveau/nvcf_fuc084 faile d with error -2 2019-06-01T22:21:32.835621+10:00 red kernel: [ 329.855007] nouveau 0000:01:00.0: Direct firmware load for nouveau/nvcf_fuc084d fail ed with error -2 2019-06-01T22:21:32.835622+10:00 red kernel: [ 329.855009] nouveau 0000:01:00.0: msvld: unable to load firmware data 2019-06-01T22:21:32.835623+10:00 red kernel: [ 329.855011] nouveau 0000:01:00.0: msvld: init failed, -19 2019-06-01T22:21:43.923950+10:00 red plasmashell[4432]: QQuickItem::stackAfter: Cannot stack StatusNotifierItem_QMLTYPE_263(0x55cd33 769d80, parent=0x55cd32c84650, geometry=0,0 0x0) after StatusNotifierItem_QMLTYPE_263(0x55cd3328fe50), which must be a sibling 2019-06-01T22:25:02.856679+10:00 red org.kde.powerdevil.backlighthelper: QDBusArgument: read from a write-only object I also see within the nouveau drm tree that there have been a number of additions to various modesetting changes needed for a number of the NVIDIA cards. I was also reading comments made by Michael Larabel thst point to the need to be using the appropriate firmware binaries when using the nouveau drm driver. An updated firmware configuration should help some GeForce GTX 1000 "Pascal" users with their limited open-source driver support, but the situation remains a mess. Besides the fact of being binary blobs, it's more complicated this time around with the interfaces changing for what is expected by the Nouveau DRM kernel driver. Hitting today in linux-firmware.git were changing the GP102/GP104/GP106/GP107 firmware blobs around the SEC2 RTOS block to point to what's used by the GP108 graphics card. This firmware update/change was needed since the existing signed firmware files weren't working correctly on newer Pascal graphics cards. Usually it's just a matter of overwriting/updating the firmware files, but due to interface breakage, it means an updated kernel DRM driver is needed to properly use the new files and to keep the old files still in the linux-firmware tree as not to regress users on older kernels. The updated DRM kernel driver bits for dealing with the changed SEC2 RTOS firmware interfaces can currently be found in the Nouveau DRM tree maintained by Red Hat's Ben Skeggs. But even with this latest Pascal firmware switching, the open-source Pascal support remains in poor shape... In particular, the same problem plagues Pascal as it does Maxwell/Volta (and ultimately Turing too, but there we're still waiting on the initial firmware files) of not having PMU access with the current firmware images in order to implement proper re-clocking support. As such, all the cards past the GTX 950 series remain very slow with Nouveau due to being stuck to their boot clock frequencies rather than their optimal base/boost clock frequencies. But if/when NVIDIA will help straight out this situation remains to be seen. For now those wanting open-source NVIDIA GPU support are best off with the GeForce GTX 600/700 Kepler series. I tried to follow up on my earlier promise to try and bisect this. Unfortunately I couldn't figure out how to build/install openSUSE kernels from source. I tried following the instructions on the wiki ( https://en.opensuse.org/openSUSE:Kernel_git ), and also the instructions in the packages linked from there; but unfortunately I couldn't past the initial "sequence-patch.sh" step. I'll not pollute the comments on this bug report further, but if folks are able to share either a place which contains RPMs for the intermediate versions, or some getting started guides for building openSUSE kernels; I'd be happy to try again. Seems I have hit the same issue: Kernel command line: BOOT_IMAGE=/vmlinuz-4.12.14-lp151.28.4-default root=UUID=64bb719b-a265-49b8-bde9-4ccf702792ce resume=/dev/disk/by-uuid/e740e737-a332-4f69-8650-ea8e83f17b7b splash=silent quiet showopts jun 11 12:27:18 b-006 kernel: nouveau 0000:01:00.0: bios: M0203T not found jun 11 12:27:18 b-006 kernel: nouveau 0000:01:00.0: bios: M0203E not matched! jun 11 12:27:19 b-006 kernel: nouveau 0000:01:00.0: DRM: VRAM: 512 MiB jun 11 12:27:19 b-006 kernel: nouveau 0000:01:00.0: DRM: GART: 1048576 MiB jun 11 12:27:19 b-006 kernel: nouveau 0000:01:00.0: DRM: TMDS table version 2.0 jun 11 12:27:19 b-006 kernel: nouveau 0000:01:00.0: DRM: DCB version 4.0 jun 11 12:27:19 b-006 kernel: nouveau 0000:01:00.0: DRM: DCB outp 00: 02000300 00000028 jun 11 12:27:19 b-006 kernel: nouveau 0000:01:00.0: DRM: DCB outp 01: 01000302 00000030 jun 11 12:27:19 b-006 kernel: nouveau 0000:01:00.0: DRM: DCB outp 02: 04011310 00000028 jun 11 12:27:19 b-006 kernel: nouveau 0000:01:00.0: DRM: DCB conn 00: 00001030 jun 11 12:27:19 b-006 kernel: nouveau 0000:01:00.0: DRM: DCB conn 01: 00000100 jun 11 12:27:19 b-006 systemd-udevd[208]: worker [253] terminated by signal 9 (KILL) jun 11 12:27:19 b-006 systemd-udevd[208]: worker [253] failed while handling '/devices/pci0000:00/0000:00:01.0/0000:01:00.0' jun 11 12:27:19 b-006 kernel: BUG: unable to handle kernel NULL pointer dereference at (null) jun 11 12:27:19 b-006 kernel: IP: (null) jun 11 12:27:19 b-006 kernel: PGD 0 P4D 0 jun 11 12:27:19 b-006 kernel: Oops: 0010 [#1] SMP PTI jun 11 12:27:19 b-006 kernel: CPU: 1 PID: 253 Comm: systemd-udevd Not tainted 4.12.14-lp151.28.4-default #1 openSUSE Leap 15.1 jun 11 12:27:19 b-006 kernel: Hardware name: Gigabyte Technology Co., Ltd. G31M-ES2L/G31M-S2L, BIOS F10 09/29/2009 jun 11 12:27:19 b-006 kernel: task: ffff88012667c100 task.stack: ffffc90000aac000 jun 11 12:27:19 b-006 kernel: RIP: 0010: (null) jun 11 12:27:19 b-006 kernel: RSP: 0018:ffffc90000aaf7d8 EFLAGS: 00010246 jun 11 12:27:19 b-006 kernel: RAX: 0000000000000000 RBX: 0000000000000020 RCX: ffffc90000aaf86f jun 11 12:27:19 b-006 kernel: RDX: ffff88012667c100 RSI: ffffc90000aaf7e8 RDI: ffff880125931490 jun 11 12:27:19 b-006 kernel: RBP: 0000000000000001 R08: 0000000000000001 R09: ffff88012fc23980 jun 11 12:27:19 b-006 kernel: R10: 0000000000000000 R11: 0000000000000040 R12: 00000000fffffffb jun 11 12:27:19 b-006 kernel: R13: ffff880125931490 R14: 0000000000000000 R15: ffff8801265faa18 jun 11 12:27:19 b-006 kernel: FS: 00007f069a985d40(0000) GS:ffff88012fc80000(0000) knlGS:0000000000000000 jun 11 12:27:19 b-006 kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 jun 11 12:27:19 b-006 kernel: CR2: 0000000000000000 CR3: 0000000126638000 CR4: 00000000000406e0 jun 11 12:27:19 b-006 kernel: Call Trace: jun 11 12:27:19 b-006 kernel: ? drm_dp_dpcd_access+0x69/0xf0 [drm_kms_helper] jun 11 12:27:19 b-006 kernel: ? drm_dp_dpcd_read+0x2e/0xc0 [drm_kms_helper] jun 11 12:27:19 b-006 kernel: ? drm_dp_cec_set_edid+0x4e/0x140 [drm_kms_helper] jun 11 12:27:19 b-006 kernel: ? nouveau_connector_detect+0x1fd/0x440 [nouveau] jun 11 12:27:19 b-006 kernel: ? drm_helper_probe_single_connector_modes+0xc3/0x6b0 [drm_kms_helper] jun 11 12:27:19 b-006 kernel: ? nouveau_connector_force+0x80/0x80 [nouveau] jun 11 12:27:19 b-006 kernel: ? drm_helper_probe_single_connector_modes+0xc3/0x6b0 [drm_kms_helper] jun 11 12:27:19 b-006 kernel: ? drm_setup_crtcs+0x139/0xa80 [drm_kms_helper] jun 11 12:27:19 b-006 kernel: ? __drm_fb_helper_initial_config_and_unlock+0x2d/0x400 [drm_kms_helper] jun 11 12:27:19 b-006 kernel: ? mutex_lock+0xe/0x30 jun 11 12:27:19 b-006 kernel: ? nouveau_fbcon_init+0x14f/0x1c0 [nouveau] jun 11 12:27:19 b-006 kernel: ? nouveau_drm_device_init+0x184/0x7f0 [nouveau] jun 11 12:27:19 b-006 kernel: ? nouveau_drm_probe+0x1eb/0x2b0 [nouveau] jun 11 12:27:19 b-006 kernel: ? __pm_runtime_resume+0x54/0x70 jun 11 12:27:19 b-006 kernel: ? local_pci_probe+0x42/0xa0 jun 11 12:27:19 b-006 kernel: ? pci_device_probe+0x13c/0x160 jun 11 12:27:19 b-006 kernel: ? driver_probe_device+0x2f7/0x440 jun 11 12:27:19 b-006 kernel: ? __driver_attach+0xb8/0xe0 jun 11 12:27:19 b-006 kernel: ? driver_probe_device+0x440/0x440 jun 11 12:27:19 b-006 kernel: ? bus_for_each_dev+0x5e/0x90 jun 11 12:27:19 b-006 kernel: ? bus_add_driver+0x161/0x260 jun 11 12:27:19 b-006 kernel: ? 0xffffffffa0465000 jun 11 12:27:19 b-006 kernel: ? driver_register+0x57/0xc0 jun 11 12:27:19 b-006 kernel: ? 0xffffffffa0465000 jun 11 12:27:19 b-006 kernel: ? do_one_initcall+0x4e/0x190 jun 11 12:27:19 b-006 kernel: ? __vunmap+0x6d/0xb0 jun 11 12:27:19 b-006 kernel: ? __vunmap+0x6d/0xb0 jun 11 12:27:19 b-006 kernel: ? do_init_module+0x5b/0x1e4 jun 11 12:27:19 b-006 kernel: ? load_module+0x18ec/0x1f80 jun 11 12:27:19 b-006 kernel: ? SYSC_finit_module+0xb7/0xd0 jun 11 12:27:19 b-006 kernel: ? SYSC_finit_module+0xb7/0xd0 jun 11 12:27:19 b-006 kernel: ? do_syscall_64+0x7b/0x160 jun 11 12:27:19 b-006 kernel: ? entry_SYSCALL_64_after_hwframe+0x3d/0xa2 jun 11 12:27:19 b-006 kernel: Code: Bad RIP value. jun 11 12:27:19 b-006 kernel: Modules linked in: sr_mod cdrom ata_generic nouveau(+) ata_piix ahci libahci video mxm_wmi wmi i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm drm_panel_orientation_quirks serio_raw ehci_pci uhci_hcd ehc> jun 11 12:27:19 b-006 kernel: CR2: 0000000000000000 jun 11 12:27:19 b-006 kernel: ---[ end trace 608a6e05fc9a8bbd ]--- jun 11 12:27:19 b-006 kernel: RIP: 0010: (null) jun 11 12:27:19 b-006 kernel: RSP: 0018:ffffc90000aaf7d8 EFLAGS: 00010246 jun 11 12:27:19 b-006 kernel: RAX: 0000000000000000 RBX: 0000000000000020 RCX: ffffc90000aaf86f jun 11 12:27:19 b-006 kernel: RDX: ffff88012667c100 RSI: ffffc90000aaf7e8 RDI: ffff880125931490 jun 11 12:27:19 b-006 kernel: RBP: 0000000000000001 R08: 0000000000000001 R09: ffff88012fc23980 jun 11 12:27:19 b-006 kernel: R10: 0000000000000000 R11: 0000000000000040 R12: 00000000fffffffb jun 11 12:27:19 b-006 kernel: R13: ffff880125931490 R14: 0000000000000000 R15: ffff8801265faa18 jun 11 12:27:19 b-006 kernel: FS: 00007f069a985d40(0000) GS:ffff88012fc80000(0000) knlGS:0000000000000000 jun 11 12:27:19 b-006 kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 jun 11 12:27:19 b-006 kernel: CR2: ffffffffffffffd5 CR3: 0000000126638000 CR4: 00000000000406e0 Working: Linux version 4.12.14-lp150.12.61-default Graphics card is: NVidia G98 [GeForce 8400 GS Rev.2] It's a dup of another bug. Please check the test kernel mentioned there later. Thanks. *** This bug has been marked as a duplicate of bug 1136978 *** |