From: Douglas Miller <dougmill@linux.vnet.ibm.com>
To: netdev@vger.kernel.org
Cc: Michael Chan <mchan@broadcom.com>,
Prashant Sreedharan <prashant@broadcom.com>
Subject: Question on behavior of tg3_self_test() (ethtool -t on tg3 driver)
Date: Tue, 11 Aug 2015 10:59:45 -0500 [thread overview]
Message-ID: <55CA1BF1.2060403@linux.vnet.ibm.com> (raw)
(Sorry if you got several duplicates, am trying to work through rejected
messages due to supposed HTML content)
The following behavior is being observed when running "ethtool -t <dev>
offline" on ports on the Broadcom BCM5719 adapter (tg3 driver). The
ports have wrap plugs on them, although I'm not sure why that would have
any affect.
The test "ethtool -t <dev> offline" was being running continuously. The
first invocation passes, all subsequent ones fail (at least in the "link
test" step) after ~20 second timeout. When running the test once, I see
the following: Looking at /var/log/messages, I see a "Link is down"
message during the test. Then, 20 seconds after the test completes,
there is a "Link is up..." message. If I wait for the "Link is up..."
message I can run the test without problems. If the test is run again
while the link is still down, it fails and seems to delay the "link up"
by an additional 20 seconds.
If I run "external_lb" instead of "offline", I am able to run the test
repeatedly without error. So it seems that some action taken in the
"external_lb" case actually "repairs" the port. But the "external_lb"
test also exhibits the link-down for 20 seconds symptom, although it can
been run while the link is considered "down" without failure.
The first question is whether we should expect to be able to run
"ethtool -t <dev> offline" continually, with no delay between runs. I
presume this is supported.
Second question, I would like someone with experience with the tg3
driver and this adapter to comment on what might be done to fix this. My
first, simple, guess would be move the "tg3_phy_lpbk_set(tp, 0, true);"
setting (in tg3_test_loopback()) to be done for both "offline" and
"external_lb" cases. I am awaiting time on a system with this adapter in
order to try out some possible fixes and/or debug what might be
wrong/different with the configuration after the "offline" test.
I would appreciate any help,
Thanks,
Doug Miller
next reply other threads:[~2015-08-11 15:59 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-11 15:59 Douglas Miller [this message]
2015-08-11 17:41 ` Question on behavior of tg3_self_test() (ethtool -t on tg3 driver) Michael Chan
2015-08-11 19:24 ` Douglas Miller
2015-08-11 20:31 ` Michael Chan
2015-08-12 12:32 ` Douglas Miller
2015-08-13 8:40 ` Siva Reddy (Siva) Kallam
2015-08-13 12:59 ` Douglas Miller
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=55CA1BF1.2060403@linux.vnet.ibm.com \
--to=dougmill@linux.vnet.ibm.com \
--cc=mchan@broadcom.com \
--cc=netdev@vger.kernel.org \
--cc=prashant@broadcom.com \
/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).