Hello Albrecht, Sorry for the delay ... your mail got stuck in a Notes "spam filter".
On Friday 22 January 2010 21:11:39 Albrecht Dreß wrote: > Are there any "final" conclusions from your tests? Yes. For the small product using the 2.6 kernel we turned all snooping and the kernel coherent flag off, which avoided crashes of the FEC and/or hard disk since we introduced that change. We are currently investigating problems that we are seeing on the 2.4.25 (DENX and Lite5200B based) boards for a long time. Here we are having problems with corrupt filesystems and FEC hick ups. In this case we are using UDMA2, because we cannot yet get MWDMA2 work on 2.4.25, well knowing that there might be a problem with UDMA2 and LPC. So we also turned of snooping and are currently in the testing phase (again). > ... two compactflash cards with vfat file systems attached to the > ata bus; - a nfs3 network drive, connected via a 100MBit line, on a > Xeon serve Are you using MWDMA2 with the compact flash cards? What is the load on the different (DMA) channels? ATA reads or writes? > ... 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? Our latest product uses an SMSC MOST150 Spynic and an FPGA to sample data from a MOST ring via SCLPC+SDMA (single non BD task from the old Freescale Betstcomm API) on the 2.4.25. Here moving from memory accesses to SCLPC+SDMA helped somewhat, probably by avoiding the UDMA2/LPC problem by mainly letting the SDMA scheduler do the scheduling of the LPC traffic, which avoids the LPC arbiter problem "somehow". The probability for seeing problems or crashes increases a lot with the bandwidth. I think, and I might be wrong, esp. when an arbiter or scheduler (LPC/PCI or SDMA) needs to switch users or tasks. In our case we have data running with about 3-6 MB/s (avg.) via the LPC to the hard disks or somewhat more using FTP from the hard disk to the FEC. > I did not observe any issues The filesystem crashes are seldom, but happen often enough to be able to reproduce them once every 1 or 2 days under heavy load, and to produce failures in the field, what's even worse. And they statistically increased a lot wen we ran out of GPIO on the MPC5200B and then used an CPLD or FPGA to replace them, just a few bits to MUX SPI lines, but that was enough. > but your statements are making me really nervous... That was not my intention. The best thing is to run very ugly tests with very high load for at least 24h. Due to the fact that we see those problems on different boards we (the SW guys) no longer can assume self made HW problems (HW guys), esp. when reading Freescale's advice with the XLB config. It might happen that we switch to 2.6 on our older products, hoping that at least the LPC/IDE problem disappears by using MWDMA2 instead of UDMA2. Roman -- Roman Fietze Telemotive AG Büro Mühlhausen Breitwiesen 73347 Mühlhausen Tel.: +49(0)7335/18493-45 http://www.telemotive.de _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev