On Thu, 8 Apr 1999, Matthew Jacob wrote:
> (and before you yell at me because I haven't loaded d01 yet, don't worry,
Consider I just did so. :)
> I will- this mail is actually mostly good news reporting):
>
> This is a coule of 53c895 cards from Antares Microsystems
> (http://www.antares.com)-
>
>
>
> Setup:
>
> Ultra30 Solaris 2.7 + Antares Driver Linux 2.2.5 (patch-53c8xx-s01-d00)
>
> scsi0 : ncr53c8xx - version 3.2
> scsi : 1 host.
> Vendor: QUANTUM Model: QM39100TD-SW Rev: N1B0
> Type: Direct-Access ANSI SCSI revision: 02
> Detected scsi disk sda at scsi0, channel 0, id 4, lun 0
> ncr53c895-0-<4,0>: tagged command queue depth set to 4
> ncr53c895-0-<4,*>: FAST-20 WIDE SCSI 40.0 MB/s (50 ns, offset 31)
> SCSI device sda: hdwr sector= 512 bytes. Sectors= 17783249 [8683 MB] [8.7
> GB]
> sda: sda1 sda3 sda8
>
>
> So far under light filesystem load testing, both systems seem to be happy
> sharing this disk.
>
> Just a couple of minor nits:
>
> + It might be nice to have NCR_SCSI_MYADDR actually be a patchable
> variable for modprobe- Most of these cards have BIOS/NVRAM, but
> a lot don't and it'd be nice to be able to change the default
> initiator ID w/o recompiling.
Recompiling is the only way to be sure you are actually running the
program you want to run. :-)
> + The driver's a bit chatty about Queue Full conditions- I get a
> stream of:
>
> ncr53c89-0-<4,0>: QUEUE FULL! 1 busy, 0 disconnected CCBs
What is that? A QUEUE FULL with 0 IO pending is a driver killer. It just
triggers the 'FULL and EMPTY at the same time' condition that may confuse
numerous drivers and sub-systems (The only way to recover is either to use
a timer or to loop hard until it works. Both are painfull).
You can guess how the driver try to handle that from the source code, or
base your guessing on the number of messages that go to the syslog. :-))
Is it the Solaris which is flooding the device or the disk firmware that
is brain-mixed ?. I remember of Atlas I behaving so, but recent devices
should not, and at least reserve 1 entry for each initiator. There is
still much room for improvements in QUANTUM firmwares. ;-)
Disabling the write caching should get rid of this condition, provided
that the Solaris is reasonnable at queuing simultaneous IOs, and should
not affect performances significantly under Linux.
Just for the fun. Could you configure the driver for 64 queued commands,
flood the disk with lost of WRITES from Linux and see how Solaris is
behaving. :)
> ncr53c895-0-<4,0>: QUEUE FULL! 1 busy, 0 disconnected CCBs
> ncr53c895-0-<4,0>: QUEUE FULL! 1 busy, 0 disconnected CCBs
> ncr53c895-0-<4,0>: QUEUE FULL! 1 busy, 0 disconnected CCBs
> ncr53c895-0-<4,0>: QUEUE FULL! 1 busy, 0 disconnected CCBs
> ncr53c895-0-<4,0>: QUEUE FULL! 1 busy, 0 disconnected CCBs
> ncr53c895-0-<4,0>: QUEUE FULL! 1 busy, 0 disconnected CCBs
> ncr53c895-0-<4,0>: QUEUE FULL! 1 busy, 0 disconnected CCBs
> ncr53c895-0-<4,0>: tagged command queue depth set to 3
> ncr53c895-0-<4,0>: tagged command queue depth set to 4
>
> Maybe this could just be printed out during debug conditions?
You can get rid of these messages with option "verb:0". Having the QUEUE
FULL by default is helpfull for user to be aware of the queue depth being
perhaps too large. Btw, only QUANTUM disks are foolish enough so that the
driver will print out a large number of QUEUE FULL messages.
> Next step is to boot up the UltraLinux disk to show even more
> excitement... This is a pretty good failover configuration...
Let me know.
Regards,
G�rard.
PS: Could you give a shot with the sym53c8xx driver and let me know if
it works on the Linux/Sparc. (Btw, it is ok for x86).
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
