How can I remove one interface from lagg, without destroying all lagg?
Hi. I have lagg interface created on my server: [root@h-qa-094 ~]$ ifconfig lagg0 lagg0: flags=8802BROADCAST,SIMPLEX,MULTICAST metric 0 mtu 1500 options=401bbRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,VLAN_HWTSO ether 00:02:c9:19:82:80 nd6 options=21PERFORMNUD,AUTO_LINKLOCAL media: Ethernet autoselect status: active laggproto failover lagghash l2,l3,l4 laggport: igb1 flags=0 laggport: mlxen1 flags=0 laggport: mlxen0 flags=5MASTER,ACTIVE Now, I want to removr igb1 interface from that lag. How can I do it? Regards, Alex Liptsin Software Quality Assurance Engineer | Mellanox Technologies Ltd. Office: +972 (74) 7236141 Mobile: +972(54) 7833986 Fax: +972(74) 7236161 Email: al...@mellanox.commailto:al...@mellanox.com Mellanox, Tel-Hai Industrial Park. Building 7, M.P. Upper Galilee 12100 Israel ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: How can I remove one interface from lagg, without destroying all lagg?
Use -laggport portN -- Jason Hellenthal Inbox: jhellent...@dataix.net Voice: +1 (616) 953-0176 JJH48-ARIN On Jul 24, 2013, at 5:14, Alex Liptsin al...@mellanox.com wrote: Hi. I have lagg interface created on my server: [root@h-qa-094 ~]$ ifconfig lagg0 lagg0: flags=8802BROADCAST,SIMPLEX,MULTICAST metric 0 mtu 1500 options=401bbRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,VLAN_HWTSO ether 00:02:c9:19:82:80 nd6 options=21PERFORMNUD,AUTO_LINKLOCAL media: Ethernet autoselect status: active laggproto failover lagghash l2,l3,l4 laggport: igb1 flags=0 laggport: mlxen1 flags=0 laggport: mlxen0 flags=5MASTER,ACTIVE Now, I want to removr igb1 interface from that lag. How can I do it? Regards, Alex Liptsin Software Quality Assurance Engineer | Mellanox Technologies Ltd. Office: +972 (74) 7236141 Mobile: +972(54) 7833986 Fax: +972(74) 7236161 Email: al...@mellanox.commailto:al...@mellanox.com Mellanox, Tel-Hai Industrial Park. Building 7, M.P. Upper Galilee 12100 Israel ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org smime.p7s Description: S/MIME cryptographic signature
RE: kern/180430: [ofed] [patch] Bad UDP checksum calc for fragmented packets
The following reply was made to PR kern/180430; it has been noted by GNATS.
From: Meny Yossefi me...@mellanox.com
To: John Baldwin j...@freebsd.org
Cc: bug-follo...@freebsd.org bug-follo...@freebsd.org
Subject: RE: kern/180430: [ofed] [patch] Bad UDP checksum calc for
fragmented packets
Date: Wed, 24 Jul 2013 13:14:53 +
--_000_F2E47A38E4D0B9499D76F2AB8901571A73A0EC13MTLDAG01mtlcom_
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Hi John,
Looks good.
-Meny
From: Meny Yossefi
Sent: Tuesday, July 23, 2013 5:01 PM
To: 'John Baldwin'
Cc: 'bug-follo...@freebsd.org'
Subject: RE: kern/180430: [ofed] [patch] Bad UDP checksum calc for fragment=
ed packets
Let's stick with the FreeBSD standards (without the likely/unlikely)
Let me just double check the CSUM flags work as expected.
I'll get back to you as soon as I'm done.
-Meny
-Original Message-
From: John Baldwin [mailto:j...@freebsd.org]
Sent: Monday, July 22, 2013 7:04 PM
To: Meny Yossefi
Cc: bug-follo...@freebsd.orgmailto:bug-follo...@freebsd.org
Subject: Re: kern/180430: [ofed] [patch] Bad UDP checksum calc for fragment=
ed packets
On Monday, July 22, 2013 10:11:51 am Meny Yossefi wrote:
Hi John,
The problem is that the HW will only calculate csum for parts of the
payload, one fragment at a time,
while the receiver side, in our case the tcp/ip stack, will expect to val=
idate the packet's payload as a whole.
Ok.
I agree with the change you offered, though one thing bothers me.
This change will add two conditions to the send flow which will probably =
have an effect on performance.
Maybe 'likely' can be useful here ?
FreeBSD tends to not use likely/unlikely unless there is a demonstrable gai=
n via benchmark measurements. However, if the OFED code regularly uses it =
and you feel this is a case where you would normally use it, it can be adde=
d.
BTW, I'm not entirely sure, but I think the CSUM_IP flag is always set, s=
o maybe the first condition is not necessary.
What do you think ?
If the user uses ifconfig to disable checksum offload and force software ch=
ecksums the flag will not be set.
-Meny
-Original Message-
From: John Baldwin [mailto:j...@freebsd.org]
Sent: Friday, July 19, 2013 6:29 PM
To: bug-follo...@freebsd.orgmailto:bug-follo...@freebsd.org; Meny Yosse=
fi
Subject: Re: kern/180430: [ofed] [patch] Bad UDP checksum calc for
fragmented packets
Oops, my previous reply didn't make it to the PR itself.
Is the problem that the hardware checksum overwrites arbitrary data in th=
e packet (at the location where the UDP header would be)?
Also, I've looked at other drivers, and they all look at the CSUM_*
flags to determine the right settings. IP fragments will not have
CSUM_UDP or
CSUM_TCP set, so I think the more correct fix is this:
Index: en_tx.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- en_tx.c (revision 253470)
+++ en_tx.c(working copy)
@@ -780,8 +780,12 @@ retry:
tx_desc-ctrl.srcrb_flags =3D
cpu_to_be32(MLX4_WQE_CTRL_CQ_UPDATE |
MLX4_WQE_CTRL_SOLICITED);
if (mb-m_pkthdr.csum_flags
(CSUM_IP|CSUM_TCP|CSUM_UDP)) {
- tx_desc-ctrl.srcrb_flags |=3D cpu_to_be32=
(MLX4_WQE_CTRL_IP_CSUM |
-=
MLX4_WQE_CTRL_TCP_UDP_CSUM);
+ if (mb-m_pkthdr.csum_flags CSUM_IP)
+
+ tx_desc-ctrl.srcrb_flags |=3D
+
+ cpu_to_be32(MLX4_WQE_CTRL_IP_CSUM);
+ if (mb-m_pkthdr.csum_flags
+ (CSUM_TCP|CSUM_UDP))
+
+ tx_desc-ctrl.srcrb_flags |=3D
+
+ cpu_to_be32(MLX4_WQE_CTRL_TCP_UDP_CSUM);
priv-port_stats.tx_chksum_offload++;
}
--
John Baldwin
--
John Baldwin
--_000_F2E47A38E4D0B9499D76F2AB8901571A73A0EC13MTLDAG01mtlcom_
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
html xmlns:v=3Durn:schemas-microsoft-com:vml xmlns:o=3Durn:schemas-micr=
osoft-com:office:office xmlns:w=3Durn:schemas-microsoft-com:office:word =
xmlns:m=3Dhttp://schemas.microsoft.com/office/2004/12/omml; xmlns=3Dhttp:=
//www.w3.org/TR/REC-html40
head
meta http-equiv=3DContent-Type content=3Dtext/html; charset=3Dus-ascii=
meta name=3DGenerator content=3DMicrosoft
Recommendations for 10gbps NIC
Hi. I am looking for recommendations for a 10gbps NIC from someone who has successfully used it on FreeBSD. It will be used on FreeBSD 9.1-R/amd64 to capture packets. Some desired features are: - PCIe - LC connectors - 10GBASE-SR - Either single- or dual-port - Multiqueue Specific part numbers would be appreciated. Thank you. -Boris ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
bce(4) panics, 9.2rc1
Running 9.2 in production load mail servers. We're hitting the watchdog message and crashing with the stable/9 version. We're reverting the change from 2 weeks ago and seeing if it still happens. We didn't see this from stable/9 from about a month ago. Sean ref: http://svnweb.freebsd.org/base?view=revisionrevision=253128 bce0: ../../../dev/bce/if_bce.c(7871): Watchdog timeout occurred, resetting! Jul 24 20:22:15 syslog.err nm4 7 syslogd: sendtFatal trap 12: page fault while in kernel mode o: No route to hcpuid = 13; ost Jul 24 20:2apic id = 13 f2:15 kern.noticault vie nm47 kernel: rtual addressbce0: link state = 0x10 changed to DOWNfau Jul 24 20:22:1lt 5 syslog.err ncode = supervisor read m47 syslogd: sendadto: No route tota, page no host t present instruction pointer = 0x20:0x803a1931 stack pointer = 0x28:0xff8c5be0aab0 frame pointer = 0x28:0xff8c5be0ab60 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 12 (irq256: bce0) trap number = 12 panic: page fault cpuid = 13 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a/frame 0xff8c5be0a540 kdb_backtrace() at kdb_backtrace+0x37/frame 0xff8c5be0a600 panic() at panic+0x1d8/frame 0xff8c5be0a700 trap_fatal() at trap_fatal+0x290/frame 0xff8c5be0a760 trap_pfault() at trap_pfault+0x1d2/frame 0xff8c5be0a7f0 trap() at trap+0x43a/frame 0xff8c5be0a9f0 calltrap() at calltrap+0x8/frame 0xff8c5be0a9f0 --- trap 0xc, rip = 0x803a1931, rsp = 0xff8c5be0aab0, rbp = 0xff8c5be0ab60 --- bce_intr() at bce_intr+0x301/frame 0xff8c5be0ab60 intr_event_execute_handlers() at intr_event_execute_handlers+0x6a/frame 0xff8c5be0ab90 ithread_loop() at ithread_loop+0xac/frame 0xff8c5be0abe0 fork_exit() at fork_exit+0x135/frame 0xff8c5be0ac30 fork_trampoline() at fork_trampoline+0xe/frame 0xff8c5be0ac30 --- trap 0, rip = 0, rsp = 0xff8c5be0acf0, rbp = 0 --- Uptime: 38m18s Dumping 2120 out of 24538 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% Dump complete signature.asc Description: This is a digitally signed message part
Re: bce(4) panics, 9.2rc1
On Wed, 2013-07-24 at 14:07 -0700, Sean Bruno wrote: Running 9.2 in production load mail servers. We're hitting the watchdog message and crashing with the stable/9 version. We're reverting the change from 2 weeks ago and seeing if it still happens. We didn't see this from stable/9 from about a month ago. Sean ref: http://svnweb.freebsd.org/base?view=revisionrevision=253128 These panics are happening on: bce0: Broadcom NetXtreme II BCM5716 1000Base-T (C0) mem 0xda00-0xdbff irq 36 at device 0.0 on pci1 miibus0: MII bus on bce0 brgphy0: BCM5709 10/100/1000baseT PHY PHY 1 on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow bce0: Ethernet address: d4:ae:52:8d:42:fc bce0: ASIC (0x57092008); Rev (C0); Bus (PCIe x4, 2.5Gbps); B/C (5.2.3); Bufs (RX:2;TX:2;PG:8); Flags (SPLT|MSI|MFW); MFW (NCSI 2.0.11) Coal (RX:6,6,18,18; TX:20,20,80,80) bce1: Broadcom NetXtreme II BCM5716 1000Base-T (C0) mem 0xdc00-0xddff irq 48 at device 0.1 on pci1 miibus1: MII bus on bce1 brgphy1: BCM5709 10/100/1000baseT PHY PHY 1 on miibus1 brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow bce1: Ethernet address: d4:ae:52:8d:42:fd bce1: ASIC (0x57092008); Rev (C0); Bus (PCIe x4, 2.5Gbps); B/C (5.2.3); Bufs (RX:2;TX:2;PG:8); Flags (SPLT|MSI|MFW); MFW (NCSI 2.0.11) Coal (RX:6,6,18,18; TX:20,20,80,80) signature.asc Description: This is a digitally signed message part
Re: bce(4) panics, 9.2rc1
On Wed, Jul 24, 2013 at 2:23 PM, Sean Bruno sean_br...@yahoo.com wrote: On Wed, 2013-07-24 at 14:07 -0700, Sean Bruno wrote: Running 9.2 in production load mail servers. We're hitting the watchdog message and crashing with the stable/9 version. We're reverting the change from 2 weeks ago and seeing if it still happens. We didn't see this from stable/9 from about a month ago. pciconf -lvb: http://people.freebsd.org/~hiren/pciconf.txt Thanks, Hiren ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: kern/180791: [ofed] [patch] Kernel crash on ifdown and kldunload mlxen
Old Synopsis: Kernel crash on ifdown and kldunload mlxen New Synopsis: [ofed] [patch] Kernel crash on ifdown and kldunload mlxen Responsible-Changed-From-To: freebsd-amd64-freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Jul 24 21:48:47 UTC 2013 Responsible-Changed-Why: relcassify. http://www.freebsd.org/cgi/query-pr.cgi?pr=180791 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: bce(4) panics, 9.2rc1
- Original Message - From: Sean Bruno sean_br...@yahoo.com As a guess its likely the interrupt handler is triggering while the watchdog timeout handler is re-initialising the card so you inconsitent state resulting in the crash. In from /var/crash should help determine the cause and confirm / deny that. Regards Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.co.uk. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
