Hi,
trying to find out, why the CMD646 (rev 01) IDE controller does corrupt my
file system on my PWS (Alpha) when writing in DMA mode, I started to wonder
about a number of things.
The pattern of the corruption is characteristic:
root@pws:/media/test/Dio/Diamonds # cmp -l copy original
8193 377 70
8194 373 71
8195 220 40
8196 144 50
16385 70 47
16386 71 367
16387 40 152
16388 50 341
24577 47 20
24578 367 342
24579 152 136
24580 341 202
always the first 4 bytes of a page still showing the old contents.
To me this looks like either a some very weird bug in the chipset or more
likely like races between BM DMA and the CPU write buffers/caches. The
latter can easily be the case on Alpha, as there is _no_ implicit ordering
on any operation on the Alpha, not even interrupts, PAL calls, ...
Following the latter somewhat more, I found that the pcilogicisp driver
which works well, does have a number of mb() commands; the whole IDE code
does not have any of those.
I would imagine that the following barriers are nacessary:
* After setting up the IDE DMA tables (PRD) and having the data there,
we need to have a barrier before telling the controller to do DMA.
* After the controller is done with it, we need to make sure the
data is in mem before we use it (i.e. we need some mb() equiv on the
controller)
* Some more less obvious ones probably ...
The Alpha Architecture manual sec. 5.6.4 gives some more info on how to
insure ordering of concurrent data access on shared memory.
Anyone familiar with IDE able to identify the necessary places in ide-dma
and/or cmd64x ?
Regards,
-- Kurt Garloff <garloff@suse.de> Eindhoven, NL GPG key: See mail header, key servers Linux kernel development SuSE GmbH, Nuernberg, DE SCSI, Security
This archive was generated by hypermail 2b29 : Fri Dec 07 2001 - 21:00:32 EST