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. Thanks, tglx
