Date: Thu, 27 Apr 1995 10:47:20 -0700 From: "Justin T. Gibbs" <gibbs> To: CVS-commiters, cvs-sys Subject: cvs commit: src/sys/i386/scsi aic7xxx.c aic7xxx.h Message-ID: <199504271747.KAA25865@freefall.cdrom.com>
next in thread | raw e-mail | index | archive | help
gibbs 95/04/27 10:47:19 Modified: sys/dev/aic7xxx aic7xxx.seq Log: Restructure the arbitration loop to allow for reselections that win out over the adapter's selections. Many fast periferals were getting upset when the sequencer decided to rearbitrate after the device had already won arbitration. This also forced the creation of a list threaded through the SCBs (since we don't have enough space anywhere else) of commands that are awaiting reselection. This list is run down before any new transactions from the input queue are allowed. The list is appened to whenever we begin a selection (simple case since the selecting device is always at the head) and by the kernel driver whenever a request sense occurs. In the common case, the list is only one element long, but when a reselection wins out over a selection and that reselection generates a request sense, the outstanding selection required for the retreval of the sense code grows the list. On machines with many targets, this might cause the list to grow large, so this solution, which will allow up to the maximum number of I/O requests capible of the card elements in the list, was chosen. The list manipulation is trivial and adds three sequencer instructions of overhead to the selection phase. This fixes the "target busy" errors from micropolis drives and the bursty I/O problem when performing I/O between a Quantum Grand Prix and any other device. I anticipate that this will correct many of the problems that have been reported with this driver. Reviewed by: Wcarchive and David Greenman Modified: sys/i386/scsi aic7xxx.c aic7xxx.h Log: Additions to support the WAITING_SCB list that the sequencer maintains. It is the kernel driver's responsibility to do the list manipulation whenever a selection timeout or a request sense occurs. Print out the interrupt type that the device has been set to. It seems that one of the Asus motherboards botches this and David thought a diagnostic would be nice. Fix a bug in my diagnostic code that David found. Reviewed by: Wcarchive and David Greenman
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199504271747.KAA25865>