2.11BSD boot looping

Steven M. Schultz sms at moe.2bsd.com
Tue Nov 30 08:07:48 AEST 1999


Hi -

> From: James Lothian <simul8 at simul8.demon.co.uk>
> For what it's worth, this does sound suspiciously like what the 4.3
> boot code did with the Viking. As far as I can remember, there is a 
> flag in one of the UDA50 registers that is set to 1 one the device
> interrupts. The 4.3 boot code runs the UDA50 with interrupts disabled,

	Actually it's in the response packet rather than a UDA 'register' but
	yep - that sounds very familiar.

> but polls this flag to find out when the controller has finished a
> command.
> On the UDA50, even if interrupts are disabled, this flag gets set. On
> the viking, it doesn't. I can't remember the exact change I made, but I

	At least one of the changes was to give the MSCP adaptor a vector 
	during the 3 or 4 step init process.   Normally 4.3/2.11 didn't bother
	to give a vector since interrupts were disabled.   It doesn't
	reall matter what the vector is as long as it's non zero - the
	value used was 0154 (primary/1st MSCP adaptor).

	Some other 3rd party adaptors (can't recall if it was Dilog or
	Emulex or ...) had the same problem.

> "Daniel A. Seagraves" wrote:
> > 
> > It's looping around at 157702.
> > 
> > 157702 contains 001776

	Hmmm, I wonder if that's in the bootblock code or the actual boot
	program. 

	The standalone MSCP driver in 2.11 has the "give a vector to the
	adaptor" change  so my guess is that the bootblock is where the
	looping is happening.  The bootbock (rauboot.s from /sys/mdec)
	relocates itself to 0160000-01000 or 0157000 so a loop at 0157702
	would be where the 'racmd:' routine is looping waiting for a
	command to complete (or the adaptor to come ready the first time).

	I thought the same "give a vector" change had been made to rauboot.s
	but it would appear that's not the case ;-(

	Steven Schultz

Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.3/8.9.3) id CAA59602
	for pups-liszt; Wed, 1 Dec 1999 02:59:41 +1100 (EST)


More information about the TUHS mailing list