From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-out.m-online.net (mail-out.m-online.net [212.18.0.10]) by ozlabs.org (Postfix) with ESMTP id 93397B7CEF for ; Tue, 30 Mar 2010 21:47:52 +1100 (EST) Message-ID: <4BB1D674.2050800@grandegger.com> Date: Tue, 30 Mar 2010 12:46:12 +0200 From: Wolfgang Grandegger MIME-Version: 1.0 To: Roman Fietze Subject: Re: MPC5200B, many FEC_IEVENT_RFIFO_ERRORs until link down References: <201003301200.54609.roman.fietze@telemotive.de> In-Reply-To: <201003301200.54609.roman.fietze@telemotive.de> Content-Type: text/plain; charset=ISO-8859-1 Cc: linuxppc-dev@lists.ozlabs.org List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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.