lkml.org 
[lkml]   [2000]   [Feb]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: sym53c8xx syslog messages from 2.2.14

    On Mon, 21 Feb 2000, Ricky Beam wrote:

    > On 21 Feb 2000, Patrick J. LoPresti wrote:
    > >One of our systems (running stock 2.2.14) is generating syslog
    > >messages like these very frequently, especially when the machine is
    > >busy. I tried lowering the TCQ depth to 8 but it did not make any
    > >difference.
    >
    > How did you set it to 8? You may need to wack the kernel with a 2x4
    > to get it to behave (read: delete sections of the scsi driver.) You
    > are free to use that same 2x4 on Quantum and the scsi driver author.

    For the [sym/ncr]53c8xx driver, you must refer to:

    /usr/src/linux/drivers/scsi/README.ncr53c8xx

    > >Could someone tell me what they mean and how I can make them stop?
    >
    > First off, the driver attempts to ajust the queue depth based on
    > a number of factors (only one of which is the user.) On a QUEUE FULL
    > condition from the drive, the driver drops the queue depth down to
    > how ever many commands are currently queued. The queue depth is increased
    > after 1000 commands are successful.
    >
    > First off, the SCSI specs say any device reporting tagged command queuing
    > capabilties MUST support a minimum of 8 queued commands. Thus, setting it
    > lower than 8 should never be necessary. HOWEVER, some manufacturers'
    > (read: Quantum) drives "don't work right." They signal command completion
    > before they are ready for the next command -- who knows what kind of crazy
    > shit is going on in the microcode.

    I have 1 Atlas 1, 2 Atlas 2 and 1 Atlas 4. The Atlas 4 is a lot better,
    but the driver copes with all these drives.

    > The Quantum Altas I was _very_ _very_ bad at handling queuing. They fixed

    You get with Quantum Atlas < 4 drives in mono-initiator what you get with
    any other drive in multi-initiator environment. A SCSI subsystem that can
    work in multi-initiator environment must work with Quantum drives.

    > some of it in later microcode, but it still lies about command completion.
    > (I should be able to remove power from the drive the instant it signals
    > command completion.)

    I does lie only if you enable write behind caching and FUA bit is not set
    for writes, which is correct.

    > You will need to set the queue depth to _8_ and make sure the damned driver
    > never tries to change it.

    /usr/src/linux/damned_drivers/scsi/README.ncr53c8xx

    > On QUEUE FULL, the driver should wait a second
    > and _then_ re-queue the command. I had similar problems with a qlogicpti
    > like board in a sparc20 -- in that case, it was the card's command queue
    > overflowing instead of a drive, but same difference.

    The suggested method is to wait for a command completion from the
    offending device prior to requeuing any subsequent command to this device.
    The sym53c8xx driver does shrink its internal device queue depth up to the
    number of _actually_ disconnect commands which has the _same_ effect.

    Then, the device queue depth will be incremented later based on some fixed
    amount of _successful_ commands. This scales quite well with a very low
    overhead. This has been implemented and tuned based on the behaviour of
    Atlas drives.

    Gérard.

    > --Ricky
    >
    > PS: I've got some IBM drives eating 64 queued commands :-) This introduces
    > some interesting behavior from the kernel thinking commands are timing
    > out :-) (4M buffer on the drive, BTW)

    I have such a 10000 rpm drive. I use it with 32 tags under Linux and 64
    tags under FreeBSD. No problem.
    Btw, the Viking II from Quantum also supports such an amount of tagged
    commands (may-be only 63, but it is equivalent). This depends mostly on
    the firmware.


    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.rutgers.edu
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:56    [W:4.349 / U:0.012 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site