Kernel panic on kernel 6.7-arch3-1 at boot

infitum · 2024-01-19 07:13:35

Hi.
There is an old computer, about 2015 year old, on which there is an arch. After updating the kernel to 6.7-arch3-1, the Kernel panic error appears on subsequent boot (see picture).
The update occurred without errors, rolling back to previous versions of the kernel eliminated the error.
Any ideas on how to win?

Last edited by infitum (2024-01-19 07:28:17)

d.ALT · 2024-01-19 07:50:21

Please post here outputs of:

# cat /proc/cmdline
# cat /etc/fstab
# blkid
# cat /etc/mkinitcpio.conf

infitum wrote:

There is an old computer, about 2015 year old

Didn't know computers were manufactured back in 9 A. D. already ...

infitum · 2024-01-19 08:07:37

d.ALT wrote:

Please post here outputs of:

# cat /proc/cmdline

root=PARTUUID=d1e2ad3f-3f9c-4bca-908f-dfcd79caf22c rw intel_pstate=no_hwp nvidia_drm.modeset=1 initrd=\initramfs-linux.img

# cat /etc/fstab

# Static information about the filesystems.
# See fstab(5) for details.

# <file system> <dir> <type> <options> <dump> <pass>

tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0
# /dev/sda2
UUID=b6992761-1031-46d9-82fc-295d0e047955	/	ext4	rw,relatime	0 1

# /dev/sda1
UUID=D863-155A	/boot	vfat	rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro	0 2

# home
UUID=882992ac-88ea-4b7f-a3d0-2dfa2fe3a6d7	/home	ext4	rw,relatime	0 2

# vbox
UUID=b9ecc815-c219-4050-af63-386ef3853cf4	/vbox	ext4	rw,relatime	0 2

# hdoc
UUID=e7381aee-3781-47e7-a835-25d134b0d0f8	/hdoc	ext4	defaults	0 2

# ntfs
# UUID=C8F4131FF4130EF6	/wnet	ntfs3	defaults,uid=andrey,gid=andrey	0 0

#swap
/home/swapfile	none	swap	defaults,discard	0 0

# blkid

/dev/sdd1: UUID="e7381aee-3781-47e7-a835-25d134b0d0f8" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="9d50a7fc-01"
/dev/sdb1: UUID="882992ac-88ea-4b7f-a3d0-2dfa2fe3a6d7" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="26a76a4e-01"
/dev/sdc1: UUID="b9ecc815-c219-4050-af63-386ef3853cf4" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="VirtulBox" PARTUUID="b96a87a1-14fa-448a-af48-63a657592f46"
/dev/sda2: UUID="b6992761-1031-46d9-82fc-295d0e047955" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="primary" PARTUUID="d1e2ad3f-3f9c-4bca-908f-dfcd79caf22c"
/dev/sda1: UUID="D863-155A" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="EFI" PARTUUID="9aec8a56-f3e6-4522-b8c8-b3293473e41d"

# cat /etc/mkinitcpio.conf

# vim:set ft=sh
# MODULES
# The following modules are loaded before any boot hooks are
# run.  Advanced users may wish to specify all system modules
# in this array.  For instance:
#     MODULES=(usbhid xhci_hcd)
MODULES=()

# BINARIES
# This setting includes any additional binaries a given user may
# wish into the CPIO image.  This is run last, so it may be used to
# override the actual binaries included by a given hook
# BINARIES are dependency parsed, so you may safely ignore libraries
BINARIES=()

# FILES
# This setting is similar to BINARIES above, however, files are added
# as-is and are not parsed in any way.  This is useful for config files.
FILES=()

