From owner-freebsd-current  Tue May 16 05:43:01 1995
Return-Path: current-owner
Received: (from majordom@localhost)
          by freefall.cdrom.com (8.6.10/8.6.6) id FAA09047
          for current-outgoing; Tue, 16 May 1995 05:43:01 -0700
Received: from Root.COM (implode.Root.COM [198.145.90.1])
          by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id FAA09041
          for <current@freebsd.org>; Tue, 16 May 1995 05:42:58 -0700
Received: from corbin.Root.COM (corbin.Root.COM [198.145.90.18]) by Root.COM (8.6.8/8.6.5) with ESMTP id FAA07656; Tue, 16 May 1995 05:46:02 -0700
Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.11/8.6.5) with SMTP id FAA01807; Tue, 16 May 1995 05:43:00 -0700
Message-Id: <199505161243.FAA01807@corbin.Root.COM>
To: Peter Dufault <dufault@hda.com>
cc: current@FreeBSD.org
Subject: Re: big files written to scsi harddisk got corrupted 
In-reply-to: Your message of "Tue, 16 May 95 08:18:07 EDT."
             <199505161218.IAA24599@hda.com> 
From: David Greenman <davidg@Root.COM>
Reply-To: davidg@Root.COM
Date: Tue, 16 May 1995 05:42:59 -0700
Sender: current-owner@FreeBSD.org
Precedence: bulk

>>    The Adaptec 1542A is known to corrupt data for DMA's that are larger than
>> 16Kbytes. FreeBSD uses I/O clustering both in the file I/O system and in the
>> VM system and DMA's are frequently larger than 16Kbytes. There are apparantly
>> some versions of the 1542A that don't have this problem, but every one that
>> I've tested does. If you upgrade the controller to a 1542B, the problems
>> should go away.
>> 
>
>Can we just put in a minphys for 16K for the 1542A?

   I'm not sure I grok your question. Do you mean add something to limit the
maximum DMA transfer size to 16K? If so, yes, this would be a good idea - we
need some sort of mechanism to limit the maximum transfer size. It would be
nice if the SCSI code could break up requests that exceed it and do then do
the I/O in smaller chunks. This doesn't sound very easy to implement, however.
   I was able to work around the problem back in 1.1.5 by modifying the kernel
in various places to limit the I/O clustering to 16K or less, but with the 4.4
VFS layer clustering, this becomes more difficult.

-DG