Messages in this thread | | | Date | Tue, 26 Feb 2002 01:37:55 -0800 (PST) | From | Andre Hedrick <> | Subject | Re: [PATCH][RFC] ServerWorks autodma behavior |
| |
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/
| |