vmspace changes to use sysref

[Matthew Dillon]

: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
: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.)
:
:Thanks!

     The main thing I want to accomplish is to make sure systems boot,
     so that's good news!

     One thing I will be doing is reducing the livelock limit from 50K/sec
     to 10K/sec, or even less, during the device configuration stage.
     The default livelock limit is too high and can cause actual livelocks
     to occur during booting.

     I could just get rid of the stray irq messages, but there's a 
     conundrum here that I would like to solve because I have no idea
     why they would be occuring on a single-cpu machine in the first
     place!  Since our clocks are working during device configuration
     now, I will be adding code (right now in fact) to reduce the 
     reporting rate to one per second.

     Could you print out your mptable?  run 'mptable'.  Even though its
     a single-cpu machine there might be an IOAPIC.  That's one of two things
     I can think of that could be responsible for generating stray IRQ 7's.
     The other is that the BIOS is programming devices to interrupt on
     IRQ 7 for its own use, and the kernel inherits the state... but 
     that still doesn't quite explain it because stray interrupts get
     masked out on the 8259.  So the implication is that the interrupt
     is coming from another source.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>