lkml.org 
[lkml]   [1996]   [Nov]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: Oopses with 2.1.8
    Date

    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

    \
     
     \ /
      Last update: 2005-03-22 13:38    [W:0.024 / U:60.612 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site