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: Wed, 31 Mar 2010 12:15:47 +0200	[thread overview]
Message-ID: <4BB320D3.9090308@grandegger.com> (raw)
In-Reply-To: <4BB1D674.2050800@grandegger.com>

Hi Roman,

Wolfgang Grandegger wrote:
> 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.

I just sent out the patch. Would be nice if you, or somebody else, could
do some testing and provide some feedback. FYI, I will be out of office
next week.

Thanks,

Wolfgang.

next prev parent reply	other threads:[~2010-03-31 10:17 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
2010-03-31 10:15   ` Wolfgang Grandegger [this message]
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=4BB320D3.9090308@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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox