On Fri, 9 Apr 1999, Matthew Jacob wrote:
> > > + 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. :-)
>
> Not if you explicitly want to change it w/o recompiles.
I was joking. :)
The driver is already bloated with bunches of options. An option patchable
from modprobe is not easy to patch in a linked driver.
Consider that the problem has been heard. :-)
> > > + The driver's a bit chatty about Queue Full conditions- I get a
> > > stream of:
> > >
>
> We all know Quantum F/W if flakey..
But using write behing caching is pain in the ass for F/W and is just
some prothesis for bad behaving O/Ses (most) with regards to disk IO
subsubsytems, in my opinion that will probably not be widely shared. ;)
Disabling write behind caching on modern disks does not mean that the
drive will not use its memory for the data, but that it will tell the host
that a command is complete after having moved the data to the medium.
Systems that perform to much synchronous writes get advantage of such a
prothesis, especially when these synchronous writes are performed from a
small number of threads.
What you want to do with SCSI is to be able to queue as numerous commands
as it is possible and being told about _actual_ IO completions. Being
told that an IO has completed when it hasn't been is a non-information. It
eats hard disk cache memory that is not large and does not spare
significantly host memory that is a lot larger. It is just some helper
for broken O/S and/or stupid applications.
When write behind caching improves a lot performances, then, it is either
the O/S or the application that needs to be fixed, in my singular but
probably quite right opinion. :-)
By the way, I assume that the QUEUE FULL with 0 outstanding command was
the consequence of write caching being enabled for your QUANTUM drive.:)
> I put the latest (d01) patches and and used the sym driver instead and
> did 64 tags for the linux side and put a much heavier load on both sides.
>
> What I get now at least once was:
Current Linux uses some 20 seconds timeout value for SCSI disks.
Something indeed went wrong at this step. If you get some additionnal info
or kernel messages, you may let me know.
> scsi : aborting command due to timeout : pid 112110, scsi1, channel 0, id
> 4, lun 0 Read (10) 00 00 89 58 da 00 00 52 00
> sym53c8xx_abort: pid=112110 serial_number=112157
> serial_number_at_timeout=112157
> scsi : aborting command due to timeout : pid 112111, scsi1, channel 0, id
> 4, lun 0 Read (10) 00 00 89 59 ac 00 00 46 00
> sym53c8xx_abort: pid=112111 serial_number=112158
> serial_number_at_timeout=112158
> sym53c895-0: abort ccb=c325f000 (cancel)
> scsi : aborting command due to timeout : pid 112109, scsi1, channel 0, id
> 4, lun 0 Read (10) 00 00 89 58 d2 00 00 08 00
> sym53c8xx_abort: pid=112109 serial_number=112159
> serial_number_at_timeout=112159
> sym53c895-0: abort ccb=c2fc2000 (cancel)
> SCSI host 1 abort (pid 112109) timed out - resetting
> SCSI bus is being reset for host 1 channel 0.
> sym53c8xx_reset: pid=112109 reset_flags=2 serial_number=112159
> serial_number_at_timeout=112159
> sym53c895-0: restart (scsi reset).
> sym53c895-0: Downloading SCSI SCRIPTS.
> sym53c895-0-<4,*>: FAST-40 WIDE SCSI 80.0 MB/s (25 ns, offset 31)
>
>
> The other side (still Solaris) sees:
>
> WARNING: /pci@1f,4000/scsi@4/sd@4,0 (sd162):
> SCSI transport failed: reason 'reset': retrying command
>
> I don't see a gap in transfers from the Solaris side. It's also now true
> in this configuration that the Solaris side has lower priority (at ID 6).
May-be that means that Linux is not wasting SCSI BUS bandwitch which may
appear as a good thing.
> >
> > 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).
>
> Next on my list... I'm running wads of tests right now. When the
> complete, I'll rehook the UltraLinux.
>
> -matt
>
G�rard.
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
