Okay, so I am able to reproduce this now, and I spent a little time
tracking it down (seeing as how I was cleaning up a bunch of the Rawhide
code anyhow).

The kernel is definitely out of the picture by the time the spew happens.

In fact, the firmware is attempting to load the primary bootstrap, at
which time it fails.  It looks like the spew is caused by a firmware
bug ... i.e. doesn't recover from this particular failure very well.

But the interesting question is why loading the primary bootstrap fails.

I believe the answer here is that the kernel is somehow leaving the
SCSI controller which the firmware wants to boot from in a state which
the firmware cannot deal with.  The reason it doesn't occur when you halt
then boot manually is because the firmware reinitializes everything.

It doesn't appear to be doing this on "reboot".

Firmware shouldn't really be making any assumptions about the state of
devices once a client program (i.e. the kernel) has run.

This may just be a general firmware bug.  So, my question to the maintainer
of the machine which I'm testing on (HI MATT) is:

	(1) Has the firmware on the system been updated at any point, or

	(2) if not, have you tried updating the firmware to see if the
	    problem goes away?

        -- Jason R. Thorpe <thorpej@nas.nasa.gov>