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...
_______________________________________________
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org
