> -----Original Message----- > From: Thomas Gleixner [mailto:tglx@xxxxxxxxxxxxx] > Sent: Tuesday, November 6, 2018 12:07 PM > To: Holger Schurig <holgerschurig@xxxxxxxxx> > Cc: Michael Shych <michaelsh@xxxxxxxxxxxx>; x86@xxxxxxxxxx; Vadim > Pasternak <vadimp@xxxxxxxxxxxx>; Ido Schimmel > <idosch@xxxxxxxxxxxx>; Ohad Oz <ohado@xxxxxxxxxxxx>; Greg KH > <gregkh@xxxxxxxxxxxxxxxxxxx>; linux-serial@xxxxxxxxxxxxxxx > Subject: Re: "No irq handler for vector" problem > > Holger, > > On Mon, 5 Nov 2018, Holger Schurig wrote: > > > That's a really good question. So one hint is that it's only a few boards > > > and not a really widespread problem. The other is that it goes away when > > > the kernel runs with only one CPU. > > > > Hmm, I noticed that "nr_cpus=1" on the kernel command line greatly > > reduced the frequency. But it was not a complete cure. > > Good. I was really worried about a subtle SMP related issue. > > > > It looks like an issue when tearing down the serial interrupt, but I need > > > to think more about how to debug that. > > > > Can we have a problem in the APCI tables? One thing that I saw in the > > kernel logs is that Linux is using the MADT normally, but with > > "noapic=1" it uses Intel MP Spec 1.4 ?!?! If the ACPI BIOS describes > > the interrupts in a wrong way, then maybe we have an issue here (and not > > in the Haswell architecture, as I originally thought). > > I don't think so. With noapic=1 the whole interrupt handling is completely > different, so it's just disabling the delivery path which is usally used. > > > Regarding the Haswell: in an Intel document I found the heading "Modile > > 4th Generation Intel Core Processor Family I/O, External design > > specificaton EDS" and below a table. This table said the following > > properties are true for IRQ 3+4: > > > > - SERIRQ: yes, > > - Direct from Pin: no > > - Using PCI Message: yes > > > > I can understand the first two: the IRQs originate from a Winbond > > SuperIO that is attached via LPC. > > > > But the last item confuses me: if the IRQ is delivered via MSI, > > shouldn't I then see PCI-MSI in /proc/interrupts??? Or should the vector > > then be in a different domain, i.E. not in IO-APIC-0 but in PCI-* ???? > > If it's deliverd via MSI, then yes it would show up in the MSI domain, but > the UART driver does not use MSI for the legacy UARTS. > > Though SERIRQ is a really good hint. Let me look into the details of that a > bit more. We are experienced problem only on Ivy Bridge CPU with Winbond SIO. There are no problem on Atom Rangeley and Broadwell-DE SoCs. Interrupt for serial port, IRQ3, is delivered via Serial IRQ on all these platforms not only on problem IvyBridge. > > Thanks, > > tglx
