Matt Thomas wrote:
> 
> On Mar 11, 2007, at 10:34 PM, Aaron J. Grier wrote:
> 
>> On Sun, Mar 11, 2007 at 03:16:11PM +0100, Johnny Billquist wrote:
>>
>>> I decided to sit down and look a bit more as well.
>>> I haven't traced it down yet, but I think we can skip the MI scsi  
>>> stuff.
>>>  In fact, I think we can skip the scsi totally.
>>>
>>> From what I can see, it appears we have a problem with the callout
>>> functions in the vax port. If I register a callout, it never gets
>>> called. Either there is something that have broken in the timer
>>> handling, or we're locking out the timer interrupts, I'd guess.
>>> I'll see if I have some more time later tonight to look at this.
>>>
>>> Or does anyone know what might have happened recently?
>>
>> I ran into this on alpha.
>>
>> it ended up being the bool-ization (TRUE -> true) in the kernel  sources
>> broke some machine-dependent handling of UVM_PAGE_IDLE_ZERO.
>>
>> http://mail-index.netbsd.org/port-alpha/2007/02/24/0000.html
>>
>> scsibus probing just happens to be the first place in bootup where the
>> idle loop is called.
>>
>> I assume the vax fix will be similarly trivial.
> 
> Completely different problem.  This was due a latent bug in the softintr
> dispatch that was revealed by the removal of spllowersoftclock.

And wasn't that a problem related to unaligned access to short (byte) 
data? Or perhaps just a change in the storage size of the data.

Anyhow, these kinds of problems don't exist on the VAX.
But whatever the problem was, it looks like someone (I'm guessing Matt) 
have fixed the problem. Wonderful. callouts now work, and the system is 
booting. What was it?

	Johnny