From owner-pups@minnie.cs.adfa.edu.au Tue Nov 30 09:21:36 1999
Received: (from major@localhost)
	by minnie.cs.adfa.edu.au (8.9.3/8.9.3) id JAA55039
	for pups-liszt; Tue, 30 Nov 1999 09:19:12 +1100 (EST)
Received: from moe.2bsd.com (0@MOE.2BSD.COM [206.139.202.200])
	by minnie.cs.adfa.edu.au (8.9.3/8.9.3) with ESMTP id JAA55035
	for <pups@minnie.cs.adfa.oz.au>; Tue, 30 Nov 1999 09:19:04 +1100 (EST)
Received: (from sms@localhost)
	by moe.2bsd.com (8.9.0/8.9.0) id OAA02606
	for pups@minnie.cs.adfa.oz.au; Mon, 29 Nov 1999 14:07:48 -0800 (PST)
Date: Mon, 29 Nov 1999 14:07:48 -0800 (PST)
From: "Steven M. Schultz" <sms@moe.2bsd.com>
Message-Id: <199911292207.OAA02606@moe.2bsd.com>
To: pups@minnie.cs.adfa.oz.au
Subject: Re: 2.11BSD boot looping
Sender: owner-pups@minnie.cs.adfa.edu.au
Precedence: bulk

Hi -

> From: James Lothian <simul8@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

