Messages in this thread |  | | From | (Philippe Strauss) | Subject | Re: Oopses with 2.1.8 | Date | Thu, 14 Nov 1996 18:27:14 +0100 (MET) |
| |
Hi Gerard,
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 Belmont
Email: <philippe.strauss@urbanet.ch> Homepage: http://sicel-home-1-4.urbanet.ch
|  |