Re: HPT372 DMA corruption

From: Andre Hedrick
Date: Thu Jan 22 2004 - 21:32:01 EST



It has NOTHING to do with VIA!

It has everything to do with a missing function th hpt366.c code.

It is all about what the FIFO thresholds are wrt to when interrupts are
issued and a pre-emptive like notification.

I am waiting on one of my customers report they are happy with the fix and
will ship the fix before I release it to the public. I have this serious
problem on not testing volitale patches on the general masses.

In my opinion, after several weeks of hard-on testing, the changes are
clean, correct, and exact.

Noting this type of patch would not be doable, had I not split the
individual dma operations way back when.

And yes for the remainder of the peanut gallery, I will "SHUT UP" for now.

Cheers,

Andre Hedrick
LAD Storage Consulting Group

On Wed, 14 Jan 2004, Måns Rullgård wrote:

> Chuck Berg <chuck@xxxxxxxxxx> writes:
>
> > On Fri, Jan 09, 2004 at 03:24:28PM -0500, Richard B. Johnson wrote:
> > [cmp -l bad good]
> >> > 89260029 0 31
> >> > 89260030 0 327
> >> > 89260031 0 200
> >> > 89260032 0 13
> >>
> >> Since whole bytes are not written, this looks strangely like
> >> an attempt to DMA to cached RAM! Since the CPU didn't write
> >
> > I tested this by reading with O_DIRECT, and immediately after each read(),
> > read all of a 1MB array (my cache is only 256kB), and then checking the
> > data. The same corruption occurs.
> >
> > Via had a DMA corruption bug a couple years ago with similar symptoms,
> > apparently with the VT82C686B southbridge. Mine is a VT82C586B (which some
> > people also reported problems with). My board dates long after these
> > problems were discovered, so I sure hope it's not the same bug. I'll try
> > upgrading my BIOS to the latest version in case Soyo's changelog is not
> > entirely honest.
>
> Well, VIA never did have a good reputation.
>
> > I did learn some more about the pattern of corruption. The data is not
> > being written to memory - the "bad" data is whatever happened to be there
> > before. It usually happens in 4, but sometimes 64 or 32 byte chunks.
>
> Is it always a multiple of 4 bytes? Is there any pattern in the
> position of the corruption, such as always aligned to some value?
>
> > When I read from the device with O_DIRECT, the corruption only
> > appears at the very end of the read. I've confirmed this for reads
> > of 512 bytes through 256k at multiples of 512 bytes.
>
> Could something be cutting off the DMA transfer too early?
>
> --
> Måns Rullgård
> mru@xxxxxx
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/