On Thu, Dec 20, 2007 at 12:57:38PM -0700, Jim Bernard wrote:
> On Wed, Dec 19, 2007 at 08:55:53PM +0100, Manuel Bouyer wrote:
> > > It's when the disk is configured that the mode is downgraded:
> > > 
> > > wd2 at atabus2 drive 0: <WDC WD5000AAKS-00YGA0>
> > > wd2: drive supports 16-sector PIO transfers, LBA48 addressing
> > > wd2: 465 GB, 969021 cyl, 16 head, 63 sec, 512 bytes/sect x 976773168 sectors
> > > wd2(viaide1:0:0): using PIO mode 0
> > > 
> > >   Does it actually use DMA for the disk(s)?
> > 
> > No.
> > It's strange that the drive doesn't report any supported PIO or DMA mode.
> 
>   Thanks for taking a look at this.  If you look at my original posting
> in this thread, you'll get a much better idea of what is happening, since
> it includes lots of debugging output.  Basically, when the driver is
> testing the supported PIO modes, it waits for WDCS_DRQ to be deasserted,
> and that never happens.  It times out testing each of the first two PIO modes:
> 
> ata_set_mode=0xc
> ...
> __wdcwait: viaide1:0: timeout (time=11), status 58 error 0 (mask 0x8 bits 0x0)
> ...
> ata_set_mode=0xb
> ...
> __wdcwait: viaide1:0: timeout (time=11), status 58 error 0 (mask 0x8 bits 0x0)
> ...
> __wdccommand_done viaide1:0:0 flags 0x108
> wd2(viaide1:0:0): using PIO mode 0
>   
> and then gives up without testing for DMA support.  That's in ata_probe_caps
> in ata.c, where a comment says "We didn't find a valid PIO mode.  Assume the
> values returned for DMA are buggy too."  BTW: increasing the timeout by a
> factor of 100 didn't help, so I don't think it's a timing issue.
> 
>   Now status 58 is (from atareg.h):
> WDCS_DRDY (drive ready) | WDCS_DSC (drive seek complete) | WDCS_DRQ (data request),
> where WDCS_DRQ = 0x8.  Is it possible that it's unnecessary to wait for
> WDCS_DRQ in this case, where you're just setting a mode (ata_set_mode=0xc) and
> not wanting to retrieve data from the platter?

No, at this point we're waiting for WDCS_DRQ to be clear. If it's set,
there is already a transfer in progress and the drive it not ready to accept
a new command.

> I don't know anything about
> ATA protocols, so I have no idea.  BTW: I haven't explicitly looked at the
> values returned by ata_get_params in params.atap_piomode_supp and
> params.atap_dmamode_supp; I should probably do that, but may not be able to
> do it soon.
> 
>   The fact that it worked at full speed with dma under knoppix indicates that
> it can be done.  The question is how difficult it is to fix, and whether it's
> preferable just to buy a different card and hope it works better, i.e., that
> it's a problem with support for the card and not a drive quirk.

It may be a drive problem at this point. The best way to know would be
to test the controller with another drive, if you have one handy.

-- 
Manuel Bouyer <bouyer@antioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la difference
--