src-test2/sys/dev/isp/isp.c, branch release/7.0.0_cvs FreeBSD source tree https://cgit-dev.freebsd.org/src-test2/atom?h=release%2F7.0.0_cvs 2008-02-24T05:45:17Z This commit was manufactured by cvs2svn to create tag 2008-02-24T05:45:17Z cvs2svn cvs2svn@FreeBSD.org 2008-02-24T05:45:17Z urn:sha1:a9c219fa3cec18ef9f30edec6fa106bf0e2d423d 'RELENG_7_0_0_RELEASE'. This commit was manufactured to restore the state of the 7.0-RELEASE image. Be more conservative- turn off fast posting and RIO for 22XX cards. 2007-07-10T07:55:04Z Matt Jacob mjacob@FreeBSD.org 2007-07-10T07:55:04Z urn:sha1:bb4f528dd82e6da5961b24f3388879b19266f1ba Approved by: re (ken) MFC after: 3 days Recover from some major omissions/problems with the 24XX port. 2007-07-02T20:08:20Z Matt Jacob mjacob@FreeBSD.org 2007-07-02T20:08:20Z urn:sha1:4607e8eed375ee34622d510c6de7d922843caca5 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 If we're going to (for 23XX and 24XX cards) DMA firmware from the 2007-06-24T01:41:16Z Matt Jacob mjacob@FreeBSD.org 2007-06-24T01:41:16Z urn:sha1:530755ca2d25b28810a2b6039ddedfd30e67b77d request queues rather than shove it down a word at a time, we have to remember to put it into little endian format. Use the macros ISP_IOXPUT_{16,32} for this purpose. Otherwise, on sparc the firmware is loaded garbled and we get a (not surprisingly) firmware checksum failure and the card won't start and we don't attach it. Approved by: re (bruce) MFC after: 3 days Make this an MP safe driver but also still be multi-release. 2007-05-05T20:17:23Z Matt Jacob mjacob@FreeBSD.org 2007-05-05T20:17:23Z urn:sha1:0a70657fcc012f03d2e0064bb31e48dc6a8414b5 Seems to work on RELENG_4 through -current and also on sparc64 now. There may still be some issues with the auto attach/detach code to sort out. MFC after: 3 days some minor error message cleanups 2007-03-29T21:29:26Z Matt Jacob mjacob@FreeBSD.org 2007-03-29T21:29:26Z urn:sha1:c6048aee5d0788092a1bb068edc1a81a7c7841fe MFP4: a) Some constification from NetBSD (gcc 4.1.2) 2007-03-22T23:38:32Z Matt Jacob mjacob@FreeBSD.org 2007-03-22T23:38:32Z urn:sha1:5f634111fa1d8624be0e9dc62e38dbbacc2342e0 b) Split default param fetching/setting into scsi and fibre functions and retry the fibre fetch more than once. MFC after: 1 week Don't call isp_intr from isp_start- this seems to, in rare cases, 2007-03-14T05:58:07Z Matt Jacob mjacob@FreeBSD.org 2007-03-14T05:58:07Z urn:sha1:f6a6ae8f5c4a5e18d80f67a9af9cdfa560bc33b9 cause confusion with at least the 23XX chipsets where the output queue index pointer just gets a bit whacko. MFC after: 1 day Restore optr if you trash it for 24XX target mode. 2007-03-13T06:44:07Z Matt Jacob mjacob@FreeBSD.org 2007-03-13T06:44:07Z urn:sha1:9418a60cb0076daafbfcd36ce6bbc61def8a8887 MFC after: 3 days Fix compilation issues found in RELENG_4 port and merge the 2007-03-12T04:54:30Z Matt Jacob mjacob@FreeBSD.org 2007-03-12T04:54:30Z urn:sha1:70273f90647de9d7ae9a4db5ec0438520ebfe22c diffs back to -current to keep versions identical.