linux-kernel - Re: `do_IRQ: 1.55 No irq handler for vector` on ASRock E350M1

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 26 Feb 2018 10:14:10 -0600
From:   Tom Lendacky <thomas.lendacky@....com>
To:     Thomas Gleixner <tglx@...utronix.de>,
        Paul Menzel <pmenzel@...gen.mpg.de>
Cc:     Borislav Petkov <bp@...en8.de>,
        Paul Menzel <pmenzel+linux-irq@...gen.mpg.de>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: `do_IRQ: 1.55 No irq handler for vector` on ASRock E350M1

On 2/24/2018 2:59 AM, Thomas Gleixner wrote:
> On Sat, 24 Feb 2018, Paul Menzel wrote:
>> Am 23.02.2018 um 20:09 schrieb Borislav Petkov:
>>> On Fri, Feb 23, 2018 at 07:18:34PM +0100, Thomas Gleixner wrote:
>>>> Borislav is seeing similar issues on larger AMD machines. The interrupt
>>>> seems to come from BIOS/microcode during bringup of secondary CPUs and we
>>>> have no idea why.
>>>
>>> Paul, can you boot 4.14 and grep your dmesg for something like:
>>>
>>> [    0.000000] spurious 8259A interrupt: IRQ7. >
>>> ?
>>
>> No, I do not see that. Please find the logs attached.
> 
> From your 4.14 log:
> 
> Feb 19 09:48:06.843173 kodi kernel: CPU 0 irqstacks, hard=e9b0a000 soft=e9b0c000
> Feb 19 09:48:06.843216 kodi kernel: spurious 8259A interrupt: IRQ7.

I think I remember seeing something like this previously and it turned out
to be a BIOS bug.  All the AP's were enabled to work with the legacy 8259
interrupt controller.  In an SMP system, only one processor in the system
should be configured to handle legacy 8259 interrupts (ExtINT delivery
mode - see Intel's SDM, Volume 3, section 10.5.1, Delivery Mode).  Once
the BIOS was fixed, the spurious interrupt message went away.

I believe at some point during UEFI, the APs were exposed to an ExtINT
interrupt.  Since they were configured to handle ExtINT delivery mode and
interrupts were not yet enabled, the interrupt was left pending.  When the
APs were started by the OS and interrupts were enabled, the interrupt
triggered. Since the original pending interrupt was handled by the BSP,
there was no longer an interrupt actually pending, so the 8259 responds
with IRQ 7 when queried by the OS.  This occurred for each AP.

Thanks,
Tom

> Feb 19 09:48:06.843258 kodi kernel: Console: colour VGA+ 80x25
> 
> So this has been there in 4.14 already just the detection mechanism has
> changed due to the modifications of the interrupt vector management code.
> It's not a real issue, just annoying ....
> 
> Thanks,
> 
> 	tglx
>