# HOOKS
# This is the most important setting in this file.  The HOOKS control the
# modules and scripts added to the image, and what happens at boot time.
# Order is important, and it is recommended that you do not change the
# order in which HOOKS are added.  Run 'mkinitcpio -H <hook name>' for
# help on a given hook.
# 'base' is _required_ unless you know precisely what you are doing.
# 'udev' is _required_ in order to automatically load modules
# 'filesystems' is _required_ unless you specify your fs modules in MODULES
# Examples:
##   This setup specifies all modules in the MODULES setting above.
##   No RAID, lvm2, or encrypted root is needed.
#    HOOKS=(base)
#
##   This setup will autodetect all modules for your system and should
##   work as a sane default
#    HOOKS=(base udev autodetect modconf block filesystems fsck)
#
##   This setup will generate a 'full' image which supports most systems.
##   No autodetection is done.
#    HOOKS=(base udev modconf block filesystems fsck)
#
##   This setup assembles a mdadm array with an encrypted root file system.
##   Note: See 'mkinitcpio -H mdadm_udev' for more information on RAID devices.
#    HOOKS=(base udev modconf keyboard keymap consolefont block mdadm_udev encrypt filesystems fsck)
#
##   This setup loads an lvm2 volume group.
#    HOOKS=(base udev modconf block lvm2 filesystems fsck)
#
##   NOTE: If you have /usr on a separate partition, you MUST include the
#    usr and fsck hooks.
HOOKS=(base udev autodetect modconf kms keyboard keymap consolefont block filesystems fsck)

# COMPRESSION
# Use this to compress the initramfs image. By default, zstd compression
# is used. Use 'cat' to create an uncompressed image.
#COMPRESSION="zstd"
#COMPRESSION="gzip"
#COMPRESSION="bzip2"
#COMPRESSION="lzma"
#COMPRESSION="xz"
#COMPRESSION="lzop"
#COMPRESSION="lz4"

# COMPRESSION_OPTIONS
# Additional options for the compressor
#COMPRESSION_OPTIONS=()

# MODULES_DECOMPRESS
# Decompress kernel modules during initramfs creation.
# Enable to speedup boot process, disable to save RAM
# during early userspace. Switch (yes/no).
#MODULES_DECOMPRESS="yes"

d.ALT wrote:

Didn't know computers were manufactured back in 9 A. D. already ...

Sorry for my English, of course I mean, approximately 2015 production )

d.ALT · 2024-01-19 08:25:26

Everything's fine to me... I'd try:

root=UUID=b6992761-1031-46d9-82fc-295d0e047955

Are you EFISTUB booting?

Last edited by d.ALT (2024-01-19 08:25:52)

infitum · 2024-01-19 08:45:24

d.ALT wrote:

Are you EFISTUB booting?

I have rEFInd installed.
# cat /boot/refind_linux.conf

"Boot with standard options"  "root=PARTUUID=d1e2ad3f-3f9c-4bca-908f-dfcd79caf22c rw intel_pstate=no_hwp nvidia_drm.modeset=1"
"Boot to single-user mode"    "root=PARTUUID=d1e2ad3f-3f9c-4bca-908f-dfcd79caf22c rw intel_pstate=no_hwp single"
"Boot with minimal options"   "ro root=UUID=b6992761-1031-46d9-82fc-295d0e047955"

Last edited by infitum (2024-01-19 08:46:42)

d.ALT · 2024-01-19 09:02:51

d.ALT wrote:

I'd try:

root=UUID=b6992761-1031-46d9-82fc-295d0e047955

Also, have a look at the red box Warning: at 4.1.1.1 refind_linux.conf

Wild Penguin · 2024-01-19 09:24:10

If d.ALT's tip doesn't work (worth a try but I think it might not make any difference); post the output of 'ls -l /boot' when /boot is mounted.

Also, post the output of 'df -h', and check the remaining space on the EFI partition. 'lsblk' is also useful in general (it will show the sizes of the partitions).

I'm speculating here, but it is possible /boot was not mounted when the kernel was updated, or that the EFI partition (which you are mounting to /boot) is full. Hence, the initrd was not generated correctly.

Note that it is easy to miss the error messages (which are clear) when doing a pacman -Suy in the output. Pacman itself doesn't error out (IIRC). In Arch, it is much easier to break boot as there is no failsafe for the cases when the kernel update fails for whatever reason (many other distributions keep copies of old Kernels; I'm not implying that would be a better way, since it can quickly take quite a lot of space).

I'm fairly certain this is not caused by a newer kernel version per se, but something has gone wrong during upgrade. Normally, Arch with initrd should not panic when it can not mount root, but drop into an emergency shell - so I strongly suspect there is something wrong with the initrd.

EDIT: In case initrd is missing, a plain "mkinitcpi -P" in the chroot, with /boot mounted would fix it.

Last edited by Wild Penguin (2024-01-19 09:29:53)

V1del · 2024-01-19 09:27:57

I'm with Wild Penguin here, chances are your /boot became full due to the fallout from https://bbs.archlinux.org/viewtopic.php?id=291900

d.ALT · 2024-01-19 09:41:15

