Hi,
> Michael,
>
> On Mon, 10 Dec 2018, Michael Shych wrote:
> > Do you have some news about this issue?
>
> No. I was waiting for the below.
>
> > > > This is specific to nolapic=1, with "noapic=1" the ERR interrupt number
> > > > stays at 51. But I guess this is a red herring, too, because who runs
> > > > his box with nolapic=1 in the first place :-)
> > >
> > > Could you do the same test without nolapic please?
>
> ^^^^^^^^^^
>
> Thanks,
>
> tglx
I'm trying to continue this thread, as it seems, this is still an issue.
I'm getting "No irq handler for vector" message almost on each serial
port closing. The serial port is on a Nuvoton SuperIO chip, and the CPU
is an Intel Baytrail E3845.
Here are my observations (misinterpretations are possible, I'm not that
familiar with the X86):
First of all, the SuperIO seems to send an undesired interrupt, when the
port's "IRQ enable" flag gets cleared (HCR address: (base + 4), "IRQ
Enable" bit3). See here:
# cat /dev/ttyS1 &
# cat /proc/interrupts | grep ttyS1
3: 0 19 0 0 IO-APIC
3-edge ttyS1
# cat /sys/class/tty/ttyS1/port
0x2F8
# /opt/hr/inb --hex 0x2FC
b
# cat /proc/interrupts | grep ttyS1
3: 0 19 0 0 IO-APIC
3-edge ttyS1
# /opt/hr/outb 0x2FC 0x3 * <----------- Clearing IRQ
enable here*
# cat /proc/interrupts | grep ttyS1
3: 0 *20* 0 0 IO-APIC 3-edge
ttyS1 *<------- IRQ counter increased*
# /opt/hr/outb 0x2FC 0xb
# cat /proc/interrupts | grep ttyS1
3: 0 20 0 0 IO-APIC
3-edge ttyS1
# /opt/hr/outb 0x2FC 0x3 * <----------- Clearing IRQ
enable here*
# cat /proc/interrupts | grep ttyS1
3: 0 *21* 0 0 IO-APIC 3-edge
ttyS1 *<------- IRQ counter increased*
# /opt/hr/outb 0x2FC 0xb
# cat /proc/interrupts | grep ttyS1
3: 0 21 0 0 IO-APIC
3-edge ttyS1
# fg
cat /dev/ttyS1 *<------- Closing port*
^C
do_IRQ: 1.44 No irq handler for vector
# cat /proc/interrupts | grep ttyS1
# cat /proc/interrupts | grep " 3:"
3: 0 21 0 0 IO-APIC 3-edge
*<------- IRQ counter NOT increased*
#
The 8250 driver seems shutting down the port like this:
- synchronize_irq()
- disabling port IRQ (clearing TIOCM_OUT2 flag with
serial8250_set_mctrl)
- free_irq()
The free_irq() is doing the following:
1) masking the interrupt in the IO-APIC
2) clearing the IRQ vector
Now, it seems, the problematic sequence is the following:
a) the SuperIO sends the interrupt to the IO-APIC
b) the IO-APIC forwards the interrupt to the local-APIC
c) the interrupt in the IO-APIC gets masked (IRQ in the local-APIC
is pending)
d) the IRQ vector gets cleared
e) the pending IRQ gets handled (most probably by another core), but
the vector is already set to VECTOR_UNUSED, so the do_IRQ() function
prints the error message
When I put a printf (delay) right before the clear_irq_vector() call in
the x86_vector_deactivate(), I no longer received the error messages ->
I left time for the interrupt to get processed.
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/x86/kernel/apic/vector.c#n378
Also, it seems, if I'm running the serial port opening-closing process
on the same core as the interrupt is assigned to, I'm not getting the
error message. If I'm running it on a different core, most of the time,
I'm getting the error message.
I mean, something like that:
# echo 2 > /proc/irq/3/smp_affinity
# taskset 1 cat /dev/ttyS1
^C
# taskset 1 cat /dev/ttyS1
^C
do_IRQ: 1.44 No irq handler for vector
# taskset 1 cat /dev/ttyS1
^C
do_IRQ: 1.44 No irq handler for vector
# taskset 2 cat /dev/ttyS1
^C
# taskset 2 cat /dev/ttyS1
^C
# taskset 2 cat /dev/ttyS1
^C
#
Unfortunately, I'm stuck at this point a bit. Don't really know, what
would be the proper solution (how could I avoid free'ing up a pending
IRQ's vector), also I'm not knowing the x86 part of the kernel very well
yet.
Thanks,
Robert
