Date: Sat, 31 Jul 2004 12:01:31 -0400 From: Chuck Swiger <cswiger@mac.com> To: =?ISO-8859-1?Q?S=F8ren_Schmidt?= <sos@DeepCore.dk> Cc: current@freebsd.org Subject: Re: Is there still sufficient reason for hw.ata.atapi_dma being 0 by default? Message-ID: <410BC25B.8000803@mac.com> In-Reply-To: <410AAEE4.7070409@DeepCore.dk> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?410BC25B.8000803>