From owner-freebsd-current@FreeBSD.ORG Sat Jul 31 16:01:35 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 5696D16A52A for ; Sat, 31 Jul 2004 16:01:35 +0000 (GMT) Received: from out009.verizon.net (out009pub.verizon.net [206.46.170.131]) by mx1.FreeBSD.org (Postfix) with ESMTP id DCE1743D31 for ; Sat, 31 Jul 2004 16:01:34 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from [192.168.1.3] ([68.161.100.95]) by out009.verizon.net (InterMail vM.5.01.06.06 201-253-122-130-106-20030910) with ESMTP id <20040731160134.PAQF23440.out009.verizon.net@[192.168.1.3]>; Sat, 31 Jul 2004 11:01:34 -0500 Message-ID: <410BC25B.8000803@mac.com> Date: Sat, 31 Jul 2004 12:01:31 -0400 From: Chuck Swiger Organization: The Courts of Chaos User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.1) Gecko/20040707 X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?S=F8ren_Schmidt?= References: <410A3833.7030502@portaone.com> <410A47C7.1080808@DeepCore.dk> <410A9B58.8000502@mac.com> <410A9D77.4030703@DeepCore.dk> <410AA5A5.4000001@mac.com> <410AAEE4.7070409@DeepCore.dk> In-Reply-To: <410AAEE4.7070409@DeepCore.dk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Authentication-Info: Submitted using SMTP AUTH at out009.verizon.net from [68.161.100.95] at Sat, 31 Jul 2004 11:01:34 -0500 cc: current@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: Sat, 31 Jul 2004 16:01:35 -0000 Søren Schmidt wrote: > Chuck Swiger wrote: >> [ FWIW, I've got a 16/10/40x Yamaha burner which just predates the >> first generation of burners with underrun protection-- this affects me >> directly. ] > > Hmn, you should be able to burn 16x in PIO4 mode... It's like trying to burn at 4x over a USB 1 channel-- 4x times 300KBs *fits* into 10Mbs, but not by much, and not if anything else is taking some bandwidth. I almost always have another device (generally another CD-ROM or DVD-ROM drive) sharing the secondary IDE channel with a burner. For what it's worth, enabling atapi_dma seems to help a significant fraction of the people using the dvd+rw-tools port, although issues with ATAPICAM are more common. >> Oh. Ewww. Could chipsets which do that be added to a "quirks" table >> similar to the way USB devices are being handled? Or is it not just >> the chipset, but some more complex interaction between ATAPI DMA and >> other devices in the system which want to do DMA which causes the lockup? > > Right, its a combination of chipset and device, the matrix would be > impossible to maintain. I would feel the same way about trying to make the ATA code work on devices I didn't have available to test, but you're doing a remarkable job of handling impossible tasks right now, Soren. :-) -- -Chuck