Re: vmspace changes to use sysref

[walt <wa1ter@xxxxxxxxxxxxx>]

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!