Gerard Roudier wrote:
>
> Sorry for my late reply. I only can read mail at evening and yesterday I
> did not have received your mail.
> Prior to posting the 1.14c patch, I have done some heavy tests under 2.1.8
> without problems.
> My current Linux is 2.0.25 + ncr1.14c. I donnot notice problems too.
> Obviously that does not prove 1.14c has no problems.
>
> I notice in another post that you have set max queued commands to 12.
Yes, but I stuff "settags 0 12" into /proc/scsi/ncr53c8xx/0
in my localconfig file. Setting CONFIG_SCSI_NCR53C8XX_TAGGED_QUEUE,
my zip drive or my cdrom (don't remember which) behave miserably at
boot. It enter a SCSI bus reset loop. ID 0 is my Seagate ST31200N
which is tag-cmd-queing-able.
iCONFIG_SCSI_NCR53C8XX=y
# CONFIG_SCSI_NCR53C8XX_TAGGED_QUEUE is not set
# CONFIG_SCSI_NCR53C8XX_IOMAPPED is not set
CONFIG_SCSI_NCR53C8XX_MAX_TAGS=12
CONFIG_SCSI_NCR53C8XX_SYNC=10
# CONFIG_SCSI_NCR53C8XX_NO_DISCONNECT is not set
# CONFIG_SCSI_NCR53C8XX_DISABLE_MPARITY_CHECK is not set
# CONFIG_SCSI_NCR53C8XX_DISABLE_PARITY_CHECK is not set
# CONFIG_SCSI_NCR53C8XX_FORCE_SYNC_NEGO is not set
> The queue depth will be set to this value for all devices that
> supports tagged commands even if tagged command is not yet enabled.
> That's due to a design lack in the middle scsi code.
> If your ZIP100 supports tagged commands (probably not), 12 is too big for it.
> With your configuration, 4 is a reasonnable value and 8 probably a maximum.
> I use only 8 queued commands with my Atlas Wide with 1MB internal cache.
I certainly lack a precise understanding of tag-cmd-queuing. I didn't look
too deep in the code either. How do you calculate the buffer-depth
needed in the disk to bear N tagged command? (Or better, how many
cmd can be buffered in the S sized buffer of the disk)?
> But 12 should work. You would probably have some risk of timeout or
> "queue full" scsi status, but not crash.
>
> I will not have time this evening to try linux-2.1.9.
> Can you check the driver source code you used in 2.1.8 against the source
> code available at the following location:
>
> ftp://linux.wauug.org/pub/roudier/ncrBsd2Linux-1.14c-src.tar.gz
doing diff between ncr53c8xx.[ch] returned nothing after patching
2.1.8 ncrBsd (1.14b) with the patch 1.14b->1.14c you posted on l-k.
> > 2.1.9 with Gerard's driver seem to work flawlessly,
> > despite the fact that 1.14c ncrBsd was crashing
> > 2.1.8.. Strange interaction, but it's OK now.
>
> It's strange, indeed. Let me know if all stay really ok with 2.1.9.
> I will check the driver source and run some tests.
> Your problem description looks like a bug in the driver but perhaps it is
> not.
> 1.14b to 1.14c is in my opinion a minor change and checking the source
> should be enough.
>
> Gerard.
>
Yeap, this bug is really a b*tch. I suspect interaction between
new TCP code and ncrBsd (how is another matter :), since most
change (bug fix) are in the ipv4 code in 2.1.9. I use
masquerading. Also, Philip Blundel reported very similar crash,
with *IDE* disk... Really not your fault there :).
And yes, 2.1.9 is stable with ncrBsd. I've not put a full feed
news server to push it to the limit, but doing usual stuffs
(kernel compile, debian cron job w find, other compile), everything
is OK.
Anyway, Thanks for helping, Philippe.
-- Philippe Strauss, CH-1092 BelmontEmail: <philippe.strauss@urbanet.ch> Homepage: http://sicel-home-1-4.urbanet.ch