Xref: utzoo comp.unix.sysv386:8267 comp.periphs.scsi:2663 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!dali.cs.montana.edu!ogicse!zephyr.ens.tek.com!tektronix!percy!littlei!sumac.intel.com!seckin From: seckin@sumac.intel.com (Seckin Unlu) Newsgroups: comp.unix.sysv386,comp.periphs.scsi Subject: Re: INTEL 5.4 2.0 and Adaptec 1542B Message-ID: <1744@gandalf.UUCP> Date: 21 May 91 20:12:30 GMT References: <1991May20.145226.7155@march.co.uk> Sender: news@gandalf.UUCP Reply-To: seckin@sumac.intel.com (Seckin Unlu) Followup-To: comp.unix.sysv386 Organization: Software Focus Group, Intel Lines: 59 Nntp-Posting-Host: sumac In article <1991May20.145226.7155@march.co.uk>, rossw@march.co.uk (Ross Wakelin) writes: > The INTEL 5.4 release 2.0 (developers edition) has buggy drivers for the > Adaptec 1542B SCSI host adaptor. > > We were using this adaptor in a 25Mhz Mylex 486 motherboard, and achieved > a record number of system lockups and crashes. The machine would go away > for a minute or so and then report a SCSI error. At this point, our only > option was to reboot the machine. The problem was: On a Read-Extended (0x28) command, the disk would send a disconnect message to the adapter, the SCSI bus would become free, the disk would not reconnect, the driver would time out after 30-90 seconds, retry the read-extended, but the SCSI bus would hang. The problem was seen mostly with AHA-1540 and Maxtor XT-4000S series, occasionally with WD-7000 FASST2 and XT-4000S, and never with other combinations of adapters and disks. > We replaced the 1542B with a WD-7000 FAST card, and found that we still got > the SCSI errors, but the driver for the WD board recovered from the errors > and let us continue processing. Needless to say, we are now production on > the WD board. The WD-7000 FASST2 driver in SVR4 resets the adapter and the SCSI bus before retrying commands. The Adaptec driver in SVR4 2.0 didn't. In SVR4 3.0, the Adaptec driver sends a Bus-Device-Reset message to the locked-up disk, before retrying the command. This workaround seems to work most of the time. > Hopefully this is one of the things that was (will be) fixed in the > handover to Interactive. > Ross Wakelin r.wakelin@march.co.uk > Unix Systems Director or ..mcsun!ukc!slxsys!march!rossw > March Systems Consultancy Ltd These are the workarounds to the above problem: - If the disk is a Maxtor XT-4000S, make sure f/w is at B5D level, and disable the read-ahead cache on the disk. No more lock-ups, but sequential read performance will be lower. - Use another disk (even with Maxtor XT-8000S the problem goes away). - Use another adapter (e.g. WD-7000 FASST2, what you have done). The problem does not go away, but it is less frequent and less fatal. - Get SVR4 3.0, from Interactive Systems Corporation. I hope this helps. Seckin Unlu uunet!littlei!seckin or seckin@littlei.intel.com Software Engineer or seckin@sumac.intel.com Intel Corporation ----- Any opinions expressed here are my own and are not representative of Intel Corporation.