V1del wrote:

/boot became full due to the fallout from https://bbs.archlinux.org/viewtopic.php?id=291900

Oh... But, shouldn't the -Syu take care of also upgrading mkinitcpio to "37.2-1"? (it seems I don't fully understood the issue, then... )

V1del · 2024-01-19 10:07:33

While the increase shouldn't be excessive anymore (... the bug was due to incorrect handling of symlinks leading to duplicated firmwares getting stored) there would still be a substantial increase in size on at least the fallback image since that will include new firmware for nouveau (and all other graphics driver kernel modules, but nvidia's GSP firmware is probably the biggest here) if the kms hook is present.

And more generally from the OP it isn't clear whether the update was performed after or before that mkinitcpio version was released.

Last edited by V1del (2024-01-19 10:08:48)

d.ALT · 2024-01-19 10:13:54

V1del wrote:

it isn't clear whether the update was performed after or before that mkinitcpio version was released.

Ah... That's makes sense, indeed. Thanks V1del!

infitum · 2024-01-22 09:32:45

The issue is still actual.

d.ALT wrote:

I'd try:

root=UUID=b6992761-1031-46d9-82fc-295d0e047955

The error remains, only the error message has changed a little, instead of "unknown-block(8,2)" it says "unknown-block(0,0)"

Wild Penguin wrote:

post the output of 'ls -l /boot' when /boot is mounted

drwxr-xr-x 2 root root      4096 Nov 21  2021 76358685d0764fcd840caf40c724a6a3
drwxr-xr-x 7 root root      4096 Nov 22  2021 EFI
-rwxr-xr-x 1 root root 115272864 Jan 21 15:21 initramfs-linux-fallback.img
-rwxr-xr-x 1 root root  52394272 Jan 21 15:21 initramfs-linux.img
-rwxr-xr-x 1 root root   7368704 Nov 14 21:33 intel-ucode.img
drwxr-xr-x 3 root root      4096 Jul  5  2023 loader
-rwxr-xr-x 1 root root       322 Nov  7 01:52 refind_linux.conf
-rwxr-xr-x 1 root root  13001216 Jan 21 15:21 vmlinuz-linux

Wild Penguin wrote:

Also, post the output of 'df -h'

Filesystem      Size  Used Avail Use% Mounted on
/dev/sda2        54G   32G   20G  62% /
/dev/sda1      1022M  181M  842M  18% /boot
/dev/sdb1       440G   59G  359G  15% /home
/dev/sdd1       916G  275G  596G  32% /hdoc
udev            7.8G     0  7.8G   0% /dev
shm             7.8G     0  7.8G   0% /dev/shm
run             7.8G     0  7.8G   0% /run
tmp             7.8G     0  7.8G   0% /tmp
run             7.8G  9.4M  7.8G   1% /etc/resolv.conf

Wild Penguin wrote:

EDIT: In case initrd is missing, a plain "mkinitcpio -P" in the chroot, with /boot mounted would fix it.

My current mkinitcpio version is 37.3-1. The output of "mkinitcpio -P" is

==> Building image from preset: /etc/mkinitcpio.d/linux.preset: 'default'
==> Using configuration file: '/etc/mkinitcpio.conf'
  -> -k /boot/vmlinuz-linux -c /etc/mkinitcpio.conf -g /boot/initramfs-linux.img
==> Starting build: '6.7.0-arch3-1'
  -> Running build hook: [base]
  -> Running build hook: [udev]
  -> Running build hook: [autodetect]
  -> Running build hook: [modconf]
  -> Running build hook: [kms]
  -> Running build hook: [keyboard]
  -> Running build hook: [keymap]
  -> Running build hook: [consolefont]
  -> Running build hook: [block]
  -> Running build hook: [filesystems]
  -> Running build hook: [fsck]
==> Generating module dependencies
==> Creating zstd-compressed initcpio image: '/boot/initramfs-linux.img'
==> Image generation successful
==> Building image from preset: /etc/mkinitcpio.d/linux.preset: 'fallback'
==> Using configuration file: '/etc/mkinitcpio.conf'
  -> -k /boot/vmlinuz-linux -c /etc/mkinitcpio.conf -g /boot/initramfs-linux-fallback.img -S autodetect
