public inbox for linuxppc-dev@ozlabs.org 
 help / color / mirror / Atom feed
From: Wolfgang Grandegger <wg@grandegger•com>
To: Roman Fietze <roman.fietze@telemotive•de>
Cc: linuxppc-dev@lists•ozlabs.org
Subject: Re: MPC5200B, many FEC_IEVENT_RFIFO_ERRORs until link down
Date: Tue, 30 Mar 2010 12:46:12 +0200	[thread overview]
Message-ID: <4BB1D674.2050800@grandegger.com> (raw)
In-Reply-To: <201003301200.54609.roman.fietze@telemotive.de>

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.

  reply	other threads:[~2010-03-30 10:47 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-30 10:00 MPC5200B, many FEC_IEVENT_RFIFO_ERRORs until link down Roman Fietze
2010-03-30 10:46 ` Wolfgang Grandegger [this message]
2010-03-31 10:15   ` Wolfgang Grandegger
2010-04-01 10:04     ` Roman Fietze
2010-04-05 12:21       ` Wolfgang Grandegger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4BB1D674.2050800@grandegger.com \
    --to=wg@grandegger$(echo .)com \
    --cc=linuxppc-dev@lists$(echo .)ozlabs.org \
    --cc=roman.fietze@telemotive$(echo .)de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox