|
Bugzilla – Full Text Bug Listing |
| Summary: | Leap 15.6 Linux 6.4.0.150600.23.7 boot hanger; former Linux ~.21 works | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE Distribution | Reporter: | Peter Thoms <p.thoms> |
| Component: | Kernel | Assignee: | openSUSE Kernel Bugs <kernel-bugs> |
| Status: | RESOLVED FIXED | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | meissner, mrmazda, msuchanek, p.thoms, tiwai |
| Version: | Leap 15.6 | Flags: | tiwai:
needinfo?
(p.thoms) |
| Target Milestone: | --- | ||
| Hardware: | x86-64 | ||
| OS: | Other | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: |
sudo inxi -Fxz
/var/log/warn Boot hanger between "Rescue Mode" and "end of listing" Screenshot Screenshot "3" instead of nomodeset: screenshot log of first start today first start today dsmg kdump, only man start posible |
||
|
Description
Peter Thoms
2024-06-28 10:02:00 UTC
When this boot completes, does Alt-F3 bring you to another login prompt? If yes and you login as root, what results from 'systemctl restart xdm'? Note Bugzilla is not intended to be a support forum. A report like this should be directed to https://forums.opensuse.org/c/english/install-boot-login/18 or the mailing list archived at https://lists.opensuse.org/archives/list/support@lists.opensuse.org/. Also details are needed, such as PC specifications, your GPU in particular, and details of the update process you employed. Hello Felix. -> Alt + F3 is inactive Created attachment 875779 [details]
sudo inxi -Fxz
sudo inxi -Fxz
Hello, recovery mode works. Boot hanger short after enter "exit" of recovery mode. Created attachment 875783 [details]
/var/log/warn
Created attachment 875784 [details]
Boot hanger between "Rescue Mode" and "end of listing"
Boot hanger between "Rescue Mode" and "end of listing"
Created attachment 875785 [details]
Screenshot
Exit Rescue Mode: running into the hanger
Created attachment 875786 [details]
Screenshot
Exit Rescue Mode: running into the hanger
When you boot with "nomodeset" boot option, does the new kernel boot? Starting with nomodeset: mobile mouse pointer at a black screen, also a boot hanger. OK, then please try to boot without GUI, i.e. in runlevel 3 (pass "3" to boot option). Can you login there? via recovery mode of linux ~23.7? Please, give the command line. Ahh: I added "pass=3", instead of "nomodeset" The login screen started. After entering my password the password dummys went into light grey and the screen freezes into a hanger. After hanging with "3" boot option, can you try to reboot with the following key combo? Alt-Sysrq-S Alt-Sysrq-B ?? Sysrq key is often mapped as "Print" (or "Druck") key. And after rebooting from that, please check the kernel messages of the previous boot, usually recorded in /var/log/messages. There can be some leftover stack traces, and that would be more interesting. (In reply to Peter Thoms from comment #13) > Ahh: > I added "pass=3", instead of "nomodeset" It should not be "pass=3", only "3". Created attachment 875943 [details]
"3" instead of nomodeset: screenshot
"3" instead of nomodeset: screenshot of behavior
(In reply to Peter Thoms from comment #16) > Created attachment 875943 [details] > "3" instead of nomodeset: screenshot > > "3" instead of nomodeset: screenshot of behavior The screenshot shows some piece of crash messages. And now we need the whole crash messages. Could you try to get it from the previous kernel boot log after the reset? I am very sorry. I tried under the folder /var/logs/..all messages but can not find anything we see on the last screenshot. Please give me an further advice, so I will try again until tomorrow. Doesn't your /var/log/messages file contain any the trace of kernel crashes in the previous sessions at all? No, maybe the part before the crash. I need expanded Timestamp to differ. Tomorrow I will try again and have a better focus at the timestamp. Created attachment 875956 [details]
log of first start today
file log of first start today option "3"
Created attachment 875957 [details]
first start today
file log of first start today option "3"
I tryed to get the messages of first start via live cd (knoppix) but var was shown as empty If /var/log/messages doesn't contain the kernel crash messages, you'd need to set up kdump to catch the crash instead. Try to install via yast2-kdump. It might be better to provide more RAM size than suggested there, to be sure. After setting up kdump, you can verify whether the crash dump works via alt-sysrq-C key combo. Boot with the previous kernel (that should still works), test the key combo and check whether you got the crash dump at /var/crash/*. If this looks working, boot with the new kernel. The kernel crash should be triggered automatically at crashing. If crash dump worked for the new kernel (at crashing), please upload the dmesg output found in the corresponding /var/crash/* directory. Created attachment 875958 [details]
dsmg kdump, only man start posible
kdump of crash, man. start
Linux started via grub, no editing of grub menu
Thanks! Now it shows a clear crash stack trace: [ 9.434527] e1000e 0000:00:19.0 eth0: NIC Link is Up 100 Mbps Half Duplex, Flow Control: Rx/Tx [ 9.434545] BUG: scheduling while atomic: kworker/2:0/30/0x00000002 (snip) [ 9.434638] CPU: 2 PID: 30 Comm: kworker/2:0 Kdump: loaded Tainted: G n 6.4.0-150600.23.7-default #1 SLE15-SP6 128952646fcb1614c051ed5f88ec9aef64f90f32 [ 9.434641] Hardware name: FUJITSU ESPRIMO P520/D3220-A1, BIOS V4.6.5.4 R1.46.0 for D3220-A1x 08/29/2018 [ 9.434642] Workqueue: events e1000_watchdog_task [e1000e] [ 9.434662] Call Trace: [ 9.434664] <TASK> [ 9.434666] dump_stack_lvl+0x57/0x80 [ 9.434670] __schedule_bug+0x56/0x70 [ 9.434674] __schedule+0x1146/0x1540 [ 9.434678] ? wakeup_preempt+0x29/0x60 [ 9.434681] ? ttwu_do_activate+0x5d/0x1e0 [ 9.434683] ? try_to_wake_up+0x408/0x5e0 [ 9.434685] schedule+0x24/0xb0 [ 9.434688] schedule_hrtimeout_range_clock+0xa8/0x120 [ 9.434691] ? __pfx_hrtimer_wakeup+0x10/0x10 [ 9.434696] usleep_range_state+0x5b/0x90 [ 9.434698] e1000e_read_phy_reg_mdic.part.3+0x7e/0x240 [e1000e 867f7757ca0e3d2299c7f92537e261b634b24512] [ 9.434713] e1000e_update_stats+0x4c4/0x6e0 [e1000e 867f7757ca0e3d2299c7f92537e261b634b24512] [ 9.434725] e1000_watchdog_task+0x157/0x890 [e1000e 867f7757ca0e3d2299c7f92537e261b634b24512] [ 9.434739] ? vfree+0x17b/0x2d0 [ 9.434742] process_one_work+0x226/0x440 [ 9.434745] worker_thread+0x2a/0x3b0 [ 9.434748] ? __pfx_worker_thread+0x10/0x10 [ 9.434750] kthread+0xe1/0x120 [ 9.434752] ? __pfx_kthread+0x10/0x10 [ 9.434753] ret_from_fork+0x2c/0x50 [ 9.434756] </TASK> And this looks like the bug that was recently fixed (in the upstream commit 387f295cb2150ed164905b648d76dfcbd3621778). The fix has been already backported to SLE15-SP6 git branch. Could you test the latest kernel in OBS Kernel:SLE15-SP6 repo? http://download.opensuse.org/repositories/Kernel:/SLE15-SP6/pool/ When I get command line support, I can try. It works, thank you very much! Command line: zypper addrepo http://download.opensuse.org/repositories/Kernel:/SLE15-SP6/pool/ zypper refresh zypper install kernel-default-6.4.0-150600.251.1.g567c8c9.x86_64 Peter |