Re: False positive "do_IRQ: #.55 No irq handler for vector" messages on AMD ryzen based laptops

[Hans de Goede <hdegoede@redhat.com>]

Hi,

On 21-02-19 13:30, Hans de Goede wrote:
> Hi,
> 
> On 19-02-19 22:47, Lendacky, Thomas wrote:
>> On 2/19/19 3:01 PM, Thomas Gleixner wrote:
>>> Hans,
>>>
>>> On Tue, 19 Feb 2019, Hans de Goede wrote:
>>>
>>> Cc+: ACPI/AMD folks
>>>
>>>> Various people are reporting false positive "do_IRQ: #.55 No irq handler for
>>>> vector"
>>>> messages on AMD ryzen based laptops, see e.g.:
>>>>
>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1551605
>>>>
>>>> Which contains this dmesg snippet:
>>>>
>>>> Feb 07 20:14:29 localhost.localdomain kernel: smp: Bringing up secondary CPUs
>>>> ...
>>>> Feb 07 20:14:29 localhost.localdomain kernel: x86: Booting SMP configuration:
>>>> Feb 07 20:14:29 localhost.localdomain kernel: .... node  #0, CPUs:      #1
>>>> Feb 07 20:14:29 localhost.localdomain kernel: do_IRQ: 1.55 No irq handler for
>>>> vector
>>>> Feb 07 20:14:29 localhost.localdomain kernel:  #2
>>>> Feb 07 20:14:29 localhost.localdomain kernel: do_IRQ: 2.55 No irq handler for
>>>> vector
>>>> Feb 07 20:14:29 localhost.localdomain kernel:  #3
>>>> Feb 07 20:14:29 localhost.localdomain kernel: do_IRQ: 3.55 No irq handler for
>>>> vector
>>>> Feb 07 20:14:29 localhost.localdomain kernel: smp: Brought up 1 node, 4 CPUs
>>>> Feb 07 20:14:29 localhost.localdomain kernel: smpboot: Max logical packages: 1
>>>> Feb 07 20:14:29 localhost.localdomain kernel: smpboot: Total of 4 processors
>>>> activated (15968.49 BogoMIPS)
>>>>
>>>> It seems that we get an IRQ for each CPU as we bring it online,
>>>> which feels to me like it is some sorta false-positive.
>>>
>>> Sigh, that looks like BIOS value add again.
>>>
>>> It's not a false positive. Something _IS_ sending a vector 55 to these CPUs
>>> for whatever reason.
>>>
>>
>> I remember seeing something like this in the past and it turned out to be
>> a BIOS issue.  BIOS was enabling the APs to interact with the legacy 8259
>> interrupt controller when only the BSP should. During POST the APs were
>> exposed to ExtINT/INTR events as a result of the mis-configuration
>> (probably due to a UEFI timer-tick using the 8259) and this left a pending
>> ExtINT/INTR interrupt latched on the APs.
>>
>> When the APs were started by the OS, the latched ExtINT/INTR interrupt is
>> processed shortly after the OS enables interrupts. The AP then queries the
>> 8259 to identify the vector number (which is the value of the 8259's ICW2
>> register + the IRQ level). The master 8259's ICW2 was set to 0x30 and,
>> since no interrupts are actually pending, the 8259 will respond with IRQ7
>> (spurious interrupt) yielding a vector of 0x37 or 55.
>>
>> The OS was not expecting vector 55 and printed the message.
>>
>>  From the Intel Developer's Manual: Vol 3a, Section 10.5.1:
>> "Only one processor in the system should have an LVT entry configured to
>> use the ExtINT delivery mode."
>>
>> Not saying this is the problem, but very well could be.
> 
> That sounds like a likely candidate, esp. also since this only happens
> once per CPU when we first only the CPU.
> 
> Can you provide me with a patch with some printk-s / pr_debugs to
> test for this, then I can build a kernel with that patch added and
> we can see if your hypothesis is right.

Ping? I like your theory, can you provide some help with debugging this
further (to prove that your theory is correct ) ?

Regards,

Hans