Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 27 Sep 2002 17:13:07 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 27 Sep 2002 17:13:07 -0400 Received: from beppo.feral.com ([192.67.166.79]:18194 "EHLO beppo.feral.com") by vger.kernel.org with ESMTP id ; Fri, 27 Sep 2002 17:13:05 -0400 Date: Fri, 27 Sep 2002 14:18:12 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: James Bottomley cc: "Justin T. Gibbs" , Andrew Morton , Jens Axboe , "Pedro M. Rodrigues" , Mathieu Chouquet-Stringer , linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: Warning - running *really* short on DMA buffers while doingfiletransfers In-Reply-To: <200209272113.g8RLD1420775@localhost.localdomain> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1018 Lines: 26 > > 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. Duh. There had been race conditions in the past which caused all of us HBA writers to in fact start swalloing things like QFULL and maintaining internal queues. > > There should be no reason in 2.5 for a driver to have to implement an internal > queue. That'd be swell. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/