Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: False positive "do_IRQ: #.55 No irq handler for vector" messages
 on AMD ryzen based laptops
To:     "Lendacky, Thomas" <Thomas.Lendacky@amd.com>,
        Thomas Gleixner <tglx@linutronix.de>
Cc:     Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
        Borislav Petkov <bp@alien8.de>
References: <95e76875-f6b2-cbea-cd74-dc14ee77b2f8@redhat.com>
 <alpine.DEB.2.21.1902192144390.1644@nanos.tec.linutronix.de>
 <13dbe818-a364-4cd4-3ac4-78bd7e8d28e3@amd.com>
 <9f17f1aa-f258-fb18-0736-04a5c03cf40e@redhat.com>
 <cef82f75-8dc6-8198-ac41-492c200f6d57@redhat.com>
 <57b32bc1-8ef2-1e1e-a70f-04444f5919a2@amd.com>
From:   Hans de Goede <hdegoede@redhat.com>
Message-ID: <6fbcd261-f9e2-1685-1ef7-f148007aab9d@redhat.com>
Date:   Tue, 5 Mar 2019 17:02:02 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.5.1
MIME-Version: 1.0
In-Reply-To: <57b32bc1-8ef2-1e1e-a70f-04444f5919a2@amd.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Hi,

On 05-03-19 15:06, Lendacky, Thomas wrote:
> On 3/3/19 4:57 AM, Hans de Goede wrote:
>> 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 ) ?
> 
> It's been a very long time since I dealt with this and I was only on the
> periphery. You might be able to print the LVT entries from the APIC and
> see if any of them have an un-masked ExtINT delivery mode.  You would need
> to do this very early before Linux modifies any values.

I'm afraid I'm not familiar enough with the interrupt / APIC parts of
the kernel to do something like this myself.

> Or you can report the issue to the OEM and have them check their BIOS
> code to see if they are doing this.

I will try to go this route, but I'm not really hopeful that will
lead to a solution.

Regards,

Hans