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]
Message-ID: <1282147735.3880.83.camel@localhost>
Date:	Wed, 18 Aug 2010 09:08:55 -0700
From:	"Benjamin Li" <benli@...adcom.com>
To:	"Joe Jin" <joe.jin@...cle.com>
cc:	"Michael Chan" <mchan@...adcom.com>,
	"terry.liu@...cle.com" <terry.liu@...cle.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: Broadcom 5709 take long time to bring up

Hi Joe,

Just a couple of quick questions:

1.  It is possible that autonegotiation could take in the orders of
seconds depending on the remote partner.   Could you describe the remote
partner?

2.  Are there iSCSI offload connections?  With iSCSI there is
additionial overhead to cleanup/setup iSCSI connections on the
chip/firmware when ifup'ing/ifdown'ing a network interface.

3.  Could you provide the kernel logs during this up/down test?  I
wanted to see if there was anything interesting in the kernel logs.

Thanks again.

-Ben


On Wed, 2010-08-18 at 07:34 -0700, Joe Jin wrote:
> Hi Michael,
> 
> We try boning two broadcom 5709 nics with active-backup mode, we try to
> down/up one of the nics, I found some ping packets loss as below:
> # ifdown eth0 
> # ifup eth0  <-- no pkg loss 
> # ifdown eth1 
> # ifup eth1  <-- 2 pkg loss 
> # ifdown eth0 
> # ifup eth0  <-- 10 pkg loss 
> # ifdown eth1 
> # ifup eth1 <-- no pkg loss 
> # ifdown eth0 
> # ifup eth0  <-- 10 pkg loss 
> 
> module bond parameter are:
> "mode=1 miimon=100 primary=eth0 downdelay=100 updelay=100"
> 
> we have tried the latest driver(2.0.8c) of broadcom and Redhat el5.5
> official driver(2.0.2), result are same.
> 
> I checked and debugged the driver found it caused by take long time(~3s)
> to bring up the device. here are link state when call if up:
> # ifdown eth0 
> # ifup eth0   
> #ip -o link | grep eth0 
> 2: eth0: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master bond0 qlen 1000\    link/ether 00:26:55:4f:1f:18 brd ff:ff:ff:ff:ff:ff 
> # ifdown eth1 
> # ifup eth1   
> #ip -o link | grep eth1 
> 3: eth1: <NO-CARRIER,BROADCAST,MULTICAST,SLAVE,UP> mtu 1500 qdisc pfifo_fast master bond0 qlen 1000\    link/ether 00:26:55:4f:1f:18 brd ff:ff:ff:ff:ff:ff 
> # ifdown eth0 
> # ifup eth0   
> #ip -o link | grep eth0 
> 2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,SLAVE,UP> mtu 1500 qdisc pfifo_fast master bond0 qlen 1000\    link/ether 00:26:55:4f:1f:18 brd ff:ff:ff:ff:ff:ff 
> # ifdown eth1 
> # ifup eth1   
> #ip -o link | grep eth1 
> 3: eth1: <NO-CARRIER,BROADCAST,MULTICAST,SLAVE,UP> mtu 1500 qdisc pfifo_fast master bond0 qlen 1000\    link/ether 00:26:55:4f:1f:18 brd ff:ff:ff:ff:ff:ff 
> # ifdown eth0 
> # ifup eth0 
> #ip -o link | grep eth0 
> 2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,SLAVE,UP> mtu 1500 qdisc pfifo_fast master bond0 qlen 1000\    link/ether 00:26:55:4f:1f:18 brd ff:ff:ff:ff:ff:ff 
> 
> So, the question is how long alway will take when bring up the interface?
> 3 seconds as expection or no? if not, is that a firmware issure or driver
> issue?
> 
> Thanks,
> Joe
> 
> 
> 
> --
> 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
> 


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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