==> Starting build: '6.7.0-arch3-1'
  -> Running build hook: [base]
  -> Running build hook: [udev]
  -> Running build hook: [modconf]
  -> Running build hook: [kms]
  -> Running build hook: [keyboard]
  -> Running build hook: [keymap]
  -> Running build hook: [consolefont]
  -> Running build hook: [block]
  -> Running build hook: [filesystems]
  -> Running build hook: [fsck]
==> Generating module dependencies
==> Creating zstd-compressed initcpio image: '/boot/initramfs-linux-fallback.img'
==> Image generation successful

Last edited by infitum (2024-01-22 09:36:01)

seth · 2024-01-22 10:00:28

Do you get away w/ the "rootwait" kernelparameter?
Is there more context before the kernel panic?
What's the plan with "intel_pstate=no_hwp"?
Do you get bus/device related errors/warnings on the older kernels?
Is sda SATA, nvme or USB?

infitum · 2024-01-29 12:45:10

The issue is still actual.
As a temporary solution, the linux-lts kernel was installed

seth wrote:

Is there more context before the kernel panic?

yes, there was a message at the top of the output:

Intiramfs unpacking failed: invalid magic as start of compressed

And after that there were many messages like:

ACPI Error: Aborting method \_SB.PCI0.SAT0.SPT0._GTF due to previous error (AE_NOT_FOUND) (20230628/psparse-529)
ACPI BIOS Error (bug): Could not resolve symbol [\_SB.PCI0.SAT0.SPT0._GTF.DSSP], AE_NOT_FOUND (20230628/psargs-330)

Because of which the first message was not immediately seen.
Searching the forums for problems with this error "Intiramfs unpacking failed" did not yield any results in my case.

seth wrote:

Do you get bus/device related errors/warnings on the older kernels?

no informative messages

seth wrote:

Is sda SATA, nvme or USB?

sata

seth wrote:

Do you get away w/ the "rootwait" kernelparameter?
What's the plan with "intel_pstate=no_hwp"?

The presence or absence of these parameters does not produce the result.

seth · 2024-01-29 16:13:38

Intiramfs unpacking failed: invalid magic as start of compressed

There've been multiple reports itr.
https://bbs.archlinux.org/viewtopic.php … 0#p2140590
Alternatively make sure you're not running out of space on the /boot partition - the recent addition of nouveau firmware has pot. bloated the initramfs considerably.

Edit: https://bbs.archlinux.org/viewtopic.php?id=290093
Alternatively try to use the "-z lz4" option w/ mkinitcpio, https://bbs.archlinux.org/viewtopic.php … 2#p2140702

Last edited by seth (2024-01-29 16:19:27)

Spoffy · 2024-01-29 21:28:15

infitum wrote:

The issue is still actual.
As a temporary solution, the linux-lts kernel was installed

Ran into a similar issue with a kernel panic on boot after updating.

linux-lts also worked as a temporary workaround for now, thanks for the suggestion/information.

infitum · 2024-02-04 19:31:42

By scientific poking method, the following result was obtained.
The current linux 6.7.3.arch1-2 kernel and its image initramfs-linux.img are considered.
If the /usr/lib/firmware/nvidia/ga102/gsp/ and /usr/lib/firmware/nvidia/tu102/gsp/ folders manually delete from the initramfs-linux.img archive, then the system boots without the issue.

V1del · 2024-02-04 19:53:42

So it is the problem we linked.

Edit your /etc/mkinitcpio.conf and remove kms from the HOOKS line and instead add the kernel module of the module you actually neef to the MODULES line

infitum · 2024-02-04 20:28:19

V1del wrote:

So it is the problem we linked.

Was it this link?

V1del wrote:

I'm with Wild Penguin here, chances are your /boot became full due to the fallout from https://bbs.archlinux.org/viewtopic.php?id=291900

seth · 2024-02-04 20:54:50

The problem with that is

/dev/sda1 1022M 181M 842M 18% /boot

Nevertheless the firmware will bloat the initramfs considerably, increasing the RAM demand when decompressing it

Another aspect is

manually delete from the initramfs-linux.img archive

How exactly did you go about that?
What happens if you add a 250MB spacer to the initramfs?

dd if=/dev/zero of=zero.spacer count=500k

will generate that, use the FILES array and use the absolute path where you put that file.
Being all 0, it should compress into nothingness but will increase the RAM demand on decompression.

infitum · 2024-02-04 21:31:01

seth wrote:

Nevertheless the firmware will bloat the initramfs considerably, increasing the RAM demand when decompressing it

My boot partition now:

total 296724
drwxr-xr-x  5 root root      4096 Jan  1  1970 .
drwxr-xr-x 19 root root      4096 Feb  4 18:14 ..
drwxr-xr-x  2 root root      4096 Nov 21  2021 76358685d0764fcd840caf40c724a6a3
drwxr-xr-x  7 root root      4096 Nov 22  2021 EFI
-rwxr-xr-x  1 root root 117449111 Feb  4 23:16 initramfs-linux-fallback.img
-rwxr-xr-x  1 root root  12805899 Feb  4 23:40 initramfs-linux.img
-rwxr-xr-x  1 root root  52418658 Feb  4 23:32 initramfs-linux.img.bak
-rwxr-xr-x  1 root root  75325386 Feb  4 23:16 initramfs-linux-lts-fallback.img
-rwxr-xr-x  1 root root  12506867 Feb  4 23:15 initramfs-linux-lts.img
-rwxr-xr-x  1 root root   7368704 Feb  1 21:16 intel-ucode.img
drwxr-xr-x  3 root root      4096 Jul  5  2023 loader
-rwxr-xr-x  1 root root       343 Feb  4 20:42 refind_linux.conf
-rwxr-xr-x  1 root root       322 Feb  4 18:18 refind_linux.conf.bat
-rwxr-xr-x  1 root root  13029888 Feb  4 23:15 vmlinuz-linux
-rwxr-xr-x  1 root root  12895200 Feb  4 23:15 vmlinuz-linux-lts

I think the changes in image sizes from here are clear.
My system:

                   -`                    
                  .o+`                   --------------- 
                 `ooo/                   OS: Arch Linux x86_64 
                `+oooo:                  Kernel: 6.7.3-arch1-2 
               `+oooooo:                 Uptime: 2 hours, 26 mins 
               -+oooooo+:                Packages: 1013 (pacman) 
             `/:-:++oooo+:               Shell: bash 5.2.26 
            `/++++/+++++++:              Resolution: 1280x1024, 1920x1080 
           `/++++++++++++++:             DE: GNOME 45.3 
          `/+++ooooooooooooo/`           WM: Mutter 
         ./ooosssso++osssssso+`          WM Theme: Adwaita 
        .oossssso-````/ossssss+`         Theme: Adwaita [GTK2/3] 
       -osssssso.      :ssssssso.        Icons: Adwaita [GTK2/3] 
      :osssssss/        osssso+++.       Terminal: gnome-terminal 
     /ossssssss/        +ssssooo/-       CPU: Intel i7-2600K (8) @ 3.800GHz 
   `/ossssso+/:-        -:/+osssso+-     GPU: NVIDIA GeForce GT 710 
  `+sso+:-`                 `.-/+oso:    Memory: 6141MiB / 15963MiB 
 `++:.                           `-/+/
 .`                                 `/

seth wrote:

Another aspect is
manually delete from the initramfs-linux.img archive
How exactly did you go about that?

A standard archiver was used.
Now I’ll try to make these settings when I understand which modules I need to specify.

V1del wrote:

Edit your /etc/mkinitcpio.conf and remove kms from the HOOKS line and instead add the kernel module of the module you actually neef to the MODULES line

seth · 2024-02-04 22:14:37

"nouveau" or https://wiki.archlinux.org/title/NVIDIA#Early_loading or you just skip that entirely for the moment.

I can see three things going on:
1. the firmware bloated the initramfs and you ran out of /boot partition (unlikely)
2. the firmware bloated the initramfs and you ran into bad RAM
3. you rewrote the initrfamfs w/ a different archiver/under different circumstances and that "sanitized" it

Adding a spacer via the FILES() array would run you into 2
Just rewriting the initramfs w/ your "standard archiver" (whatever tf that is…) would fix it regardless of its size

infitum · 2024-02-04 22:47:37

seth wrote:

I can see three things going on:
1. the firmware bloated the initramfs and you ran out of /boot partition (unlikely)
2. the firmware bloated the initramfs and you ran into bad RAM
3. you rewrote the initrfamfs w/ a different archiver/under different circumstances and that "sanitized" it
Adding a spacer via the FILES() array would run you into 2
Just rewriting the initramfs w/ your "standard archiver" (whatever tf that is…) would fix it regardless of its size

