From owner-freebsd-scsi Wed Jan 7 10:11:28 1998 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA23324 for freebsd-scsi-outgoing; Wed, 7 Jan 1998 10:11:28 -0800 (PST) (envelope-from owner-freebsd-scsi) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA23304 for ; Wed, 7 Jan 1998 10:11:14 -0800 (PST) (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.8.8/8.7.3) id LAA09578; Wed, 7 Jan 1998 11:08:45 -0700 (MST) Date: Wed, 7 Jan 1998 11:08:45 -0700 (MST) From: "Justin T. Gibbs" Message-Id: <199801071808.LAA09578@narnia.plutotech.com> To: Andrew Gallatin Subject: Re: painfully slow crashdumps Newsgroups: pluto.freebsd.scsi In-Reply-To: <199801061941.OAA17352@hurricane.cs.duke.edu> cc: scsi@FreeBSD.org User-Agent: tin/pre-1.4-971204 (UNIX) (FreeBSD/3.0-CURRENT (i386)) Sender: owner-freebsd-scsi@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk In article <199801061941.OAA17352@hurricane.cs.duke.edu> you wrote: > However, I know next to nothing about the scsi programming interface. > I randomly chose N=8 (which yields a crashdump in ~50 seconds, or > about 2.5MB/sec), but I'm concerned I may run across a hardware > combination that cannot handle a transaction this large. Is this a > valid concern? How can I determine the maximum transaction a > controller/disk can handle at runtime? This information will be available with the CAM SCSI code. The idea is to allow peripheral drivers (like the disk driver) to determine the most efficient I/O size for the device, a size that does not need to be coalessed before being sent to the device. In this way, the disk driver, which has more flexibility in how it writes things, can be smart about what it does, but for devices like tapes, where you have to write the whole block in one go, the bus_dma system will take care of coalessing the data. It would be nice to make dumps over 16MB work on ISA busmastering controllers too, so perhaps dump should attempt to "steal" a portion of the bounce buffer area. Since interrupts are disabled, held bounce buffer resources will not be freed, so you'd have to do something to ensure you get the resources you need. > ------------------------------------------------------------------------------ > Andrew Gallatin, Sr Systems Programmer http://www.cs.duke.edu/~gallatin > Duke University Email: gallatin@cs.duke.edu > Department of Computer Science Phone: (919) 660-6590 -- Justin T. Gibbs =========================================== FreeBSD - Turning PCs into workstations ===========================================