lkml.org 
[lkml]   [2020]   [Dec]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] x86/irq: Lower unhandled irq error severity
On Tue, Dec 1, 2020, at 01:34, Thomas Gleixner wrote:
> The point is that for some cases this can result in a non working
> machine which just hangs and if it's below the usual loglevel cutoff,
> then it's not visible, which is more annoying than a non-quiet boot if
> you're affected.

For most (desktop) users "errors" will be shown by default, and if anyone is having trouble, they can temporarily remove "quiet" from the kernel command line while debugging it, so it's easy. On the other hand, I don't think it's possible to silence the emergency messages (and I'd still like to see them for any "something is on fire").

The only other use of `pr_emerg_ratelimited` seems to be an informational message shown on non-AMD MCEs ("run mcelog --ascii"). `pr_emerg` is used in more places, but they do sound like critical situations that will bring the system down anyway.

>
> We are looking into a way to mitigate that AMD wreckage, but so far we
> don't even know where exactly this comes from. The reason why we are
> pretty sure that it is a BIOS/Firmware issue is that some people
> reported it to be gone after a BIOS update and quite some machines do
> not have this issue at all.

In my case, it's latest BIOS version available. Could be AGESA-related, maybe we could install a no-op handler for that IRQ?

>
> Just for completeness sake. Can you provide the line in /proc/interrupts
> for irq 7 on that machine?


55: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IR-PCI-MSI 2625543-edge xhci_hcd

PS: I now see that this was reported a lot of times, including e.g. https://lkml.org/lkml/2019/3/6/97.

Thanks,
Laurențiu

\
 
 \ /
  Last update: 2020-12-01 09:20    [W:0.089 / U:0.392 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site