On Tue, 26 Feb 2002, Alan Cox wrote:
> > I have a lot of ServerWorks OSB4 IDE hardware, which has the annoyingly
> > suboptimal behavior of corrupting filesystems when DMA is active.
>
> With newer kernels you should get a panic because we spot the "I'm going
> to get 4 bytes stuck in the FIFO and DMA your inodes shifted 4 bytes down the
> disk behaviour" - at least in the cases I could study
>
> What set up do you have ?
>
> > Unfortunately, serverworks.c (in recent 2.4, at least) does not honor
> > the CONFIG_IDEDMA_AUTO config option -- it turns dma on only unless
> > "ide=nodma" is set on the kernel command line.
>
> You actually really to just turn off UDMA from experience.
>
> > if (hwif->dma_base) {
> > +#ifdef CONFIG_IDEDMA_AUTO
> > if (!noautodma)
> > hwif->autodma = 1;
> > +#endif
>
> I would have expected this to be a fix in the core code to ignore
> hwif->autodma but I'll admit I've not looked to see if that is practical.
It is not practical and it was absorbed via distos which are/were
generally paranoid of DMA because of the total number of ATAPI devices
that live in SFF-8020/8070 but claim ATA/ATAPI-4 so who knows or cares.
The real solution for distros is to wrapper the dma_capable flags in the
module cores in 2.4 under the disk_only. Also not setting
CONFIG_IDEDMA_AUTO will help but you are not permitted to invoke
echo using_dma:1 > /proc/ide/hda/settings
One of the issues to be address is a test for transfer modes, but have to
many other issues to address w/ clients to deal with distro issues.
Cheers,
Andre Hedrick
Linux Disk Certification Project Linux ATA Development
-
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/
This archive was generated by hypermail 2b29 : Thu Feb 28 2002 - 21:00:25 EST