NetBSD Problem Report #58124
From www@netbsd.org Sun Apr 7 18:01:44 2024
Return-Path: <www@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))
(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
by mollari.NetBSD.org (Postfix) with ESMTPS id 7C1481A9239
for <gnats-bugs@gnats.NetBSD.org>; Sun, 7 Apr 2024 18:01:44 +0000 (UTC)
Message-Id: <20240407180143.2828B1A923B@mollari.NetBSD.org>
Date: Sun, 7 Apr 2024 18:01:43 +0000 (UTC)
From: vezhlys@gmail.com
Reply-To: vezhlys@gmail.com
To: gnats-bugs@NetBSD.org
Subject: lagg(4) fails to work with lacp protocol on mcx(4)
X-Send-Pr-Version: www-1.0
>Number: 58124
>Category: kern
>Synopsis: lagg(4) fails to work with lacp protocol on mcx(4)
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: yamaguchi
>State: closed
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Sun Apr 07 18:05:00 +0000 2024
>Closed-Date: Fri Apr 19 02:39:52 +0000 2024
>Last-Modified: Fri Apr 19 07:10:01 +0000 2024
>Originator: Andrius V
>Release: NetBSD 10
>Organization:
>Environment:
>Description:
Hi,
I am trying to configure lagg(4) interface using lacp (802.3ad) protocol between
my NAS server (amd64 machine) and Mikrotik CRS309-1G-8S+ router (RouterOS).
My network adapter is QNAP QXG-10G2SF-CX4 (Mellanox ConnectX-4 Lx mcx(4) SFP+ DAC).
Unfortunately I can't manage to make it work and communicate with my switch or
receive IP address from my router's DHCP server.
Switch should be configured correctly, I used it for Linux setup for years, also
deprecated agr(4) interface "sometimes" works with certain manual actions applied.
agr(4) is unstable though and looses connection soon or after reboot requiring
manual interaction again, thus also unusable in general. It has "LACP Partner System ID"
in the interface, but it stays empty for NetBSD (should be mac address of nas server).
I am using dhcpcd DHCP client.
Alternatively I tried loadbalance protocol, it works without issues in comparison.
Besides these I have 2x igc(4) interfaces, but I am not using them for link aggregation.
ifconfig.lagg0
create
laggproto lacp laggport mcx0 laggport mcx1
up
/etc/rc.conf
...
net_interfaces="igc1 lagg0"
dhcpcd=YES
dhcpcd_flags="-qLM lagg0 igc1"
...
ifconfig lagg0
lagg0: flags=0x8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
capabilities=0x3ff00<IP4CSUM_Rx,IP4CSUM_Tx,TCP4CSUM_Rx,TCP4CSUM_Tx>
capabilities=0x3ff00<UDP4CSUM_Rx,UDP4CSUM_Tx,TCP6CSUM_Rx,TCP6CSUM_Tx>
capabilities=0x3ff00<UDP6CSUM_Rx,UDP6CSUM_Tx>
enabled=0x3ff00<IP4CSUM_Rx,IP4CSUM_Tx,TCP4CSUM_Rx,TCP4CSUM_Tx>
enabled=0x3ff00<UDP4CSUM_Rx,UDP4CSUM_Tx,TCP6CSUM_Rx,TCP6CSUM_Tx>
enabled=0x3ff00<UDP6CSUM_Rx,UDP6CSUM_Tx>
ec_capabilities=0x7<VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU>
ec_enabled=0x2<VLAN_HWTAGGING>
laggproto lacp
laggport:
mcx0 pri=32768 flags=0
mcx1 pri=32768 flags=0
address: xx:xx:xx:xx:xx:xx
status: no carrier
mcx0: flags=0x8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
capabilities=0x3ff00<IP4CSUM_Rx,IP4CSUM_Tx,TCP4CSUM_Rx,TCP4CSUM_Tx>
capabilities=0x3ff00<UDP4CSUM_Rx,UDP4CSUM_Tx,TCP6CSUM_Rx,TCP6CSUM_Tx>
capabilities=0x3ff00<UDP6CSUM_Rx,UDP6CSUM_Tx>
enabled=0x3ff00<IP4CSUM_Rx,IP4CSUM_Tx,TCP4CSUM_Rx,TCP4CSUM_Tx>
enabled=0x3ff00<UDP4CSUM_Rx,UDP4CSUM_Tx,TCP6CSUM_Rx,TCP6CSUM_Tx>
enabled=0x3ff00<UDP6CSUM_Rx,UDP6CSUM_Tx>
ec_capabilities=0x7<VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU>
ec_enabled=0x2<VLAN_HWTAGGING>
address: xx:xx:xx:xx:xx:xx
media: Ethernet autoselect (10GBASE-CR1)
status: active
mcx1: flags=0x8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
capabilities=0x3ff00<IP4CSUM_Rx,IP4CSUM_Tx,TCP4CSUM_Rx,TCP4CSUM_Tx>
capabilities=0x3ff00<UDP4CSUM_Rx,UDP4CSUM_Tx,TCP6CSUM_Rx,TCP6CSUM_Tx>
capabilities=0x3ff00<UDP6CSUM_Rx,UDP6CSUM_Tx>
enabled=0x3ff00<IP4CSUM_Rx,IP4CSUM_Tx,TCP4CSUM_Rx,TCP4CSUM_Tx>
enabled=0x3ff00<UDP4CSUM_Rx,UDP4CSUM_Tx,TCP6CSUM_Rx,TCP6CSUM_Tx>
enabled=0x3ff00<UDP6CSUM_Rx,UDP6CSUM_Tx>
ec_capabilities=0x7<VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU>
ec_enabled=0x2<VLAN_HWTAGGING>
address: xx:xx:xx:xx:xx:xx
media: Ethernet autoselect (10GBASE-CR1)
status: active
link xx:xx:xx:xx:xx:xx
dmesg for mcx:
mcx0 at pci9 dev 0 function 0: Mellanox Technologies ConnectX-4 Lx (rev. 0x00)
mcx0: FW 14.22.1002
mcx0: Ethernet address xx:xx:xx:xx:xx:xx
mcx1 at pci9 dev 0 function 1: Mellanox Technologies ConnectX-4 Lx (rev. 0x00)
mcx1: FW 14.22.1002
mcx1: Ethernet address xx:xx:xx:xx:xx:xx
>How-To-Repeat:
ifconfig lagg0 create
ifconfig lagg0 laggproto lacp laggport mcx0 laggport mcx1
ifconfig lagg0 up
Start dhcpcd service or run dhcpcd lagg0 and observe that no IP is assigned, "status: no carrier" is displayed.
>Fix:
>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: kern-bug-people->yamaguchi
Responsible-Changed-By: riastradh@NetBSD.org
Responsible-Changed-When: Sun, 07 Apr 2024 22:50:17 +0000
Responsible-Changed-Why:
Can you take a look at this and suggest diagnostics?
From: s ymgch <s.ymgch228@gmail.com>
To: gnats-bugs@netbsd.org
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: kern/58124: lagg(4) fails to work with lacp protocol on mcx(4)
Date: Mon, 8 Apr 2024 10:24:55 +0900
Hi,
Could you check "ifconfig -m mcx0" and "ifconfig -m mcx1"?
LACP in lagg(4) needs "mediaopt full-duplex" to work, but mcx(4) may
be missing IFM_FDX.
On Mon, Apr 8, 2024 at 3:05=E2=80=AFAM <vezhlys@gmail.com> wrote:
>
> >Number: 58124
> >Category: kern
> >Synopsis: lagg(4) fails to work with lacp protocol on mcx(4)
> >Confidential: no
> >Severity: serious
> >Priority: medium
> >Responsible: kern-bug-people
> >State: open
> >Class: sw-bug
> >Submitter-Id: net
> >Arrival-Date: Sun Apr 07 18:05:00 +0000 2024
> >Originator: Andrius V
> >Release: NetBSD 10
> >Organization:
> >Environment:
> >Description:
> Hi,
>
> I am trying to configure lagg(4) interface using lacp (802.3ad) protocol =
between
> my NAS server (amd64 machine) and Mikrotik CRS309-1G-8S+ router (RouterOS=
).
> My network adapter is QNAP QXG-10G2SF-CX4 (Mellanox ConnectX-4 Lx mcx(4) =
SFP+ DAC).
> Unfortunately I can't manage to make it work and communicate with my swit=
ch or
> receive IP address from my router's DHCP server.
>
> Switch should be configured correctly, I used it for Linux setup for year=
s, also
> deprecated agr(4) interface "sometimes" works with certain manual actions=
applied.
> agr(4) is unstable though and looses connection soon or after reboot requ=
iring
> manual interaction again, thus also unusable in general. It has "LACP Par=
tner System ID"
> in the interface, but it stays empty for NetBSD (should be mac address of=
nas server).
>
> I am using dhcpcd DHCP client.
>
> Alternatively I tried loadbalance protocol, it works without issues in co=
mparison.
>
> Besides these I have 2x igc(4) interfaces, but I am not using them for li=
nk aggregation.
>
> ifconfig.lagg0
> create
> laggproto lacp laggport mcx0 laggport mcx1
> up
>
> /etc/rc.conf
> ...
> net_interfaces=3D"igc1 lagg0"
> dhcpcd=3DYES
> dhcpcd_flags=3D"-qLM lagg0 igc1"
> ...
>
> ifconfig lagg0
> lagg0: flags=3D0x8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
> capabilities=3D0x3ff00<IP4CSUM_Rx,IP4CSUM_Tx,TCP4CSUM_Rx,TCP4CSUM=
_Tx>
> capabilities=3D0x3ff00<UDP4CSUM_Rx,UDP4CSUM_Tx,TCP6CSUM_Rx,TCP6CS=
UM_Tx>
> capabilities=3D0x3ff00<UDP6CSUM_Rx,UDP6CSUM_Tx>
> enabled=3D0x3ff00<IP4CSUM_Rx,IP4CSUM_Tx,TCP4CSUM_Rx,TCP4CSUM_Tx>
> enabled=3D0x3ff00<UDP4CSUM_Rx,UDP4CSUM_Tx,TCP6CSUM_Rx,TCP6CSUM_Tx=
>
> enabled=3D0x3ff00<UDP6CSUM_Rx,UDP6CSUM_Tx>
> ec_capabilities=3D0x7<VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU>
> ec_enabled=3D0x2<VLAN_HWTAGGING>
> laggproto lacp
> laggport:
> mcx0 pri=3D32768 flags=3D0
> mcx1 pri=3D32768 flags=3D0
> address: xx:xx:xx:xx:xx:xx
> status: no carrier
>
> mcx0: flags=3D0x8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
> capabilities=3D0x3ff00<IP4CSUM_Rx,IP4CSUM_Tx,TCP4CSUM_Rx,TCP4CSUM=
_Tx>
> capabilities=3D0x3ff00<UDP4CSUM_Rx,UDP4CSUM_Tx,TCP6CSUM_Rx,TCP6CS=
UM_Tx>
> capabilities=3D0x3ff00<UDP6CSUM_Rx,UDP6CSUM_Tx>
> enabled=3D0x3ff00<IP4CSUM_Rx,IP4CSUM_Tx,TCP4CSUM_Rx,TCP4CSUM_Tx>
> enabled=3D0x3ff00<UDP4CSUM_Rx,UDP4CSUM_Tx,TCP6CSUM_Rx,TCP6CSUM_Tx=
>
> enabled=3D0x3ff00<UDP6CSUM_Rx,UDP6CSUM_Tx>
> ec_capabilities=3D0x7<VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU>
> ec_enabled=3D0x2<VLAN_HWTAGGING>
> address: xx:xx:xx:xx:xx:xx
> media: Ethernet autoselect (10GBASE-CR1)
> status: active
>
> mcx1: flags=3D0x8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
> capabilities=3D0x3ff00<IP4CSUM_Rx,IP4CSUM_Tx,TCP4CSUM_Rx,TCP4CSUM=
_Tx>
> capabilities=3D0x3ff00<UDP4CSUM_Rx,UDP4CSUM_Tx,TCP6CSUM_Rx,TCP6CS=
UM_Tx>
> capabilities=3D0x3ff00<UDP6CSUM_Rx,UDP6CSUM_Tx>
> enabled=3D0x3ff00<IP4CSUM_Rx,IP4CSUM_Tx,TCP4CSUM_Rx,TCP4CSUM_Tx>
> enabled=3D0x3ff00<UDP4CSUM_Rx,UDP4CSUM_Tx,TCP6CSUM_Rx,TCP6CSUM_Tx=
>
> enabled=3D0x3ff00<UDP6CSUM_Rx,UDP6CSUM_Tx>
> ec_capabilities=3D0x7<VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU>
> ec_enabled=3D0x2<VLAN_HWTAGGING>
> address: xx:xx:xx:xx:xx:xx
> media: Ethernet autoselect (10GBASE-CR1)
> status: active
> link xx:xx:xx:xx:xx:xx
>
> dmesg for mcx:
> mcx0 at pci9 dev 0 function 0: Mellanox Technologies ConnectX-4 Lx (rev. =
0x00)
> mcx0: FW 14.22.1002
> mcx0: Ethernet address xx:xx:xx:xx:xx:xx
> mcx1 at pci9 dev 0 function 1: Mellanox Technologies ConnectX-4 Lx (rev. =
0x00)
> mcx1: FW 14.22.1002
> mcx1: Ethernet address xx:xx:xx:xx:xx:xx
>
> >How-To-Repeat:
> ifconfig lagg0 create
> ifconfig lagg0 laggproto lacp laggport mcx0 laggport mcx1
> ifconfig lagg0 up
>
> Start dhcpcd service or run dhcpcd lagg0 and observe that no IP is assign=
ed, "status: no carrier" is displayed.
> >Fix:
>
From: Andrius V <vezhlys@gmail.com>
To: gnats-bugs@netbsd.org
Cc: yamaguchi@netbsd.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: kern/58124: lagg(4) fails to work with lacp protocol on mcx(4)
Date: Mon, 8 Apr 2024 09:23:12 +0300
On Mon, Apr 8, 2024 at 4:30=E2=80=AFAM s ymgch <s.ymgch228@gmail.com> wrote=
:
>
> The following reply was made to PR kern/58124; it has been noted by GNATS=
.
>
> From: s ymgch <s.ymgch228@gmail.com>
> To: gnats-bugs@netbsd.org
> Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org, netbsd-bugs@netbs=
d.org
> Subject: Re: kern/58124: lagg(4) fails to work with lacp protocol on mcx(=
4)
> Date: Mon, 8 Apr 2024 10:24:55 +0900
>
> Hi,
>
> Could you check "ifconfig -m mcx0" and "ifconfig -m mcx1"?
> LACP in lagg(4) needs "mediaopt full-duplex" to work, but mcx(4) may
> be missing IFM_FDX.
>
Hi,
supported media support is reported as:
media 1000BASE-SGMII
media 1000BASE-KX
media 10GBASE-KR
media 10GBASE-CR1
media 10GbaseSR
media 10GbaseLR
media 1000baseT
media autoselect
My assumption is 10GBASE-CR1 is full-duplex by default:
https://github.com/NetBSD/src/blob/2722c570299bae16210dbd4df9a7af6fd4759ba6=
/sys/net/if_media.h#L525.
From: s ymgch <s.ymgch228@gmail.com>
To: gnats-bugs@netbsd.org
Cc: yamaguchi@netbsd.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org,
vezhlys@gmail.com
Subject: Re: kern/58124: lagg(4) fails to work with lacp protocol on mcx(4)
Date: Mon, 8 Apr 2024 16:49:12 +0900
Hi,
On Mon, Apr 8, 2024 at 3:25=E2=80=AFPM Andrius V <vezhlys@gmail.com> wrote:
>
> The following reply was made to PR kern/58124; it has been noted by GNATS=
.
>
> From: Andrius V <vezhlys@gmail.com>
> To: gnats-bugs@netbsd.org
> Cc: yamaguchi@netbsd.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
> Subject: Re: kern/58124: lagg(4) fails to work with lacp protocol on mcx(=
4)
> Date: Mon, 8 Apr 2024 09:23:12 +0300
>
> On Mon, Apr 8, 2024 at 4:30=3DE2=3D80=3DAFAM s ymgch <s.ymgch228@gmail.c=
om> wrote=3D
> :
> >
> > The following reply was made to PR kern/58124; it has been noted by GN=
ATS=3D
> .
> >
> > From: s ymgch <s.ymgch228@gmail.com>
> > To: gnats-bugs@netbsd.org
> > Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org, netbsd-bugs@ne=
tbs=3D
> d.org
> > Subject: Re: kern/58124: lagg(4) fails to work with lacp protocol on m=
cx(=3D
> 4)
> > Date: Mon, 8 Apr 2024 10:24:55 +0900
> >
> > Hi,
> >
> > Could you check "ifconfig -m mcx0" and "ifconfig -m mcx1"?
> > LACP in lagg(4) needs "mediaopt full-duplex" to work, but mcx(4) may
> > be missing IFM_FDX.
> >
>
> Hi,
>
> supported media support is reported as:
> media 1000BASE-SGMII
> media 1000BASE-KX
> media 10GBASE-KR
> media 10GBASE-CR1
> media 10GbaseSR
> media 10GbaseLR
> media 1000baseT
> media autoselect
>
It seems that the media of mcx(4) does not set full-duplex.
Could you test the following patch?
----- patch -----
diff --git a/sys/dev/pci/if_mcx.c b/sys/dev/pci/if_mcx.c
index 274682e430af..8094e9b11320 100644
--- a/sys/dev/pci/if_mcx.c
+++ b/sys/dev/pci/if_mcx.c
@@ -8031,7 +8031,7 @@ mcx_media_add_types(struct mcx_softc *sc)
if (cap->cap_media =3D=3D 0)
continue;
- ifmedia_add(&sc->sc_media, IFM_ETHER | cap->cap_media, 0, N=
ULL);
+ ifmedia_add(&sc->sc_media, IFM_ETHER | IFM_FDX |
cap->cap_media, 0, NULL);
}
}
@@ -8072,8 +8072,8 @@ mcx_media_status(struct ifnet *ifp, struct
ifmediareq *ifmr)
ifmr->ifm_status =3D IFM_AVALID;
if (proto_oper !=3D 0) {
ifmr->ifm_status |=3D IFM_ACTIVE;
- ifmr->ifm_active =3D IFM_ETHER | IFM_AUTO | media_oper;
- /* txpause, rxpause, duplex? */
+ ifmr->ifm_active =3D IFM_ETHER | IFM_AUTO | IFM_FDX | media=
_oper;
+ /* txpause, rxpause? */
}
}
----- patch -----
-- Yamaguchi
From: Andrius V <vezhlys@gmail.com>
To: s ymgch <s.ymgch228@gmail.com>
Cc: gnats-bugs@netbsd.org, yamaguchi@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org
Subject: Re: kern/58124: lagg(4) fails to work with lacp protocol on mcx(4)
Date: Mon, 8 Apr 2024 22:18:50 +0300
On Mon, Apr 8, 2024 at 10:49=E2=80=AFAM s ymgch <s.ymgch228@gmail.com> wrot=
e:
>
> Hi,
>
>
> It seems that the media of mcx(4) does not set full-duplex.
> Could you test the following patch?
>
> ----- patch -----
> diff --git a/sys/dev/pci/if_mcx.c b/sys/dev/pci/if_mcx.c
> index 274682e430af..8094e9b11320 100644
> --- a/sys/dev/pci/if_mcx.c
> +++ b/sys/dev/pci/if_mcx.c
> @@ -8031,7 +8031,7 @@ mcx_media_add_types(struct mcx_softc *sc)
> if (cap->cap_media =3D=3D 0)
> continue;
>
> - ifmedia_add(&sc->sc_media, IFM_ETHER | cap->cap_media, 0,=
NULL);
> + ifmedia_add(&sc->sc_media, IFM_ETHER | IFM_FDX |
> cap->cap_media, 0, NULL);
> }
> }
>
> @@ -8072,8 +8072,8 @@ mcx_media_status(struct ifnet *ifp, struct
> ifmediareq *ifmr)
> ifmr->ifm_status =3D IFM_AVALID;
> if (proto_oper !=3D 0) {
> ifmr->ifm_status |=3D IFM_ACTIVE;
> - ifmr->ifm_active =3D IFM_ETHER | IFM_AUTO | media_oper;
> - /* txpause, rxpause, duplex? */
> + ifmr->ifm_active =3D IFM_ETHER | IFM_AUTO | IFM_FDX | med=
ia_oper;
> + /* txpause, rxpause? */
> }
> }
>
> ----- patch -----
>
> -- Yamaguchi
Hi,
You are completely right! Setting the patch helps and lacp protocol
starts to work. mcx0/mcx1 shows "media: Ethernet autoselect
(10GBASE-CR1 full-duplex)" now, switch also shows mac address at the
"LACP Partner System ID". Thank you for identifying the issue. Can the
patch be applied directly, or more work needs to be done to identify
when to set full-duplex mode?
Regards,
Andrius V
From: s ymgch <s.ymgch228@gmail.com>
To: gnats-bugs@netbsd.org
Cc: yamaguchi@netbsd.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org,
vezhlys@gmail.com
Subject: Re: kern/58124: lagg(4) fails to work with lacp protocol on mcx(4)
Date: Tue, 9 Apr 2024 10:37:58 +0900
Hi,
On Tue, Apr 9, 2024 at 4:20=E2=80=AFAM Andrius V <vezhlys@gmail.com> wrote:
>
> Hi,
>
> You are completely right! Setting the patch helps and lacp protocol
> starts to work. mcx0/mcx1 shows "media: Ethernet autoselect
> (10GBASE-CR1 full-duplex)" now, switch also shows mac address at the
> "LACP Partner System ID". Thank you for identifying the issue. Can the
> patch be applied directly, or more work needs to be done to identify
> when to set full-duplex mode?
I don't know whether the patch is correct toward mcx(4) or not, because
I'm not familiar with mcx(4). And I don't have any mcx(4) devices.
So, I'd like someone to review and commit the patch.
-- Yamaguchi
From: Andrius V <vezhlys@gmail.com>
To: s ymgch <s.ymgch228@gmail.com>, gnats-bugs@netbsd.org
Cc: jmcneill@netbsd.org, yamaguchi@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org
Subject: Re: kern/58124: lagg(4) fails to work with lacp protocol on mcx(4)
Date: Wed, 10 Apr 2024 21:48:43 +0300
Hi,
Comparing OpenBSD and NetBSD driver, there's one place where
potentially OpenBSD sets full-duplex in comparison to NetBSD:
https://nxr.netbsd.org/xref/src/sys/dev/pci/if_mcx.c#8176
https://github.com/openbsd/src/blob/a938a57b1f753b55309620f7e0ecb50db35645b=
7/sys/dev/pci/if_mcx.c#L8114
However we don't have this particular "link status". So my guess that
we need to set it in mcx_media_status(), potentially based on media
type, and it is not needed in ifmedia_add() (need to test). Is there a
need for more complex logic, I am not sure.
On Wed, Apr 10, 2024 at 12:06=E2=80=AFPM s ymgch <s.ymgch228@gmail.com> wro=
te:
>
> Hi,
>
> I suppose you maintain mcx(4). and this PR is related to the driver.
> Could you take a look at the PR?
>
> Best Regards,
> Yamaguchi
>
> On Tue, Apr 9, 2024 at 10:37=E2=80=AFAM s ymgch <s.ymgch228@gmail.com> wr=
ote:
> >
> > Hi,
> >
> > On Tue, Apr 9, 2024 at 4:20=E2=80=AFAM Andrius V <vezhlys@gmail.com> wr=
ote:
> > >
> > > Hi,
> > >
> > > You are completely right! Setting the patch helps and lacp protocol
> > > starts to work. mcx0/mcx1 shows "media: Ethernet autoselect
> > > (10GBASE-CR1 full-duplex)" now, switch also shows mac address at the
> > > "LACP Partner System ID". Thank you for identifying the issue. Can t=
he
> > > patch be applied directly, or more work needs to be done to identify
> > > when to set full-duplex mode?
> >
> > I don't know whether the patch is correct toward mcx(4) or not, because
> > I'm not familiar with mcx(4). And I don't have any mcx(4) devices.
> > So, I'd like someone to review and commit the patch.
> >
> > -- Yamaguchi
From: "Andrius Varanavicius" <andvar@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/58124 CVS commit: src/sys/dev/pci
Date: Thu, 11 Apr 2024 10:42:42 +0000
Module Name: src
Committed By: andvar
Date: Thu Apr 11 10:42:42 UTC 2024
Modified Files:
src/sys/dev/pci: if_mcx.c
Log Message:
mcx(4): enforce full-duplex mark in mcx_media_status(), when link is up.
LACP protocol requires full-duplex to be enabled for lagg(4) to work,
however mcx(4) was not setting this capability making it to fail.
Fixes PR kern/58124. OK'd by msaitoh@
To generate a diff of this commit:
cvs rdiff -u -r1.26 -r1.27 src/sys/dev/pci/if_mcx.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
State-Changed-From-To: open->pending-pullups
State-Changed-By: andvar@NetBSD.org
State-Changed-When: Fri, 12 Apr 2024 21:40:16 +0000
State-Changed-Why:
[pullup-10 #660]
From: Andrius V <vezhlys@gmail.com>
To: gnats-bugs@netbsd.org
Cc: yamaguchi@netbsd.org, netbsd-bugs@netbsd.org, gnats-admin@netbsd.org,
andvar@netbsd.org
Subject: Re: kern/58124 (lagg(4) fails to work with lacp protocol on mcx(4))
Date: Sat, 13 Apr 2024 00:44:26 +0300
On Sat, Apr 13, 2024 at 12:40=E2=80=AFAM <andvar@netbsd.org> wrote:
>
> State-Changed-Why:
> [pullup-10 #660]
>
Actually [pullup-10 #661]
From: "Martin Husemann" <martin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/58124 CVS commit: [netbsd-10] src/sys/dev/pci
Date: Thu, 18 Apr 2024 16:29:48 +0000
Module Name: src
Committed By: martin
Date: Thu Apr 18 16:29:48 UTC 2024
Modified Files:
src/sys/dev/pci [netbsd-10]: if_mcx.c
Log Message:
Pull up following revision(s) (requested by andvar in ticket #661):
sys/dev/pci/if_mcx.c: revision 1.27
mcx(4): enforce full-duplex mark in mcx_media_status(), when link is up.
LACP protocol requires full-duplex to be enabled for lagg(4) to work,
however mcx(4) was not setting this capability making it to fail.
Fixes PR kern/58124. OK'd by msaitoh@
To generate a diff of this commit:
cvs rdiff -u -r1.25.4.1 -r1.25.4.2 src/sys/dev/pci/if_mcx.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
State-Changed-From-To: pending-pullups->closed
State-Changed-By: riastradh@NetBSD.org
State-Changed-When: Fri, 19 Apr 2024 02:39:52 +0000
State-Changed-Why:
fixed and pulled up to 10
inapplicable <10 because lagg(4) is new in 10
From: Andrius V <vezhlys@gmail.com>
To: gnats-bugs@netbsd.org
Cc: yamaguchi@netbsd.org, netbsd-bugs@netbsd.org, gnats-admin@netbsd.org,
riastradh@netbsd.org
Subject: Re: kern/58124 (lagg(4) fails to work with lacp protocol on mcx(4))
Date: Fri, 19 Apr 2024 10:05:40 +0300
On Fri, Apr 19, 2024 at 5:39=E2=80=AFAM <riastradh@netbsd.org> wrote:
>
> Synopsis: lagg(4) fails to work with lacp protocol on mcx(4)
>
> State-Changed-From-To: pending-pullups->closed
> State-Changed-By: riastradh@NetBSD.org
> State-Changed-When: Fri, 19 Apr 2024 02:39:52 +0000
> State-Changed-Why:
> fixed and pulled up to 10
> inapplicable <10 because lagg(4) is new in 10
>
Technically speaking this ended up to be a mcx(4) issue, which may be
relevant for NetBSD 9.
I didn't do PR for the few reasons:
NetBSD 9 driver is older and would need separate testing, maybe it
would make more sense to sync the driver fully instead, it there's a
need.
I also didn't test if full-duplex helps agr(4), which may be an option
for 9-th release.
I am not planning to use it on netbsd 9.
So, unless requested by someone, I am not planning to cater netbsd-9 releas=
e.
>Unformatted:
(Contact us)
$NetBSD: query-full-pr,v 1.47 2022/09/11 19:34:41 kim Exp $
$NetBSD: gnats_config.sh,v 1.9 2014/08/02 14:16:04 spz Exp $
Copyright © 1994-2024
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.
Home