Manuel,

Yep, that fixed it:

pciide1 at pci0 dev 13 function 0: CMD Technology PCI0649 (rev. 0x02)
pciide1: bus-master DMA support present
pciide1: primary channel configured to native-PCI mode
pciide1: using irq 10 for native-PCI interrupt
wd0 at pciide1 channel 0 drive 0: <SAMSUNG SV4084H>
wd0: drive supports 16-sector PIO transfers, LBA addressing
wd0: 38931 MB, 16383 cyl, 16 head, 63 sec, 512 bytes/sect x 79730784 sectors
wd0: 32-bit data port
wd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 5 (Ultra/100)
wd0(pciide1:0:0): using PIO mode 4, Ultra-DMA mode 5 (Ultra/100) (using DMA data transfers)
pciide1: secondary channel configured to native-PCI mode
wd1 at pciide1 channel 1 drive 0: <WDC WD1000BB-00CCB0>
wd1: drive supports 16-sector PIO transfers, LBA addressing
wd1: 95396 MB, 16383 cyl, 16 head, 63 sec, 512 bytes/sect x 195371568 sectors
wd1: 32-bit data port
wd1: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 5 (Ultra/100)
wd1(pciide1:1:0): using PIO mode 4, Ultra-DMA mode 5 (Ultra/100) (using DMA data transfers)

On Wed, 14 Nov 2001, Manuel Bouyer wrote:

> Date: Wed, 14 Nov 2001 20:55:51 +0100
> From: Manuel Bouyer <bouyer@antioche.eu.org>
> To: Ron Roskens <roskens@elfin.net>
> Cc: current-users@netbsd.org
> Subject: Re: CMD 649 pciide interface
>
> On Tue, Nov 13, 2001 at 11:38:05PM -0600, Ron Roskens wrote:
> > in src/sys/dev/pci/pciide.c in cmd0643_9_chip_map() there is a check for
> > both the 648 and 649 where it sets it to UDMA_cap to 4. Should it
> > really be setting this to 5 for the 649 since its UDMA/100 capable?
>
> OK, I just looked at this; it appears that I didn't have the info available
> when I commited the cmd64[89] support (I don't really remember, to be honest :)
>
> The attached patch should do it, could you confirm it works OK ?
>
> --
> Manuel Bouyer <bouyer@antioche.eu.org>
> --
>

Elfin