System seizes to function randomly,till i force shut it down

urizen · 2024-12-18 08:20:53

Randomly, the system would seize to function. No mouse events nor keyboard nothing what ever audio that is being played at that time would basically be stuck in a time loop repeating the same frame till I force shutdown and restart.
i ran some journalctl codes and got this
Dec 18 09:05:57 urizen kernel: AMD-Vi: [Firmware Bug]: : No southbridge IOAPIC found
Dec 18 09:05:57 urizen kernel: AMD-Vi: Disabling interrupt remapping
Dec 18 09:05:57 urizen kernel: platform USBC000:00: failed to claim resource 0: [mem 0x6ce7d8c6-0x6ce7e8c5]
Dec 18 09:05:57 urizen kernel: acpi USBC000:00: platform device creation failed: -16
Dec 18 09:05:57 urizen kernel: serial 0000:04:00.1: probe with driver serial failed with error -28
Dec 18 09:05:57 urizen kernel: serial 0000:04:00.2: probe with driver serial failed with error -28
Dec 18 09:05:57 urizen systemd-udevd[395]: /etc/udev/rules.d/42-logitech-unify-permissions.rules:2 Unknown group 'plugdev', ignoring.

it seems to be a known bug of some sort
BIOS Information
Vendor: LENOVO
Version: R0XET73W (1.50 )
Release Date: 12/14/2023

seth · 2024-12-18 09:14:16

what ever audio that is being played at that time would basically be stuck in a time loop repeating

Hallmark of a kernel panic.

i ran some journalctl codes and got

… some random and irrelevant output.

There's some recent noise around amdgpu related issues, https://wiki.archlinux.org/title/Ryzen#Troubleshooting is a permanent issue and you can try to catch a kernel panic w/ https://wiki.archlinux.org/title/Kdump but for now this thread falls into https://bbs.archlinux.org/viewtopic.php?id=57855

ReDress · 2024-12-18 09:35:42

urizen wrote:

Randomly, the system would seize to function. No mouse events nor keyboard nothing what ever audio that is being played at that time would basically be stuck in a time loop repeating the same frame till I force shutdown and restart.
i ran some journalctl codes and got this
Dec 18 09:05:57 urizen kernel: AMD-Vi: [Firmware Bug]: : No southbridge IOAPIC found
Dec 18 09:05:57 urizen kernel: AMD-Vi: Disabling interrupt remapping
Dec 18 09:05:57 urizen kernel: platform USBC000:00: failed to claim resource 0: [mem 0x6ce7d8c6-0x6ce7e8c5]

Happened to me before... on non-AMD hardware. You don't need 'interrupt remapping' for IOMMU to function, though. This usually is a secondary function.

This might be irrelevant but unlike with Intel(Vt-d), which usually is the same hardware component as the CPU, AMD-Vi usually is a different component on the board.

urizen · 2024-12-20 16:00:40

Dec 20 16:55:56 urizen kernel: call_irq_handler: 2.55 No irq handler for vector
Dec 20 16:55:56 urizen kernel: call_irq_handler: 4.55 No irq handler for vector
Dec 20 16:55:56 urizen kernel: call_irq_handler: 6.55 No irq handler for vector
Dec 20 16:55:56 urizen kernel: call_irq_handler: 1.55 No irq handler for vector
Dec 20 16:55:56 urizen kernel: call_irq_handler: 3.55 No irq handler for vector
Dec 20 16:55:56 urizen kernel: call_irq_handler: 5.55 No irq handler for vector
Dec 20 16:55:56 urizen kernel: call_irq_handler: 7.55 No irq handler for vector
Dec 20 16:55:56 urizen kernel: platform USBC000:00: failed to claim resource 0: [mem 0x6ce7d8c6-0x6ce7e8c5]
Dec 20 16:55:56 urizen kernel: acpi USBC000:00: platform device creation failed: -16
Dec 20 16:55:56 urizen kernel: EXT4-fs error (device nvme0n1p5): ext4_orphan_get:1415: comm mount: bad orphan inode 2672967
Dec 20 16:55:56 urizen kernel: ext4_test_bit(bit=2374, block=10485782) = 0
Dec 20 16:55:56 urizen kernel: EXT4-fs error (device nvme0n1p5): ext4_orphan_get:1415: comm mount: bad orphan inode 2006504
Dec 20 16:55:56 urizen kernel: ext4_test_bit(bit=7655, block=7864340) = 0
Dec 20 16:55:56 urizen kernel: EXT4-fs error (device nvme0n1p5): ext4_orphan_get:1415: comm mount: bad orphan inode 1882439
Dec 20 16:55:56 urizen kernel: ext4_test_bit(bit=6470, block=7340053) = 0
Dec 20 16:55:56 urizen kernel: EXT4-fs error (device nvme0n1p5): ext4_orphan_get:1415: comm mount: bad orphan inode 1948687
Dec 20 16:55:56 urizen kernel: ext4_test_bit(bit=7182, block=7340061) = 0
Dec 20 16:55:56 urizen kernel: EXT4-fs error (device nvme0n1p5): ext4_orphan_get:1415: comm mount: bad orphan inode 1883872
Dec 20 16:55:56 urizen kernel: ext4_test_bit(bit=7903, block=7340053) = 0
Dec 20 16:55:56 urizen kernel: EXT4-fs error (device nvme0n1p5): ext4_orphan_get:1415: comm mount: bad orphan inode 1948300
Dec 20 16:55:56 urizen kernel: ext4_test_bit(bit=6795, block=7340061) = 0
Dec 20 16:55:56 urizen kernel: EXT4-fs error (device nvme0n1p5): ext4_orphan_get:1415: comm mount: bad orphan inode 2647322
Dec 20 16:55:56 urizen kernel: ext4_test_bit(bit=1305, block=10485779) = 0
Dec 20 16:55:58 urizen systemd[1]: Failed to start Load the kdump kernel.
Dec 20 16:56:13 urizen bluetoothd[546]: profiles/audio/avdtp.c:try_send() send: Transport endpoint is not connected (107)
Dec 20 16:56:13 urizen bluetoothd[546]: src/service.c:btd_service_connect() a2dp-sink profile connect failed for 14:03:78:8E:53:5D: Input/output error
Dec 20 16:56:33 urizen kwin_wayland[2516]: kwin_libinput: Libinput: event7  - Logitech USB Receiver Mouse: client bug: event processing lagging behind by 60ms, your system is too slow
Dec 20 16:57:25 urizen kwin_wayland[2516]: kwin_libinput: Libinput: event7  - Logitech USB Receiver Mouse: client bug: event processing lagging behind by 30ms, your system is too slow
Dec 20 16:57:28 urizen kwin_wayland[2516]: kwin_libinput: Libinput: event7  - Logitech USB Receiver Mouse: client bug: event processing lagging behind by 21ms, your system is too slow

