netdev - Re: Question on behavior of tg3_self_test() (ethtool -t on tg3 driver)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 11 Aug 2015 13:31:13 -0700
From:	Michael Chan <mchan@...adcom.com>
To:	Douglas Miller <dougmill@...ux.vnet.ibm.com>
CC:	<netdev@...r.kernel.org>,
	Prashant Sreedharan <prashant@...adcom.com>,
	<siva.kallam@...adcom.com>
Subject: Re: Question on behavior of tg3_self_test() (ethtool -t on tg3
 driver)

On Tue, 2015-08-11 at 14:24 -0500, Douglas Miller wrote: 
> Yes, the "wrap plugs" are the loopback cables/plugs. It is my 
> understanding that the "offline" tests do not require anything to be 
> plugged into the ports, as they do not in any way touch the "external" 
> port. They perform an "internal loopback" test which does not depend on 
> any external connection.

Correct.

> 
>  From what I can tell, the only difference between "offline" and 
> "external_lb" is that "external_lb" performs the external loopback 
> tests, *in addition to* all the tests done for "offline".

Correct.

> This would 
> imply that the only tests that depend on anything connected to the 
> physical port is "external_lb", and there is no requirement that the 
> wrap plugs be removed/replaced in order to run "offline" tests.

When you do external loopback test, we skip the link test because you no
longer have normal connection to the network.  You now use a special
loopback cable, which will fail the link up test because the link up
test assumes connection to the network using normal cable.

> 
> In the case I was debugging, wrap plugs were installed because the ports 
> were, later, being tested in an "external loopback" way.
> 
> What I am observing is that it takes about 20 seconds for the kernel to 
> declare that the link is up, after running the "offline" or 
> "external_lb" test. In the case of "offline" I cannot run the test again 
> until the kernel declares the link up. In the case of "external_lb" I 
> can run the test again immediately and it passes.

As stated earlier, because we skip the link test when we are performing
external_lb.

So, you should always do ethtool -t <dev> external_lb if you have a
loopback cable connected.  We will perform the external loopback test
and skip the link test.

If you don't have an external loopback cable connected, you should run
ethtool -t <dev> offline.  It will not do the external loopback test and
will do the link test for proper link up with the network.

> This suggests to me 
> that the "external_lb" case (again, it is a superset of "offline") is 
> performing some configuration on the port that allows the subsequent 
> test to work. The one significant difference between "offline" and 
> "external_lb" is that "external_lb" performs the
> "tg3_phy_lpbk_set(tp, 0, true);" changes to configuration (immediately 
> prior to running the loopback tests again). I believe this call is to 
> switch from "internal loopback" to "normal", in order to leverage the 
> wrap plugs and perform the external loopback tests. But this call is not 
> made for "offline" and I am wondering if that leaves the port in a state 
> where it cannot be used until the kernel completes the "link up".
> 
> 

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html