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;
> 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.
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
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]
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,
On Tue, 26 Feb 2002, Ken Brownfield wrote:
> 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
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
Andre Hedrick
Linux Disk Certification Project Linux ATA Development
Ken Brownfield wrote:
> 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 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 ;-).
Andre Hedrick wrote:
> 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.
Does this mean the ServerWorks IDE chipset is buggy ?
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]
Ken Brownfield wrote:
> 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.
I rather think that VIA could be cured the same way.