'RELENG_7_0_0_RELEASE'.

This commit was manufactured to restore the state of the 7.0-RELEASE image.

Add missing locking for SBus controllers.

Approved by:	re (kensmith)

Both WWNN and WWPN are 64-bit unsigned integers and they are prefixed
with "0x", which requires two more bytes each.

Submitted by:	Danny Braniss (danny at cs dot huji dot ac dot il)
		via Matthew Jacob (lydianconcepts at gmail dot com)
Approved by:	re (bmah)
MFC after:	3 days

Approved by:	re (kensmith)
MFC after:	3 days

Approved by:	re (Ken)
MFC after:	3 days

Approved by:	re (ken)
MFC after:	3 days

First, we were never correctly checking for a 24XX Status Type 0
response- that cased us to fall through to evaluate status for
commands as if this were a 2100/2200/2300 Status Type 0 response.
This is *close*, but not quite the same. This has been reported
to be apparent with some wierd lun configuration problems with
some arrays. It became glaringly apparent on sparc64 where none
of the correct byte swap things were done.

Fixing this omission then caused a whole universe shifting debug
cycle of endian issues for the 2400. The manual for 24XX f/w turns
out to be wrong about the endianness of a couple of entities. The
lun and cdb fields for the type 7 request are *not* unconditionally
big endian- they happen to be opposite of whatever the endian of
the current machine type is. Same with the sense data for the
24XX type 0 response.

While we're at it investigate and resolve some NVRAM endian
issues.

Approved by:	re (ken)
MFC after:	3 days

Approved by:	re (ken, implicit)

put out a ispreqt2e_t structure onto the request queue- not a ispreqt2_t
structure. I forgot that the 23XX can use a t2 structure.

Approved by:    re (ken, implicitly)
MFC after:	3 days

to put out a ispreqt3e_t structure onto the request queue-
not a ispreqt3_t structure. We weren't. This turns out only
to really matter for big endian machines.

Approved by:	re (ken)
MFC after:	3 days