> > Note that with this patch, all VIA users will get IDE transferrates
> > about 3 MB/sec as opposed to about 20 MB/sec without it (and with
> > UDMA66).
> >
> > Also note that enabling the DMA later with hdparm -X66 -d1 or similar
> > command is not safe, and usually works by pure luck on VIA chipsets.
> > This however, would need some non-minor changes to the generic code to
> > fix.
>
> _ouch_ Will -X66 -d1c1m16 be as stable with this patch as version 2.1e
> has been for me?? It has always (auto)set transfer speeds properly and
> I have never seen corruption with my 686a -- 'cept when patching from
> test11-pre7 to test12-pre1, and I'm pretty sure that was from other
> factors.
Well, can't tell. For some reason hdparm doesn't tell the VIA driver to
update the timings in the chipset when changing modes. The fact that
UDMA will start to work after this command is only due to that the VIA
chips do have a built in filter for UDMA commands, notice the command
sent to the harddrive, and switch the UDMA mode on. However the timings
stay as were, as perhaps the BIOS set them up. So it may work or may
not.
As I said, getting it to work reliably needs changes in the generic code
(hdparm should call the correct ioctl, and the ioctl must call the
timing routine in the specific chipset code).
If the patch I sent to Linus gets applied, I'll probably submit another
one that will allow to override the no-dma rule by a kernel command line
option, as Alan Cox suggested.
-- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/