linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: rje@valleytech.com
To: linuxppc-embedded@ozlabs.org.
Subject: Re: mpc8349, gb ethernet, bridging
Date: Mon, 21 Apr 2008 11:10:28 -0400	[thread overview]
Message-ID: <480CAE64.3060405@valleytech.com> (raw)
In-Reply-To: <480AD64E.1040406@valleytech.com>

Hi.
Anybody have any idea what could cause the NETDEV WATCHDOG timeout?
On the GB ethernet port?

Could that happen if the other port was being overflowed?

That watchdog timeout seems to be involved pretty much every time
that the bridge goes down.  When the timeout occurs, the gianfar driver 
stops
and then (re)starts itself.



>
> Hi.
>
> We are having some issues regarding bridging the 2 ethernet ports of 
> an mpc8349, and are
> trying to determine what is going on.
>
>
> We are attempting to daisy-chain several mpc8349-based boards via the 
> 2 ethernet ports
> on each 8349.  When we enable bridging for the units, we (sometimes) 
> start seeing the following
> on one of the interior bridge's (mostly on the root bridge) console(s):
>
> NETDEV WATCHDOG: eth1 : transmit timed out
>
> We then see the bridge output  messages that indicate that is is going 
> through a topology
> state change.
>
> This situation keeps recurring.
>
> At some point, the message from the bridge that it is entering a 
> disabled state for port #2
> (eth1) is followed by garbage (actually, it appears to be some 
> pointers and/or memory
> addresses printed out), and the system hangs.
>
> We are using NAPI and the skbuff-recycling for the gianfar driver.
> We use ring(s) of 32 buffers.
> The gianfar's watchdog is set to  1Hz (once a seond ?)
>
> We are not sure if/how affect things:
>
> Port #1 of the 'root' bridge  is attached directly to our LAN
> Port #1 of the 'root' bridge runs at 10 Mbs
> Port #2 of the 'root' bridge runs at 1Gbs
> All other ports in the chain are       1Gbs
> We are using CAT-5 cables for all connections
>
> We have an application on each bridge in the chain that periodically 
> sends several hundred bytes
> 'up the chain', towards its head (ie, towards our LAN).   This 
> application is typically running
> when the issue is seen.
>
> Setting the bridge's forwarding delay to 0 and hellotime to 6,000 
> helped, but did
> not solve the issue.
>
> ???
>

-- 

Sometimes I feel like a red shirt in the Star Trek episode of life.

--

This message contains confidential information and is intended only for the
individual named.  If you are not the intended recipient you should not
disseminate, distribute or copy this e-mail.  Please notify the sender
immediately by e-mail if you have received this e-mail by mistake and delete
this e-mail from your system.

  reply	other threads:[~2008-04-21 15:16 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-20  5:36 mpc8349, gb ethernet, bridging R. Ebersole (VTI - new)
2008-04-21 15:10 ` rje [this message]
2008-04-25 13:22   ` rje

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=480CAE64.3060405@valleytech.com \
    --to=rje@valleytech.com \
    --cc=linuxppc-embedded@ozlabs.org. \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).