Roman Fietze wrote: > Hello, > > I think this is a never ending story. This error still happens under > higher load every few seconds, until I get a "PHY: f0003000:00 - Link > is Down", on my box easiliy reproducable after maybe 15 to 30 seconds. > I can recover using "ip link set down/up dev eth0". > > I double checked that I'm using the most recent version of this driver > (checked with DENX, benh master/next, using Wolfgang Denk's version of > the 2.6.33), this includes the locking patches from Asier Llano, the > hard setting of mii_speed in the PHY mdio transfer routine of course. > I tried all 8 combinations of PLDIS, BSDIS and SE, with and without > CONFIG_NOT_COHERENT_CACHE. > > As some of you probably remember, I'm running this controller under > high load on FEC, ATA and LPC. As soon as "the" load is going above a > certain level I get those FEC RFIFO errors, sometimes ATA errors > (MWDMA2) and sometimes even lost SDMA interrupts using BestComm with > the SCLPC (now switched back to simple PIO). I quite sure almost all > of this is the BestComm's fault.
This problem shows up quickly with NAPI, but I have never observed it with the current version. The error occurs when the software is not able to readout the messages in time. Unfortunately, dealing with Bestcomm is a pain. > Did somebody already try the latest NAPI patches, which might give me > a slight chance to have a workaround? Any idea or upcoming patch to > address this problem once more, and if it's just by recovering e.g. > within mpc52xx_fec_mdio_transfer's timeout using some other dirty > workaround? Yes, I have a NAPI version ready for testing. I will roll it out as RFC today or tomorrow. Wolfgang. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev