4607e8eed3
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 |
||
|---|---|---|
| .. | ||
| DriverManual.txt | ||
| Hardware.txt | ||
| isp_freebsd.c | ||
| isp_freebsd.h | ||
| isp_ioctl.h | ||
| isp_library.c | ||
| isp_library.h | ||
| isp_pci.c | ||
| isp_sbus.c | ||
| isp_stds.h | ||
| isp_target.c | ||
| isp_target.h | ||
| isp_tpublic.h | ||
| isp.c | ||
| ispmbox.h | ||
| ispreg.h | ||
| ispvar.h | ||