From: Russell King - ARM Linux <linux@arm.linux.org.uk>
To: Mattis Lorentzon <Mattis.Lorentzon@autoliv.com>
Cc: Fredrik Noring <fredrik.noring@autoliv.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: Oops: 17 SMP ARM (v3.16-rc2)
Date: Wed, 6 Aug 2014 13:55:50 +0100 [thread overview]
Message-ID: <20140806125550.GO30282@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <C4A61A5CA4AD2246942F4BA6F20ACB8043575172@ALVA-EXMB04.alv.autoliv.int>
On Wed, Aug 06, 2014 at 11:10:06AM +0000, Mattis Lorentzon wrote:
> Russell,
>
> > What is on the other end of the link?
>
> 16 ARM cards connected to a 3Com Switch 4400 connected to a Linux FC 20
> machine (Intel Corporation 82541PI Gigabit Ethernet Controller rev 05).
>
> There may be multiple problems. The backtrace has only been seen a few
> times, on two different cards. Most of the time, the network for a random
> card just stalls without any visible backtrace or error messages. The other
> cards seem to be unaffected when this happens.
Can you ascertain whether these stalls are a result of some failure of the
receive side or the transmit side - you should be able to tell that if you
watch the packet counts via ifconfig on the stalled card. Also, it would
be useful to know whether the FEC interrupt was firing.
I hope you have some kind of serial console on these cards?
> > What I would like to do is to stamp each packet in some way with an
> > identifier marking its ring position, and then monitor the network to find out
> > whether the packet at slot 85 was actually transmitted - that's made slightly
> > harder because packets may be dropped at the receiver when operating in
> > promisc mode. This would then allow us to work out some likely causes.
>
> We would be glad to run this test on our setup, do you have more detailed
> information on how to set it up?
One of the problems is to find some way to stamp each packet with a 10-bit
number without having any side effects. I guess one possibility would be
to overwrite the source MAC address on transmit, which hopefully should not
cause any side effects.
> After a network stall, we usually have to powercycle the ARM hardware to
> get it back to a usable state. These stalls last at least several minutes,
> perhaps indefinitely. It does not seem to recover properly, and is no longer
> reachable via the network.
Hmm. Okay, I think the first thing we need to do is to work out why
the silent stalls are happening.
--
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.
next prev parent reply other threads:[~2014-08-06 12:56 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-25 13:55 Mattis Lorentzon
2014-06-26 14:01 ` Russell King - ARM Linux
2014-06-26 14:44 ` Mattis Lorentzon
2014-06-26 15:14 ` Russell King - ARM Linux
2014-06-27 11:21 ` Russell King - ARM Linux
2014-06-27 16:16 ` Fredrik Noring
2014-06-27 16:31 ` Russell King - ARM Linux
2014-06-30 6:22 ` Fredrik Noring
2014-06-30 12:30 ` Fredrik Noring
2014-06-30 13:00 ` Nathan Lynch
2014-07-02 6:02 ` Fredrik Noring
2014-08-05 13:31 ` Mattis Lorentzon
2014-08-05 13:53 ` Fabio Estevam
2014-08-06 6:48 ` Mattis Lorentzon
2014-08-06 9:50 ` Russell King - ARM Linux
2014-08-06 11:10 ` Mattis Lorentzon
2014-08-06 12:55 ` Russell King - ARM Linux [this message]
2014-08-07 11:11 ` Mattis Lorentzon
2014-08-07 12:12 ` Russell King - ARM Linux
2014-08-07 14:20 ` Fabio Estevam
2014-08-07 14:38 ` Fabio Estevam
2014-08-08 1:30 ` Troy Kisky
2014-08-08 14:05 ` Fabio Estevam
2014-08-08 18:09 ` Russell King - ARM Linux
2014-08-11 13:32 ` Mattis Lorentzon
2014-08-11 17:41 ` Fabio Estevam
2014-08-13 13:39 ` Mattis Lorentzon
2014-08-25 10:18 ` Russell King - ARM Linux
2014-08-26 13:11 ` Iain Paton
2014-08-14 14:43 ` Mattis Lorentzon
2014-08-14 15:30 ` Fabio Estevam
2014-08-15 5:42 ` Mattis Lorentzon
2014-08-17 21:34 ` Iain Paton
2014-08-17 21:46 ` Fabio Estevam
2014-08-19 6:03 ` Iain Paton
2014-08-21 9:39 ` Iain Paton
2014-08-22 0:01 ` Fabio Estevam
2014-08-22 6:39 ` Mattis Lorentzon
2014-08-22 10:36 ` Iain Paton
2014-08-27 6:32 ` Mattis Lorentzon
2014-08-27 10:43 ` Iain Paton
2014-08-29 10:57 ` Mattis Lorentzon
2014-08-29 11:30 ` Fabio Estevam
2014-12-16 14:50 ` Mattis Lorentzon
2014-08-26 13:12 ` Iain Paton
2014-08-22 8:27 ` Russell King - ARM Linux
2014-06-26 13:16 Mattis Lorentzon
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=20140806125550.GO30282@n2100.arm.linux.org.uk \
--to=linux@arm.linux.org.uk \
--cc=Mattis.Lorentzon@autoliv.com \
--cc=fredrik.noring@autoliv.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.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
all inboxes | Powered by JetHome®