Description of problem: Fills system partition. Workaround: use previous kernel. From forum https://forums.mageia.org/en/viewtopic.php?t=14701 I asked that user to issue a bug here, but as it may be critical for other users experiencing this, I issued it now, and posting back the link.
CC: (none) => davidwhodgins
My searching on the error indicates it's hardware problem. The kernel update just made it get reported instead of silently ignored. From https://forums.unraid.net/topic/103901-solved-aer-pcie-bus-errors/ Try adding "pcie_aspm=off" (without the quotes) to the kernel boot parameter. https://wiki.mageia.org/en/How_to_set_up_kernel_options
Is it possible to get it not swamp the log? Because that *is* a problem for normal users - making system crash, unbootable.
sojkovec reported that adding pcie_aspm=off as a workaround is working. Unlike syslog, journald does limit how much space it will use. From "man journald.conf" ... SystemMaxUse= and RuntimeMaxUse= control how much disk space the journal may use up at most. SystemKeepFree= and RuntimeKeepFree= control how much disk space systemd-journald shall leave free for other uses. systemd-journald will respect both limits and use the smaller of the two values. The first pair defaults to 10% and the second to 15% of the size of the respective file system, but each value is capped to 4G.
OK good, so this problem should not be critical
Severity: critical => normalSummary: kernel 5.15.62 regression - snd_hda_intel PCI error repeatedly, fills log quickly => kernel 5.15.62 change - report snd_hda_intel PCI error repeatedly, feeds log fast
Whiteboard: (none) => WORKAROUND
Keep in mind, rsyslog should be strongly discouraged. When asking for logs as them to use "journalctl -b --no-hostname" in a terminal such as konsole. I have 64GB for my root partition so 10% is too large making the journalctl command quite slow. I reduce it using ... $ grep -v -e ^'#' -e ^$ /etc/systemd/journald.conf [Journal] SystemMaxUse=200M RuntimeMaxUse=200M ForwardToSyslog=yes ForwardToConsole=yes TTYPath=/dev/tty12 For me, that's around 30 days retention.
This issue will be fixed in next kernel update as the problematic change is reverted upstream. While the change was technically correct it needs more checks as the "wrong change" it fixed dates back to 2.6.36-rc4 so it needs a bit more work as many systems trips over it due to buggy hw/bios/firmware implementations...
Depends on: (none) => 30813
Depends on: (none) => 30814
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2022-0324.html
Status: NEW => RESOLVEDResolution: (none) => FIXED