then this one again
alot of inconsistency in the message logs

Last edited by urizen (2024-12-20 16:37:48)

seth · 2024-12-20 16:28:54

Please use [code][/code] tags. Edit your post in this regard.

alot of inconsistency in the message logs

Because that's just some random lines from the journal, w/o any context or meaning.

From what's there, https://wiki.archlinux.org/title/Solid_ … leshooting - disable APST and use iommu=soft, but essentially we're just looking at a corrupted FS, likely consequence of the hard reboot.

Dec 20 16:55:58 urizen systemd[1]: Failed to start Load the kdump kernel.

Post the /etc/systemd/system/kdump.service you created, nb. that the wiki example contains a bunch of [placeholders] - you cannot just copy and paste that literally but have to substitute them w/ the correct values (or use kdumpst instead)

urizen · 2024-12-20 16:40:08

From what's there, https://wiki.archlinux.org/title/Solid_ … leshooting - disable APST and use iommu=soft, but essentially we're just looking at a corrupted FS, likely consequence of the hard reboot.

hard reboot yh cos of the seizing "functionality", that's the only way to recover of some sort

Post the /etc/systemd/system/kdump.service you created, nb. that the wiki example contains a bunch of [placeholders] - you cannot just copy and paste that literally but have to substitute them w/ the correct values (or use kdumpst instead)

i see
this is what i added

[Unit]
Description=Load the kdump kernel
After=local-fs.target

[Service]
Type=oneshot
RemainAfterExit=true
ExecStart=/usr/bin/kexec -p /boot/vmlinuz-linux-kdump --initrd=/boot/initramfs-linux-kdump.img --append="root=/dev/nvme0n1p5 irqpoll nr_cpus=1 reset_devices"
ExecStop=/usr/bin/kexec -p -u

[Install]
WantedBy=multi-user.target

Last edited by urizen (2024-12-20 19:53:53)

ReDress · 2024-12-23 08:36:20

urizen wrote:

From what's there, https://wiki.archlinux.org/title/Solid_ … leshooting - disable APST and use iommu=soft, but essentially we're just looking at a corrupted FS, likely consequence of the hard reboot.
hard reboot yh cos of the seizing "functionality", that's the only way to recover of some sort

Just a random comment: iommu=soft is most probably not a kernel feature. It's supposed to deal with bugs where some devices are buggy and it bugs entire IOMMU configuration.

seth · 2024-12-23 08:53:25

https://raw.githubusercontent.com/torva … meters.txt

iommu= [X86,EARLY]
off
force
noforce
biomerge
panic
nopanic
merge
nomerge
soft
pt [X86]
nopt [X86]
nobypass [PPC/POWERNV]
Disable IOMMU bypass, using IOMMU for PCI devices.

ReDress · 2024-12-23 09:08:21

It could be BIOS doesn't come with an option to disable IR(Interrupt Remapping) especially with the presumption that all AMD IOMMU come with this feature.

If you plug a device that doesn't work well with this feature it turns into a problem, for instance. That is also presuming the board was working correctly and then you have to disable it via the kernel.

Last edited by ReDress (2024-12-23 09:09:16)

urizen · 2024-12-23 09:09:39

i'm also thinking maybe this has something to do with the logitech mouse i have connected to the pc

ReDress · 2024-12-23 09:16:50

urizen wrote:

i'm also thinking maybe this has something to do with the logitech mouse i have connected to the pc

I've sure seen this hitting graphics drivers and devices but only from a user-space perspective.

Arch Linux

#1 2024-12-18 08:20:53

System seizes to function randomly,till i force shut it down

#2 2024-12-18 09:14:16

Re: System seizes to function randomly,till i force shut it down

#3 2024-12-18 09:35:42

Re: System seizes to function randomly,till i force shut it down

#4 2024-12-20 16:00:40

Re: System seizes to function randomly,till i force shut it down

#5 2024-12-20 16:28:54

Re: System seizes to function randomly,till i force shut it down

#6 2024-12-20 16:40:08

Re: System seizes to function randomly,till i force shut it down

#7 2024-12-23 08:36:20

Re: System seizes to function randomly,till i force shut it down

#8 2024-12-23 08:53:25

Re: System seizes to function randomly,till i force shut it down

#9 2024-12-23 09:08:21

Re: System seizes to function randomly,till i force shut it down

#10 2024-12-23 09:09:39

Re: System seizes to function randomly,till i force shut it down

#11 2024-12-23 09:16:50

Re: System seizes to function randomly,till i force shut it down

Board footer