not setting Extint can fix this IRQ issue.

Is it a common problem or it is a AMD specific one?


Zheng 

diff --git a/src/cpu/x86/lapic/lapic.c b/src/cpu/x86/lapic/lapic.c
index 91b0fcd5ba..0dff625eb7 100644​
--- a/src/cpu/x86/lapic/lapic.c​
+++ b/src/cpu/x86/lapic/lapic.c​
@@ -29,6 +29,8 @@ void do_lapic_init(void)​
  lapic_write_around(LAPIC_SPIV,​
  (lapic_read_around(LAPIC_SPIV) & ~(LAPIC_VECTOR_MASK))​
  | LAPIC_SPIV_ENABLE);​
+​
+ if (lapicid() == 0)​
  lapic_write_around(LAPIC_LVT0,​
  (lapic_read_around(LAPIC_LVT0) &​
  ~(LAPIC_LVT_MASKED | LAPIC_LVT_LEVEL_TRIGGER |​
@@ -38,6 +40,16 @@ void do_lapic_init(void)​
  | (LAPIC_LVT_REMOTE_IRR | LAPIC_SEND_PENDING |​
  LAPIC_DELIVERY_MODE_EXTINT)​
  );​
+ else​
+ lapic_write_around(LAPIC_LVT0,​
+ (lapic_read_around(LAPIC_LVT0) &​
+ ~(LAPIC_LVT_MASKED | LAPIC_LVT_LEVEL_TRIGGER |​
+ LAPIC_LVT_REMOTE_IRR | LAPIC_INPUT_POLARITY |​
+ LAPIC_SEND_PENDING | LAPIC_LVT_RESERVED_1 |​
+ LAPIC_DELIVERY_MODE_MASK))​
+   | (LAPIC_LVT_REMOTE_IRR | LAPIC_SEND_PENDING)​
+ );​
+​
  lapic_write_around(LAPIC_LVT1,​
  (lapic_read_around(LAPIC_LVT1) &​
  ~(LAPIC_LVT_MASKED | LAPIC_LVT_LEVEL_TRIGGER |​



From: Zheng Bao <fishbaoz@hotmail.com>
Sent: Wednesday, May 6, 2020 8:14 AM
To: Nico Huber <nico.h@gmx.de>; coreboot <coreboot@coreboot.org>
Subject: [coreboot] Re: Linux kernel says "do_IRQ: 1.55 No irq handler for vector​"
 
The Payload I run between Coreboot and Linux is SeaBIOS. Do you mean  SeaBIOS should disable interrupt of all APs?
I check the mail list and found this issue was raised before, but actually by my colleague. We worked together and have not found the final solution.

Zheng



From: Nico Huber <nico.h@gmx.de>
Sent: Sunday, May 3, 2020 4:28 PM
To: Zheng Bao <fishbaoz@hotmail.com>; coreboot <coreboot@coreboot.org>
Subject: Re: [coreboot] Linux kernel says "do_IRQ: 1.55 No irq handler for vector​"
 
Hi Zheng,

On 03.05.20 17:27, Zheng Bao wrote:
> I am debugging the AMD Picasso board. When Linux kernel boots, there is some error message in dmesg.
> do_IRQ: 1.55 No irq handler for vector​
>
> The kernel can still boot.
> What does this message mean? Can I just ignore this message?

well, I'm worried. Even if it probably breaks nothing, it seems the APs
are not in a state that Linux expects when it starts them up.

1.55 means interrupt vector 55 on CPU#1. This is in Linux' legacy
interrupt range, should be IRQ 7 (offset by 48).

That's where my Linux knowledge ended but I just had a quick look:
In `arch/x86/kernel/smpboot.c` we have start_secondary() which runs
on the AP. It calls:

    load_current_idt();
    ...
    lapic_online();
    ...
    local_irq_enable();

A comment above the declaration of load_current_idt() indicates that
we don't expect IRQs yet (before local_irq_enable() via `sti` I guess).
That the kernel complains "No irq handler for vector" likely means that
an interrupt is triggered before lapic_online() registered the handler.

So, for me there are two mysteries:

 1. Why is IRQ 7 triggerred?

 2. Why does the AP process interrupts before `sti`? (if my assessment
    above is correct).

Did you run any payload between coreboot and the kernel?

Nico

PS. I didn't thought you'd ask without googling first, there are
    mailing list threads about the issue already. Let's see what
    they say...