netdev - question about niu linux driver behaviour

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>] [day] [month] [year] [list]

Message-ID: <4AB154DC.7070305@nortel.com>
Date:	Wed, 16 Sep 2009 15:13:00 -0600
From:	"Chris Friesen" <cfriesen@...tel.com>
To:	netdev@...r.kernel.org, "David S. Miller" <davem@...emloft.net>,
	Santwona.Behera@....com, Matheos Worku <Matheos.Worku@....COM>
Subject: question about niu linux driver behaviour

Hi all,

I've got a Sun 3320 ATCA "alonso" board with Neptune network devices.
I'm running basically 2.6.27.8, and I'm seeing some odd behaviour in the
niu driver.

My understanding is that there are four ports. 0 and 1 are XMAC links,
while 10, and 11 are BMAC links.  On our board these normally map to
eth4/5/6/7.

At boot time, if the other end for the XMAC links is not up, then we see
messages that look like:

niu 0000:08:00.0: niu: Port 0 signal bits [00000000] are not [30000000]
niu 0000:08:00.0: niu: Port 0 10G/1G SERDES Link Failed
niu 0000:08:00.1: niu: Port 1 signal bits [00000000] are not [0c000000]
niu 0000:08:00.1: niu: Port 1 10G/1G SERDES Link Failed

and the BMAC links come up as eth4/eth5.

This seems to be due to the fact that we're checking ESR_INT_SIGNALS for
ESR_INT_DET0_P0 and ESR_INT_DET0_P1, and then failing because they're
not set.  (The 10G initialization behaves similarly.)

Is this valid behaviour?  I seems fragile for successful serdes
initialization to depend on the other end of the link being up at driver
init time.

Chris
--
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