From owner-freebsd-current@FreeBSD.ORG Fri Jul 30 13:06:29 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 79E4B16A4CE; Fri, 30 Jul 2004 13:06:29 +0000 (GMT) Received: from spider.deepcore.dk (cpe.atm2-0-53484.0x50a6c9a6.abnxx9.customer.tele.dk [80.166.201.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id CDC9543D53; Fri, 30 Jul 2004 13:06:28 +0000 (GMT) (envelope-from sos@DeepCore.dk) Received: from [194.192.25.132] (current.deepcore.dk [194.192.25.132]) by spider.deepcore.dk (8.12.11/8.12.10) with ESMTP id i6UD6MBE011919; Fri, 30 Jul 2004 15:06:27 +0200 (CEST) (envelope-from sos@DeepCore.dk) Message-ID: <410A47C7.1080808@DeepCore.dk> Date: Fri, 30 Jul 2004 15:06:15 +0200 From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= User-Agent: Mozilla Thunderbird 0.7.1 (X11/20040711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Maxim Sobolev References: <410A3833.7030502@portaone.com> In-Reply-To: <410A3833.7030502@portaone.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-mail-scanned: by DeepCore Virus & Spam killer v1.4 cc: current@freebsd.org cc: release@freebsd.org cc: sos@freebsd.org Subject: Re: Is there still sufficient reason for hw.ata.atapi_dma being 0 by default? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jul 2004 13:06:29 -0000 Maxim Sobolev wrote: > Since high-speed CD-RW/DVD-RW recorders (32x - 52x) are commodity now > IMO it makes sense to review hw.ata.atapi_dma default of 0, since > apparently PIO mode can't support necessary sustained data transfer > rates anymore. For example I had had problems burning RWs on 16-24x with > several drives in PIO mode, which gone when I've switched to DMA. Hmm, things are still messy, but most drives that support UDMA33 can do ATAPI dma. However, that is only part of the equation, the chipset has its hands in there as well, and unfortunatly there seems to be no good way to detect when it works and when it doesnt. This is more of a decision thing, until now its been decided to have it off by default, if there is consensus to change it, I'll just do that and only enable dma on udma33 and above (is there any such animals at all, I've newer seen an ATAPI device support > UDMA33). -Søren