Date: Fri, 02 Jun 1995 11:53:16 -0700 From: "Justin T. Gibbs" <gibbs@freefall.cdrom.com> To: "Rodney W. Grimes" <rgrimes@gndrsh.aac.dev.com> Cc: FreeBSD-hackers@freebsd.org (FreeBSD hackers) Subject: Re: quantum (DEC) grand prix (any objections?) Message-ID: <199506021853.LAA26253@freefall.cdrom.com> In-Reply-To: Your message of "Fri, 02 Jun 95 11:21:36 PDT." <199506021821.LAA07801@gndrsh.aac.dev.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>> >> >I'm about to buy a Quantum Grand Prix (4GB) SCSI disk today. >> >> >Keen as always I'm expecting there will be no trouble connecting >> >> >it to a 1.1.5.1 (AH1542A) system, will there be? >> >> >Any caveats wrt connecting it to ncr 53810 (Asus SP3G) under 2.0-current >? >> >> > >> >> >> >> It will not work on the NCR. I have no idea about the 1542, since I haven >'t >> >> tried it, but a 1742 in Wcarchive had trouble with them. The drives work >> >> fine on any of the aic7xxx based cards with 2.0.5A. >> > >> > >> >> --nyone knowing the reasons why it does not work on the NCR? I mean >> >the on board NCR of the ASUS SP3G PCI board. >> >> Some incompatibility with the code the NCR runs (I don't know if its called >> a sequencer program like it is for the Adaptec). The aic7xxx driver had a >> similar problem, but was fixed more than a month ago. > >Can you provide specific details of what you had to do to the sequencer >code for the aic7xxx, the NCR does infact use sequencer code and the >same fix could probably be adapted into it makeing the Grand Prix supportable. > >It may also fix the problems with certain CDROM drives and TAPE drives >that show a very similiar failure to the Grand Prix drive. > >-- >Rod Grimes rgrimes@gndrsh.aac.dev.com >Accurate Automation Company Custom computers for FreeBSD The problem with the aic7xxx was fairly simple. Whenever a selection was being made to a device, as initiated by turning on the selection hardware, the sequencer code always always assumed that it would win. With slow devices, this is not a problem, but with fast devices, and my guess is that the Grand Prix goes right to the limit of the spec on the bus settle times and such, there was a window between the last time we checked to see if other initiators or targets had won arbitration, and when we started our own arbitration for the bus. During arbitration, the original code from John Aycock would just busy look until sucess. This would cause other devices that won arbitration of the bus by sneeking into during the window to timeout on the card and fall off the bus. The fix, and this may only be an option on the aic7xxx, was to keep the reselection hardware enabled at all times, and enable selections whenever we wanted to arbitrate. When we start a transaction, we go back to the generic loop that looks for reconnections, successfull selections, and soon, selections from another initiator (target mode). This fixed the problem quite nicely, but you need to add aditional state to handle the case that your selection failed and the next time the bus goes free to try it again. For the aic7xxx, this is all handled transparantly to the kernel. -- Justin T. Gibbs ============================================== TCS Instructional Group - Programmer/Analyst 1 Cory | Po | Danube | Volga | Parker | Torus ==============================================
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199506021853.LAA26253>