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 transferAre 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.
pgpXPDVyEnoYv.pgp
Description: PGP signature
_______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev