ethtool -t option is failing for shiner-t in Ubuntu 14.04

Bug #1500717 reported by bugproxy
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Invalid
Undecided
Unassigned

Bug Description

== Comment: #0 - Rajeshkumar S <email address hidden> - 2015-01-27 05:21:43 ==
---Problem Description---
ethtool -t option is failing for shiner-t interface

---uname output---
3.16.0-29-generic #39-Ubuntu SMP Tue Dec 16 20:53:59 UTC 2014 ppc64le ppc64le ppc64le GNU/Linux

Machine Type = 8286-42A /10D6B9T

---Steps to Reproduce---

Configure the interfaces of the of shiner-t adapter.

Invoke ethtool with -t option for the shiner-t interface ( eth22 and eth20 in this test system [9.3.189.142])

It fails on the below test as

root@powerio-le21:~# ethtool -t eth22
The test result is FAIL
The test extra info:
register_test (offline) 0
memory_test (offline) 0
int_loopback_test (offline) 0
ext_loopback_test (offline) 0
nvram_test (online) 1
interrupt_test (online) 0
link_test (online) 0

the dmesg output during the event is

[348306.120281] bnx2x 0003:0a:00.0 eth22: using MSI-X IRQs: sp 441 fp[0] 461 ... fp[7] 472
[348306.222325] bnx2x 0003:0a:00.0 eth22: NIC Link is Up, 10000 Mbps full duplex, Flow control: none
[348307.088285] bnx2x 0003:0a:00.0 eth22: using MSI-X IRQs: sp 441 fp[0] 461 ... fp[7] 472
[348313.363674] bnx2x 0003:0a:00.0 eth22: NIC Link is Up, 10000 Mbps full duplex, Flow control: ON - receive & transmit
root@powerio-le21:~#

Userspace tool common name: ethtool

The userspace tool has the following bit modes: 64 bit

Userspace rpm: -

Userspace tool obtained from project website: na

*Additional Instructions for <email address hidden>:
-Post a private note with access information to the machine that the bug is occuring on.
-Attach ltrace and strace of userspace application.

== Comment: #4 - Rajeshkumar S <email address hidden> - 2015-04-08 04:36:56 ==
Brian,

I have a system that is available right now exhibiting this failure for Mason adapter from Qlogic

eth1 and eth2 are the interfaces corresponding to the ports of the Qlogic's Mason adapter.

The issue is reproducible now also

wii01:~ # ethtool -t eth1
The test result is FAIL
The test extra info:
Loopback test (offline) -5

wii01:~ # echo $?
2
wii01:~ # ethtool -t eth2
The test result is FAIL
The test extra info:
Loopback test (offline) -5

== Comment: #15 - Guilherme Guaglianoni Piccoli <email address hidden> - 2015-09-28 10:00:18 ==
(In reply to comment #14)
> Mirror on Launchpad

The mirror is requested because there's a need to involve QLogic - since they have no access to LTC bugzilla, we NEED to mirror this bug to Launchpad so we can discuss there.

Revision history for this message
bugproxy (bugproxy) wrote : lspci from adapter

Default Comment by Bridge

tags: added: architecture-ppc64le bugnameltc-120976 severity-medium targetmilestone-inin---
Revision history for this message
Ubuntu Foundations Team Bug Bot (crichton) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. It seems that your bug report is not filed about a specific source package though, rather it is just filed against Ubuntu in general. It is important that bug reports be filed about source packages so that people interested in the package can find the bugs about it. You can find some hints about determining what package your bug might be about at https://wiki.ubuntu.com/Bugs/FindRightPackage. You might also ask for help in the #ubuntu-bugs irc channel on Freenode.

To change the source package that this bug is filed about visit https://bugs.launchpad.net/ubuntu/+bug/1500717/+editstatus and add the package name in the text box next to the word Package.

[This is an automated message. I apologize if it reached you inappropriately; please just reply to this message indicating so.]

tags: added: bot-comment
Revision history for this message
bugproxy (bugproxy) wrote : Comment bridged from LTC Bugzilla

------- Comment From <email address hidden> 2015-09-29 14:09 EDT-------
This bug is happening sometimes on Shiner-T adapter. Not all adapters shows the behavior, only some of them. We have one adapter showing this right now.

When "ethtool -t" is used, as reported above, the test fails on NVRAM sub-test. The interesting part is that a workaround was found: if the problem is happening and a microcode/firmware update is performed (using specific tool to "burn" the image on the adapter), the problem disappear.

No matter which version of microcode image is used, the "process" of updating the microcode seems to solve the problem somewhat.

Since we have no access to the source-code of update tool or the source of microcode itself, I want to involve QLogic so we can work together to solve the issue.

Revision history for this message
bugproxy (bugproxy) wrote : Data: lspci, dumped_NVRAM, ethtool of problematic adapter

------- Comment (attachment only) From <email address hidden> 2015-09-29 14:41 EDT-------

affects: ubuntu → ethtool (Ubuntu)
Revision history for this message
Ben Hutchings (benh-debian) wrote :

Self-tests are implemented in the driver, not in ethtool. Assuming that this is an in-tree driver, I'm reassigning to linux. If the driver is out-of-tree then I don't think it's an Ubuntu issue at all.

affects: ethtool (Ubuntu) → linux (Ubuntu)
Revision history for this message
nasir moinuddin (nasir-moinuddin) wrote :

We did try to duplicate the issue that you reported several times in our lab but were unable to see the symptoms you reported. It seems like the issue you are having is very sporadic in nature. We have had no issues reported from the field or from IBM either on this very specific command. Could you please tell me what tool are you exactly referring to when you say you are able to "burn" the image on the adapter.

I would recommend you use the firmware update tool provided by IBM and I would also advise you to do that with the latest firmware provided by IBM. Please try that and let me know the outcome.

Revision history for this message
bugproxy (bugproxy) wrote : Comment bridged from LTC Bugzilla

------- Comment From <email address hidden> 2016-01-04 19:42 EDT-------
After talking to Nasir via email, we tried to reproduce this issue in many adapters, without success. It's pretty probable that this issue happened only in some few problematic adapters, and since we did a firmware update on those, we can't reproduce again - the fw update process solves the issue, no matter which fw level is used.

So, will close as non-reproducible. If ever reproduced, I can re-open or talk to QLogic to advise.

Thanks,

Guilherme

Revision history for this message
Tim Gardner (timg-tpi) wrote :

Marking Invalid according to comment #7

Changed in linux (Ubuntu):
status: New → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.