I'll definitely check it out. But I think the main cause of the problem is in my video card, or more precisely in its drivers.
Let's look at the contents of the folders removed from the image; they contain the same list of files:

total 25756
drwxr-xr-x 2 andrey andrey     4096 Feb  4 23:55 .
drwxr-xr-x 3 andrey andrey     4096 Feb  5 02:13 ..
-rw-r--r-- 1 andrey andrey    33114 Jan  1  1970 booter_load-535.113.01.bin.zst
-rw-r--r-- 1 andrey andrey    18906 Jan  1  1970 booter_unload-535.113.01.bin.zst
-rw-r--r-- 1 andrey andrey    16463 Jan  1  1970 bootloader-535.113.01.bin.zst
-rw-r--r-- 1 andrey andrey 26287047 Jan  1  1970 gsp-535.113.01.bin.zst

535.113.01 is a driver version for nvidia card, which is not suitable for my card. I need 470.223.02
Although yes, these folders increase the size of the image three times.

seth · 2024-02-04 22:52:40

The firmware is for nouveau, not nvidia.

lspci -k

infitum · 2024-02-04 22:56:50

lspci -k

00:00.0 Host bridge: Intel Corporation 2nd Generation Core Processor Family DRAM Controller (rev 09)
	Subsystem: ASUSTeK Computer Inc. P8P67/P8H67 Series Motherboard
	Kernel driver in use: snb_uncore
00:01.0 PCI bridge: Intel Corporation Xeon E3-1200/2nd Generation Core Processor Family PCI Express Root Port (rev 09)
	Subsystem: ASUSTeK Computer Inc. Xeon E3-1200/2nd Generation Core Processor Family PCI Express Root Port
	Kernel driver in use: pcieport
00:16.0 Communication controller: Intel Corporation 6 Series/C200 Series Chipset Family MEI Controller #1 (rev 04)
	Subsystem: ASUSTeK Computer Inc. P8 series motherboard
	Kernel driver in use: mei_me
	Kernel modules: mei_me
00:19.0 Ethernet controller: Intel Corporation 82579V Gigabit Network Connection (rev 05)
	DeviceName:  Onboard LAN
	Subsystem: ASUSTeK Computer Inc. P8P67 Deluxe Motherboard
	Kernel driver in use: e1000e
	Kernel modules: e1000e
00:1a.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #2 (rev 05)
	Subsystem: ASUSTeK Computer Inc. P8 series motherboard
	Kernel driver in use: ehci-pci
00:1b.0 Audio device: Intel Corporation 6 Series/C200 Series Chipset Family High Definition Audio Controller (rev 05)
	Subsystem: ASUSTeK Computer Inc. 6 Series/C200 Series Chipset Family High Definition Audio Controller
	Kernel driver in use: snd_hda_intel
	Kernel modules: snd_hda_intel
00:1c.0 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 1 (rev b5)
	Subsystem: ASUSTeK Computer Inc. P8 series motherboard
	Kernel driver in use: pcieport
00:1c.1 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 2 (rev b5)
	Subsystem: ASUSTeK Computer Inc. 6 Series/C200 Series Chipset Family PCI Express Root Port 2
	Kernel driver in use: pcieport
00:1c.4 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 5 (rev b5)
	Subsystem: ASUSTeK Computer Inc. 6 Series/C200 Series Chipset Family PCI Express Root Port 5
	Kernel driver in use: pcieport
00:1c.6 PCI bridge: Intel Corporation 82801 PCI Bridge (rev b5)
	Subsystem: ASUSTeK Computer Inc. P8 series motherboard
	Kernel driver in use: pcieport
00:1d.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #1 (rev 05)
	Subsystem: ASUSTeK Computer Inc. P8 series motherboard
	Kernel driver in use: ehci-pci
00:1f.0 ISA bridge: Intel Corporation Z68 Express Chipset LPC Controller (rev 05)
	Subsystem: ASUSTeK Computer Inc. Z68 Express Chipset LPC Controller
	Kernel driver in use: lpc_ich
	Kernel modules: lpc_ich
00:1f.2 SATA controller: Intel Corporation 6 Series/C200 Series Chipset Family 6 port Desktop SATA AHCI Controller (rev 05)
	Subsystem: ASUSTeK Computer Inc. P8 series motherboard
	Kernel driver in use: ahci
