ServerWorks autodma behavior

There wasn't a specific MAINTAINER for this stuff, other than perhaps Andre Hedrick by proxy, so I decided it might be best to post this directly.

I have a lot of ServerWorks OSB4 IDE hardware, which has the annoyingly suboptimal behavior of corrupting filesystems when DMA is active. 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.

Personally, I think the correct behavior is for the subdrivers to honor this config value. However, only VIA behaves in this way, and PIIX only because of its funky CONFIG_PIIX_TUNING config. This obviates having to modify lilo.conf (or similar) on all machines, and having to remember to do so, etc etc.

The alternative is that, somewhat unintuitively, the correct behavior is for the subdrivers to make their own non-CONFIGurable decisions on DMA. In this case, VIA and PIIX should be corrected, I would think.

In any case, I've appended the patch I'm using to be able to turn off auto-DMA at config-time rather than run-time for ServerWorks. One alternative is to shed this code altogether, since ide-pci.c seems to set a rational default.

I just wanted to see if there was any clear consensus on this -- I'd be glad to whip out patches for either behavior.

Thanks,

Ken.
[email protected]


--- linux/drivers/ide/serverworks.c.orig	Sun Sep  9 10:43:02 2001
+++ linux/drivers/ide/serverworks.c	Tue Feb 26 00:39:17 2002
@@ -590,8 +590,10 @@
 #else /* CONFIG_BLK_DEV_IDEDMA */
 
 	if (hwif->dma_base) {
+#ifdef CONFIG_IDEDMA_AUTO
 		if (!noautodma)
 			hwif->autodma = 1;
+#endif
 		hwif->dmaproc = &svwks_dmaproc;
 	} else {
 		hwif->autodma = 0;

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 ?

You actually really to just turn off UDMA from experience.

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

On Tue, Feb 26, 2002 at 01:37:55AM -0800, Andre Hedrick wrote:
[...]

| 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

I noticed that "hdparm -d1 /dev/hda" timed out three times and reverted to PIO in my case, with DMA enabled but autoDMA disabled. So does DMA support have to be on at boot and is only allowed to be disabled, not enabled?

If so, ide=dma is the proper solution for trusted boards, but it would be nice if the /proc or hdparm interfaces worked reliably for enabling DMA.

So what does this say about the autoDMA issue that I'm seeing? For me, the best of both worlds is to have DMA enabled, but off by default and capable of being enabled from userspace (and kernel command line, less usefully).

Thanks,

Ken.
[email protected]


| 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

Here is the skinny.

Running DOMAIN VALIDATION against the HOST just totally throttles the silicon-dma-core. Basically direct access force the hardware to protect itself from pushing the limits of the access, it BLOWS CHUNKS like a freshman in college on his/her first drunk.

If you run the it top down via block, the mainloop eases alot of the pressure. The punch line is like this .........

DV(BLOWS CHUNKS) == Block_pressure(BLOWS CHUNKS)

If DV fails, you have not got a prayer of believing the physical is stable, IMHO.

Cheers,

Andre Hedrick
Linux Disk Certification Project Linux ATA Development

Does this mean the ServerWorks IDE chipset is buggy ?

On Tue, Feb 26, 2002 at 09:52:57AM +0000, 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 ?

These machines are Tyan Thunder LE (S2510) non-SCSI boards with Seagate drives. Dual-P3.

| > 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.

Yeah -- but I'd like to be able to enable it if I need the performance on a more DMA-able motherboard. Turning it off entirely would have worked, of course.

| >  	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.

That may be -- I was sticking with the obvious, least-invasive, least IDE-core-clued evaluation. :) This is also the same treatment of noautodma found in the VIA driver. The autodma setting from ide-pci does seem to be correct -- deleting the code segment produces the same DMA end-results, in the end, for ServerWorks.

Thanks much,

Ken.
[email protected]

I think (not 100% becouse not re-checked against the code), you could just have removed the lines

if (!noautodma)

	hwif->autodma = 1;

and all should be well ;-).

On Tue, Feb 26, 2002 at 12:12:46PM +0100, Martin Dalecki wrote:
| Ken Brownfield wrote:
[...]

| > In any case, I've appended the patch I'm using to be able to turn off
| > auto-DMA at config-time rather than run-time for ServerWorks.  One
| > alternative is to shed this code altogether, since ide-pci.c seems to
| > set a rational default.
| 
| I think (not 100% becouse not re-checked against the code),
| you could just have removed the lines
| 
| if (!noautodma)
| 	hwif->autodma = 1;
| 
| and all should be well ;-).

Yes, and that's what I found as well. That was my first patch until I noticed the AUTO check in the VIA driver around this same code.

That being said, which of these solutions is worthy of going into the kernel (if any) and should that decision be applied to the other IDE drivers?

I feel like I'm okay with my own little patchbase, but this seems like a useful type of change to make for everyone and all drivers in 2.4 (and 2.5 if it's even still applicable). And it's just dirt simple enough for me to do it. ;)

Thanks,

Ken.
[email protected]

I rather think that VIA could be cured the same way.