Re: MPC5200B XLB Configuration Issues, FEC RFIFO Events, ATA Crashes

["Albrecht Dreß" <albrecht.dress@arcor.de>]

[-- Attachment #1: Type: text/plain, Size: 2295 bytes --]

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 #2: Type: application/pgp-signature, Size: 190 bytes --]