Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
FS#79195 - Slow boot Since 2-3 last kernels updates.
Attached to Project:
Arch Linux
Opened by Guy B (sushi2503) - Tuesday, 25 July 2023, 07:39 GMT
Last edited by Toolybird (Toolybird) - Tuesday, 25 July 2023, 22:14 GMT
Opened by Guy B (sushi2503) - Tuesday, 25 July 2023, 07:39 GMT
Last edited by Toolybird (Toolybird) - Tuesday, 25 July 2023, 22:14 GMT
|
DetailsHello,
Since 2-3 last kernel updates the transition between the end of the bios screen and the systemd-boot countdown screen is slow. It's like the kernel is searching the root partition (blinking underscore for a few seconds) and then the boot starts. Yesterday by the last kernel update I went in the BIOS to check the boot order priority (which was right) and clicked on linux boot manager to boot and after the boot completed I saw this in the logs : jui 24 20:56:47 Cockpit kernel: software IO TLB: area num 16. jui 24 20:56:47 Cockpit kernel: BUG: Bad page state in process swapper pfn:22d4c7 jui 24 20:56:47 Cockpit kernel: page:(____ptrval____) refcount:0 mapcount:0 mapping:(____ptrval____) index:0xbf000000000000 pfn:0x22d4c7 jui 24 20:56:47 Cockpit kernel: memcg:20000000000000 jui 24 20:56:47 Cockpit kernel: invalid mapping:00af000000000000 jui 24 20:56:47 Cockpit kernel: flags: 0x23eff0000000000(node=0|zone=2|lastcpupid=0x3eff) jui 24 20:56:47 Cockpit kernel: page_type: 0xffffffff() jui 24 20:56:47 Cockpit kernel: raw: 023eff0000000000 ff3eeeedc8b531c8 ffefeeedc8b531c8 00af000000000000 jui 24 20:56:47 Cockpit kernel: raw: 00bf000000000000 0002000000000000 00000000ffffffff 0020000000000000 jui 24 20:56:47 Cockpit kernel: page dumped because: page still charged to cgroup jui 24 20:56:47 Cockpit kernel: Modules linked in: jui 24 20:56:47 Cockpit kernel: CPU: 0 PID: 0 Comm: swapper Not tainted 6.4.5-arch1-1 #1 3c9b257d67a253272ac52bb586b7a35c5448601c jui 24 20:56:47 Cockpit kernel: Hardware name: Gigabyte Technology Co., Ltd. B360M-D3H/B360M D3H-CF, BIOS F15 11/05/2021 jui 24 20:56:47 Cockpit kernel: Call Trace: jui 24 20:56:47 Cockpit kernel: <TASK> jui 24 20:56:47 Cockpit kernel: dump_stack_lvl+0x47/0x60 jui 24 20:56:47 Cockpit kernel: bad_page+0x71/0x100 jui 24 20:56:47 Cockpit kernel: __free_pages_ok+0x45e/0x540 jui 24 20:56:47 Cockpit kernel: memblock_free_all+0x1c5/0x260 jui 24 20:56:47 Cockpit kernel: mem_init+0x1b/0x240 jui 24 20:56:47 Cockpit kernel: mm_core_init+0xa5/0x3d0 jui 24 20:56:47 Cockpit kernel: start_kernel+0x471/0xa90 jui 24 20:56:47 Cockpit kernel: x86_64_start_reservations+0x18/0x30 jui 24 20:56:47 Cockpit kernel: x86_64_start_kernel+0x96/0xa0 jui 24 20:56:47 Cockpit kernel: secondary_startup_64_no_verify+0x10b/0x10b jui 24 20:56:47 Cockpit kernel: </TASK> jui 24 20:56:47 Cockpit kernel: Disabling lock debugging due to kernel taint jui 24 20:56:47 Cockpit kernel: Memory: 16019456K/16502612K available (16384K kernel code, 2120K rwdata, 12768K rodata, 3344K init, 3992K bss, 478800K reserved, 0K cma-reserved) jui 24 20:56:47 Cockpit kernel: SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=12, Nodes=1 jui 24 20:56:47 Cockpit kernel: Kernel/User page tables isolation: enabled jui 24 20:56:47 Cockpit kernel: ftrace: allocating 47545 entries in 186 pages jui 24 20:56:47 Cockpit kernel: ftrace: allocated 186 pages with 5 groups jui 24 20:56:47 Cockpit kernel: Dynamic Preempt: full I saw this bug logs only on this reboot. I had even the case that few times the OS went back to the BIOS. I was thinking that it was hardware related and dismount the nvme disk from the PCIe adapted in case of a bad contact but no change since. Steps to reproduce: Boot normally. Thanks for any help. P.S. Let me know if any info is needed. |
This task depends upon
Closed by Toolybird (Toolybird)
Tuesday, 25 July 2023, 22:14 GMT
Reason for closing: Not a bug
Additional comments about closing: See comments
Tuesday, 25 July 2023, 22:14 GMT
Reason for closing: Not a bug
Additional comments about closing: See comments
Surely that means you are still in the boot loader? Please clarify.
If so, the kernel hasn't even come into play yet? If that's the case, your kernel issue logged in the journal is possibly something different.
> had even the case that few times the OS went back to the BIOS. I was thinking that it was hardware related
Hardware definitely seems a bit suss...
Seeing as there is no identifiable Arch packaging bug here, this actually belongs in the proper Arch support channels (Forum/IRC/Mailing Lists/Reddit/etc)
Sorry for the delay (busy day) but I found the issue. For an unknown reason (computing mystery) the boot device in the BIOS has been changed and setting the right one makes the boot working again without delay. I have no Idea why !
Sorry for the inconvenience.