All of lore.kernel.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.com \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=roman.fietze@telemotive.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.