[lkml]   [2002]   [Sep]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Warning - running *really* short on DMA buffers while doingfiletransfers
    > Since your drive cannot handle 253 tags, when saturated with commands,
    > a new command is never submitted to the drive directly. Instead the
    > command waits in the aic7xxx driver's queue until space is available
    > on the device. In FreeBSD, this never happens as tag depth is known
    > to, and adjusted by, the mid-layer. In Linux I must report the queue
    > depth without having sufficient load or history with the device to
    > know anything about its capabilities so I have no choice but to
    > throttle internally should the device support fewer tags than
    > initially reported to the OS. You can determine the actual device
    > queue depth from "cat /proc/scsi/aic7xxx/#". Run a bunch of I/O first
    > so that the tag depth gets locked first.

    Linux is perfectly happy just to have you return 1 in queuecommand if the
    device won't accept the tag. The can_queue parameter represents the maximum
    number of outstanding commands the mid-layer will ever send. The mid-layer is
    happy to re-queue I/O below this limit if it cannot be accepted by the drive.
    In fact, that's more or less what queue plugging is about.

    The only problem occurs if you return 1 from queuecommand with no other
    outstanding I/O for the device.

    There should be no reason in 2.5 for a driver to have to implement an internal


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:29    [W:0.020 / U:17.744 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site