>  I was able to reproduce the stray 6600 irq 47 messages on my
> SCSI ID 1 disk. I had forgotten to try the 1.4P kernel.
> 
> Synopsis:
> - NetBSD 1.4.1: works fine(?) (loads 7.65(?) FW)
> - NetBSD 1.4P? (ALPHA.nofw): works fine (uses resident 1040C FW)
> - NetBSD 1.4P (snapshot 19991223): stray 6600 irq 47 (uses 4.65 FW),
> very unstable.

I've been giving a little thought to this- I finally put it together that
the irq 47 message is indicative of the isp driver not claiming an
interrupt- but that's ridiculous as it's pretty straightforward as to
whether or not there's an interrupt or not.

I'm beginning to now think that the f/w issue is a red herring- nearly
always during booting if things hang and commands start aborting it's due
to the fact that the f/w has fouled up the sync negotiation somehow. What
the isp driver does is/should be very straightforward:

	1. Force the isp to negotiate async/narrow on next command.

	2. allow the probing code to run

	3. Based on what inquiry data each found target passed back,
	re-enable sync/wide/tags for a device- next command(s) will
	have the negotiation.

The problem here can be that the f/w pooches one of these steps and
somehow gets out of step with what a target thinks has been negotiated.
Unfortunately, most boot prom f/w writers are completely brainless and
allow the bootprom to negotiate wide/sync which makes the problem worse.

Do you mind working (somewhat slowly on this- I'll mail you when I have a
test kernel ready- it won't be for a couple of days) with me on this?
Obviously if I could reproduce this in my set of Alpha's this would have
been tackled by now. There are periodic cases of things like this
happening, but not in my set of things.

-matt