On Mon, 30 Apr 2007, Matthew Dillon wrote: > Oh, also try with the absolute latest HEAD. I don't think SYSREF > could have had any effect on the interrupt routing, but the other > work recently committed certainly could have. > > I have some ideas with regards to the livelock issues. If reducing > the values solves that part of the problem I think we can safely > boot up with a much lower livelock limits, then increase them > as part of the RC. > > -- > > The only thing that can cause a large number of stray irq 7's that > I know of is when the ICU is used (no APIC_IO), and the BIOS fails > to program the hardware to route the ICU interrupts to just one of > the cpu's. If interrupts go to both cpu's then both cpu's try to > ack the INTA cycle and one of the cpu's will always get a stray > interrupt vector (which is usually irq 7). On AMD boxes that can be > fixed. I'm not sure how to do it on Intel boxes. > > What I'd like to know regarding the stray irq 7 is whether you ever > used the ICU with older kernels running on this particular box, > or whether you just always used APIC_IO. It might not be a 'new' > issue for your box with that particular combination (i.e. not created > by recent commits).
Good news: after updating sources just now, the new kernel no longer hangs with the scanner plugged in. With ACPI disabled I now see a few hundred of those stray interrupt 7's and then the boot continues normally. I tried booting my previous kernel with ACPI disabled and saw no stray interrupts. This situation is so much better than yesterday I think I'll wait to see if you still want more info before messing with the livelock limits. This is the dmesg from today's kernel with ACPI disabled: usb3: companion controllers, 2 ports each: usb0 usb1 usb2 intr 3 at 50001 > 50000 hz, livelocked limit engaged! usb3: <VIA VT6202 USB 2.0 controller> on ehci0 usb3: USB revision 2.0 sched_ithd: stray interrupt 7 on cpu 0 sched_ithd: stray interrupt 7 on cpu 0 sched_ithd: stray interrupt 7 on cpu 0 sched_ithd: stray interrupt 7 on cpu 0 sched_ithd: stray interrupt 7 on cpu 0 sched_ithd: stray interrupt 7 on cpu 0 sched_ithd: stray interrupt 7 on cpu 0 sched_ithd: stray interrupt 7 on cpu 0 sched_ithd: stray interrupt 7 on cpu 0 sched_ithd: stray interrupt 7 on cpu 0 sched_ithd: stray interrupt 7 on cpu 0 sched_ithd: stray interrupt 7 on cpu 0 uscanner0: at uhub1 port 2 (addr 2) disconnected uscanner: ops removed uscanner0: detached sched_ithd: stray interrupt 7 on cpu 0 sched_ithd: stray interrupt 7 on cpu 0 sched_ithd: stray interrupt 7 on cpu 0 sched_ithd: stray interrupt 7 on cpu 0 sched_ithd: stray interrupt 7 on cpu 0 sched_ithd: stray interrupt 7 on cpu 0 sched_ithd: stray interrupt 7 on cpu 0 sched_ithd: stray interrupt 7 on cpu 0 uhub3: 6 ports with 6 removable, self powered sched_ithd: stray interrupt 7 on cpu 0 <several hundred more strays snipped> sched_ithd: stray interrupt 7 on cpu 0 intr 3 at 7376 < 20000 hz, livelock removed and the boot continues normally from here. (I see these stray interrupts only with ACPI disabled.) BTW, this is a single-CPU machine, so I don't use APIC_IO in my custom kernel. I'd be happy to experiment with the livelock limits if you still want the info. Thanks!
