Re: Quick question about libata and hdparm

[Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>]

On Thursday 23 April 2009 07:56:19 Rogério Brito wrote:
> Hi, Bart, Alan.
> 
> On Apr 21 2009, Bartlomiej Zolnierkiewicz wrote:
> > Incremental patch (a certain theory to verify).
> (...)
> > +	/* FIXME: this thrashes internal UDMA timings previously set by
> > +	   controller on SET FEATURES - XFER MODE command "snooping" */
> >  	/* The DMA clocks may have been trashed by a reset. FIXME: make conditional
> >  	   and move to qc_issue ? */
> > -	pdc202xx_set_dmamode(ap, qc->dev);
> > +	/* pdc202xx_set_dmamode(ap, qc->dev); */
> 
> This didn't work. I still get those same messages. If you want, I can try
> compiling the 2.6.30-rc3 kernel that was released now (as I mentioned
> before, I was using 2.6.29).

I think that testing -rc3 won't hurt but don't get your hopes too high. ;)

> I can test whatever you want me to.

You can try booting with "libata.force=1.00:mwdma2" kernel paramater to
force use of "regular" MWDMA2 transfer mode instead of UDMA ones so we are
sure that the issue is specific to pata_pdc202xx_old + UDMA.

Other than that I'm out of ideas, though the hint that the original driver
works just fine should help driver's maintainer in fixing this regression.

Thanks,
Bart