00:1f.3 SMBus: Intel Corporation 6 Series/C200 Series Chipset Family SMBus Controller (rev 05)
	Subsystem: ASUSTeK Computer Inc. P8 series motherboard
	Kernel driver in use: i801_smbus
	Kernel modules: i2c_i801
01:00.0 VGA compatible controller: NVIDIA Corporation GK208B [GeForce GT 710] (rev a1)
	Subsystem: ASUSTeK Computer Inc. GK208B [GeForce GT 710]
	Kernel driver in use: nvidia
	Kernel modules: nouveau, nvidia_drm, nvidia
01:00.1 Audio device: NVIDIA Corporation GK208 HDMI/DP Audio Controller (rev a1)
	Subsystem: ASUSTeK Computer Inc. GK208 HDMI/DP Audio Controller
	Kernel driver in use: snd_hda_intel
	Kernel modules: snd_hda_intel
03:00.0 USB controller: ASMedia Technology Inc. ASM1042 SuperSpeed USB Host Controller
	Subsystem: ASUSTeK Computer Inc. P8B WS Motherboard
	Kernel driver in use: xhci_hcd
	Kernel modules: xhci_pci
04:00.0 USB controller: ASMedia Technology Inc. ASM1042 SuperSpeed USB Host Controller
	Subsystem: ASUSTeK Computer Inc. P8B WS Motherboard
	Kernel driver in use: xhci_hcd
	Kernel modules: xhci_pci
05:00.0 PCI bridge: ASMedia Technology Inc. ASM1083/1085 PCIe to PCI Bridge (rev 01)
	Subsystem: ASMedia Technology Inc. ASM1083/1085 PCIe to PCI Bridge

Arch Linux

#1 2024-01-19 07:13:35

Kernel panic on kernel 6.7-arch3-1 at boot

#2 2024-01-19 07:50:21

Re: Kernel panic on kernel 6.7-arch3-1 at boot

#3 2024-01-19 08:07:37

Re: Kernel panic on kernel 6.7-arch3-1 at boot

#4 2024-01-19 08:25:26

Re: Kernel panic on kernel 6.7-arch3-1 at boot

#5 2024-01-19 08:45:24

Re: Kernel panic on kernel 6.7-arch3-1 at boot

#6 2024-01-19 09:02:51

Re: Kernel panic on kernel 6.7-arch3-1 at boot

#7 2024-01-19 09:24:10

Re: Kernel panic on kernel 6.7-arch3-1 at boot

#8 2024-01-19 09:27:57

Re: Kernel panic on kernel 6.7-arch3-1 at boot

#9 2024-01-19 09:41:15

Re: Kernel panic on kernel 6.7-arch3-1 at boot

#10 2024-01-19 10:07:33

Re: Kernel panic on kernel 6.7-arch3-1 at boot

#11 2024-01-19 10:13:54

Re: Kernel panic on kernel 6.7-arch3-1 at boot

#12 2024-01-22 09:32:45

Re: Kernel panic on kernel 6.7-arch3-1 at boot

#13 2024-01-22 10:00:28

Re: Kernel panic on kernel 6.7-arch3-1 at boot

#14 2024-01-29 12:45:10

Re: Kernel panic on kernel 6.7-arch3-1 at boot

#15 2024-01-29 16:13:38

Re: Kernel panic on kernel 6.7-arch3-1 at boot

#16 2024-01-29 21:28:15

Re: Kernel panic on kernel 6.7-arch3-1 at boot

#17 2024-02-04 19:31:42

Re: Kernel panic on kernel 6.7-arch3-1 at boot

#18 2024-02-04 19:53:42

Re: Kernel panic on kernel 6.7-arch3-1 at boot

#19 2024-02-04 20:28:19

Re: Kernel panic on kernel 6.7-arch3-1 at boot

#20 2024-02-04 20:54:50

Re: Kernel panic on kernel 6.7-arch3-1 at boot

#21 2024-02-04 21:31:01

Re: Kernel panic on kernel 6.7-arch3-1 at boot

#22 2024-02-04 22:14:37

Re: Kernel panic on kernel 6.7-arch3-1 at boot

#23 2024-02-04 22:47:37

Re: Kernel panic on kernel 6.7-arch3-1 at boot

#24 2024-02-04 22:52:40

Re: Kernel panic on kernel 6.7-arch3-1 at boot

#25 2024-02-04 22:56:50

Re: Kernel panic on kernel 6.7-arch3-1 at boot

Board footer