Messages in this thread | | | From | Bartlomiej Zolnierkiewicz <> | Subject | Re: Quick question about libata and hdparm | Date | Thu, 23 Apr 2009 23:31:13 +0200 |
| |
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |