On Fri, Feb 08, 2008 at 12:22:38AM -0200, Carlos A. M. dos Santos wrote: >Wow, now I'm *really* surprised. I used to think that putting > > hw.ata.ata_dma="1" > hw.ata.atapi_dma="1"
hw.ata.ata_dma has no effect on ATAPI devices. >in /boot/loader.conf would be enough to enable DMA mode. Looking at the code, atapi_dma will enable UDMA modes if the drive supports at least UDMA2 them but ignores WDMA capabilities. This was part of the ATA mkIII update - which is in 6.x but was not MFC'd to 5.x. If you do a verbose boot, you will get a probe line reporting the drive capabilities. Unfortunately, atacontrol only reports 'dma [not] supported' - not what capabilities the drive has. >1. Is this related to using atapicam? No. >2. Should this be considered a bug? Possibly. The relevant commit message doesn't mention the ATAPI DMA changes so it's not clear whether this is an oversight or deliberate. I do recall that there have been problems in the past with ATAPI drives that would advertise DMA capabilities but would misbehave if you used DMA (atapi_dma was disabled by default in 5.x for this reason). I'm not sure if the current code is at effort to avoid this. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour.
pgpIQYQNr4R4r.pgp
Description: PGP signature
