Digital PWS: Still IDE DMA corruption w/ 2.4.18

• Next message: Suparna Bhattacharya: "Re: Faster reboots (and a better way of taking crashdumps?)"
• Previous message: David Schwartz: "Re: Memory Leaking. Help!"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Hi Ivan, Jay, Richard,

I once complained about IDE DMA data corruption on my Digital Personal
Workstation (Miata). The corruption would occur every fourth or fifth 8k
block that was written to disk and only the first couple of bytes were
affected.
I came up with a workaround in ide-dma.

The problem was identified as being a documented (well, if you can get the
documents) chipset bug on the pyxis (21174) chipset used on Miata MoBo.

Ivan came up with a better fix: Instead of a hack breaking down the segments
into 8k blocks in ide-dma, he just disabled the hardware SG support on
affected Miatas, so the normal sg_map() call would do the breaking down.

I then tested Ivan's test and reported it to work.
Ivan's patch was merged in the 2.4.18pre3 kernel (misattributed to RTH).

I was not entirely correct, though :-(
Here's what my 2.4.18 kernel says on bootup:
pci: pyxis 8K boundary dma bug - sg dma disabled
So Ivan's patch is active.

But occasionally, I see corruption. It happens about once per 100MB written
to disk. Again it happens at the start of an 8k block. Between 4 and 36
bytes are affected. (See the hexified output of a cmp -l attached in
cmp.SL80-ISO7-ISO7.bad).

I don't know exactly what happens there, but I imagine that despite having
disabled HW SG support, the occasionally allocates two contigous 8k blocks
and the sg_map() function will just make one 16k segment from it. So we
still do a busmaster DMA read across a page boundary: Boom!

So, I revamped my workaround in ide-dma to make sure no segments larger than
8k get through for write operations ...
The patch does prevent the corruption of data, so I assume my above
speculation is about right.
Patch against 2.4.18 is attached.

Note: Even with the patch applied, I found data corruption twice (bit 1
cleared on a byte with offset 0xXXXXX063), but I'd guess this is yet another
unrelated thing (firmware, cables, kernel bug). But I could only trigger this
once so far (after transfering something like 5GB).

Regards,

-- 
Kurt Garloff  <garloff@suse.de>                          Eindhoven, NL
GPG key: See mail header, key servers         Linux kernel development
SuSE Linux AG, Nuernberg, DE                            SCSI, Security

• text/plain attachment: cmp.SL80-ISO7-ISO7.bad

• text/plain attachment: pyxis-ide-dma-pagecross-2418.diff

• application/pgp-signature attachment: stored

• Next message: Suparna Bhattacharya: "Re: Faster reboots (and a better way of taking crashdumps?)"
• Previous message: David Schwartz: "Re: Memory Leaking. Help!"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

This archive was generated by hypermail 2b29 : Mon Apr 15 2002 - 22:00:24 EST