Hi Roman:

Sorry for the long delay, I had to fix some other stuff first, before I could 
launch the test...  Here is just a short intermediate result.

Am 04.02.10 20:35 schrieb(en) Albrecht Dreß:
Actually, I forgot that I have to explicitly enable libata dma on the 5200b, 
due to the known silicon bugs...  I will repeat my tests with the proper 
configuration, stay tuned.

... a signal processor attached to the localbus, using bestcomm and the fifo 
for the bulk transfer

Are you using an own driver, or are you using Grant's SCLPC+SDMA driver? BD 
task?

Basically Grant's driver, but with a slightly modified variant of the gen_bd task.  
The signal processor is a LE, and I managed to insert the LE/BE conversion into the 
bestcomm task (see also <http://patchwork.ozlabs.org/patch/35038/>).  
Unfortunately, there is no good documentation of the engine; I would like to also 
shift crc calculation into bestcomm, which seems to be possible in principle, but I 
never got it running.

The best thing is to run very ugly tests with very high load for at least 24h.

I today launched my test application, on kernel 2.6.32 with a few minor tweaks, 
which runs 4 threads in parallel, all first writing a number of data blocks, 
then doing a sync() when appropriate, and reading reading them all back and 
checking the contents (md5 hash):
- one writes/reads back 256 files of 256k each to a nfs3 share on a Xeon 
server, using a 100 MBit line;
- one writes/reads back one 1 MByte block using BestComm to a Localbus device 
(see quote above);
- two write/read back 128 files of 64k each to two CF cards w/ vfat, both 
attached to the ata (master/slave).

Booting with 'libata.force=mwdma2', this tests reproducibly freezes the system 
*within a few minutes*, in one case leaving the vfat fs on one card completely 
broken.  The system didn't throw a panic, it was always simply stuck - no 
response to the serial console, nothing.

Booting *without* this option (i.e. using pio for the cf cards), the system 
seems to run flawlessly.  I will continue the test over the weekend (now active 
for ~5 hours), but it looks as if I can reproduce your problem.  Next week, 
I'll try your fix (hope I don't wear out the cf cards...), and re-run the test.

Best, Albrecht.

Attachment: pgpXPDVyEnoYv.pgp
Description: PGP signature

_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Reply via email to