Re: [Intel-wired-lan] [PATCH iwl-net v4] ice: Block PF reinit if attached to bond
On 11/28/23 08:37, Jiri Pirko wrote: Mon, Nov 27, 2023 at 05:23:55PM CET, sachin.baha...@intel.com wrote: Nack. Remove the netdev during re-init, that would solve your issue. Looks like some checks are needed to be added in devlink code to make sure drivers behave properly. I'm on in. Sure. This fix should apply to all drivers. Adding it in devlink makes more sense. I am not a devlink expert, so I hope you or someone else can help with it. No, you misunderstood. I'll just add a check-warn in devlink for case when port exists during reload. You need to fix it in your driver. Having a message in log that reminds devs would be useful, thanks! + return -EBUSY; + } ice_unload(pf); return 0; case DEVLINK_RELOAD_ACTION_FW_ACTIVATE: -- 2.25.1 ___ Intel-wired-lan mailing list Intel-wired-lan@osuosl.org https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
Re: [Intel-wired-lan] The difference between linux kernel driver and FreeBSD's with Intel X533
On 11/28/23 04:20, Ivan Pang wrote: On Wed, Oct 18, 2023 at 09:50:35PM +0300, Skyler Mäntysaari wrote: On Tue, Oct 10, 2023, at 03:39, Skyler Mäntysaari wrote: On Tue, Oct 10, 2023, at 02:50, Skyler Mäntysaari wrote: On Mon, Oct 9, 2023, at 18:33, Jesse Brandeburg wrote: On 10/4/2023 10:08 AM, Skyler Mäntysaari wrote: Hi there, It seems that for reasons unknown to me, my Intel X533 based 10G SFP+ doesn't want to work with kernel 6.1.55 in VyOS 1.4 nor Debian 12 but it does in OPNsense which is based on FreeBSD 13.2. How would I go about debugging this properly? Both sides see light, but no link unless I'm using FreeBSD. https://forum.vyos.io/t/10g-sfp-trouble-with-linking-intel-x553/12253/11?u=samip537 Hi Skyler, Response from Intel team: In the ethtool -m output pasted I see TX and RX optical power is fine. Could you request fault status on both sides? Just want to check if link is down because we are at local-fault or link partner is at local-fault. rmmod ixgbe modprobe ixgbe ethtool -S eth0 | grep fault Since it is 10G, if our side TX is ON (power level says it is) then we should expect link partner RX to be locked so cannot be at Local Fault. Skyler, please gather that ethtool -S data for us. Jesse Hi Jesse, As the other side of the link is an Juniper, I'm not quite sure how I would gather the same data from it as it doesn't have ethtool? I have also somewhat given up hope on it working on VyOS and instead I am using OPNsense for the moment but I still have VyOS installed as well. Skyler Hi Jesse, I did verify that the grep doesn't yield any results on the VyOS box and all of the data returned has an value of 0. Paste of which is here: https://p.kapsi.fi/?4a82cedb4f4801ec#DcEgFMFK7cH13EqypsY4ZaHS5taeA1zXevmmTSVW3P9x I really think something weird is going on with the driver in Linux as otherwise the same exact config on Juniper wouldn't work there either. The VyOS box also says that it's unable to modify autoneg settings, or speed/duplex of the interface. Skyler It has been verified that the driver in kernel version 5.4.255 seems to work aka 1.3 VyOS. Post from another user in the same thread about it: https://forum.vyos.io/t/10g-sfp-trouble-with-linking-intel-x553/12253/46 I have also verified that the out-of-tree ixgbe driver does work, but in-kernel doesn't in kernel 6.1.58. Please share these findings with the correct Intel team so that this could be fixed. - Skyler Hi Skyler, Jesse, I came across this very similar issue when upgrading our networking gear from kernel 5.15 to 6.1. Our 10G link fails with the in-tree 6.1 ixgbe driver but works with the out-of-tree 5.x versions. I found that my link issues were related to this commit: ixgbe: Manual AN-37 for troublesome link partners for X550 SFI https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v6.1.63&id=565736048bd5f9888990569993c6b6bfdf6dcb6d Specifically, our 10G link works when both sides of the fiber are running the in-tree 6.1 ixgbe driver with this autonegotiation change. Our link also works when both sides are running the 5.x ixgbe drivers without this commit. It fails, however, when only one side has this commit. Our current setup compiles the in-tree 6.1 ixgbe driver with this commit reverted, for compatibility with our varying hardware. I would appreciate it if anyone can cross-check my claim with their hardware as well. Also, would anyone be able to help explain what some of those registers and reg_val being written are doing? -Ivan Hi Ivan, It seems that for whatever reason, your reply does not appear on the lists? - Skyler ___ Intel-wired-lan mailing list Intel-wired-lan@osuosl.org https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
Re: [Intel-wired-lan] The difference between linux kernel driver and FreeBSD's with Intel X533
On 11/28/23 04:20, Ivan Pang wrote: On Wed, Oct 18, 2023 at 09:50:35PM +0300, Skyler Mäntysaari wrote: On Tue, Oct 10, 2023, at 03:39, Skyler Mäntysaari wrote: On Tue, Oct 10, 2023, at 02:50, Skyler Mäntysaari wrote: On Mon, Oct 9, 2023, at 18:33, Jesse Brandeburg wrote: On 10/4/2023 10:08 AM, Skyler Mäntysaari wrote: Hi there, It seems that for reasons unknown to me, my Intel X533 based 10G SFP+ doesn't want to work with kernel 6.1.55 in VyOS 1.4 nor Debian 12 but it does in OPNsense which is based on FreeBSD 13.2. How would I go about debugging this properly? Both sides see light, but no link unless I'm using FreeBSD. https://forum.vyos.io/t/10g-sfp-trouble-with-linking-intel-x553/12253/11?u=samip537 Hi Skyler, Response from Intel team: In the ethtool -m output pasted I see TX and RX optical power is fine. Could you request fault status on both sides? Just want to check if link is down because we are at local-fault or link partner is at local-fault. rmmod ixgbe modprobe ixgbe ethtool -S eth0 | grep fault Since it is 10G, if our side TX is ON (power level says it is) then we should expect link partner RX to be locked so cannot be at Local Fault. Skyler, please gather that ethtool -S data for us. Jesse Hi Jesse, As the other side of the link is an Juniper, I'm not quite sure how I would gather the same data from it as it doesn't have ethtool? I have also somewhat given up hope on it working on VyOS and instead I am using OPNsense for the moment but I still have VyOS installed as well. Skyler Hi Jesse, I did verify that the grep doesn't yield any results on the VyOS box and all of the data returned has an value of 0. Paste of which is here: https://p.kapsi.fi/?4a82cedb4f4801ec#DcEgFMFK7cH13EqypsY4ZaHS5taeA1zXevmmTSVW3P9x I really think something weird is going on with the driver in Linux as otherwise the same exact config on Juniper wouldn't work there either. The VyOS box also says that it's unable to modify autoneg settings, or speed/duplex of the interface. Skyler It has been verified that the driver in kernel version 5.4.255 seems to work aka 1.3 VyOS. Post from another user in the same thread about it: https://forum.vyos.io/t/10g-sfp-trouble-with-linking-intel-x553/12253/46 I have also verified that the out-of-tree ixgbe driver does work, but in-kernel doesn't in kernel 6.1.58. Please share these findings with the correct Intel team so that this could be fixed. - Skyler Hi Skyler, Jesse, I came across this very similar issue when upgrading our networking gear from kernel 5.15 to 6.1. Our 10G link fails with the in-tree 6.1 ixgbe driver but works with the out-of-tree 5.x versions. I found that my link issues were related to this commit: ixgbe: Manual AN-37 for troublesome link partners for X550 SFI https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v6.1.63&id=565736048bd5f9888990569993c6b6bfdf6dcb6d Specifically, our 10G link works when both sides of the fiber are running the in-tree 6.1 ixgbe driver with this autonegotiation change. Our link also works when both sides are running the 5.x ixgbe drivers without this commit. It fails, however, when only one side has this commit. Our current setup compiles the in-tree 6.1 ixgbe driver with this commit reverted, for compatibility with our varying hardware. I would appreciate it if anyone can cross-check my claim with their hardware as well. Also, would anyone be able to help explain what some of those registers and reg_val being written are doing? -Ivan Hi Ivan, It seems that for whatever reason, your reply does not appear on the lists? P.S Sorry for the double posting if you see this twice. It wasn't sent to Ivan correctly the first try. - Skyler ___ Intel-wired-lan mailing list Intel-wired-lan@osuosl.org https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
Re: [Intel-wired-lan] [PATCH iwl-next v1] ice: Improve logs for max ntuple errors
> -Original Message- > From: Intel-wired-lan On Behalf Of Pawel > Kaminski > Sent: Tuesday, November 21, 2023 7:02 AM > To: intel-wired-lan@osuosl.org > Cc: net...@vger.kernel.org; Kaminski, Pawel ; > Brandeburg, Jesse > Subject: [Intel-wired-lan] [PATCH iwl-next v1] ice: Improve logs for max > ntuple errors > > Supported number of ntuple filters affect also maximum location value that > can be provided to ethtool command. Update error message to provide info > about max supported value. > > Fix double spaces in the error messages. > > Reviewed-by: Jesse Brandeburg > Signed-off-by: Pawel Kaminski > --- > drivers/net/ethernet/intel/ice/ice_ethtool_fdir.c | 13 - > 1 file changed, 8 insertions(+), 5 deletions(-) > Tested-by: Pucha Himasekhar Reddy (A Contingent worker at Intel) ___ Intel-wired-lan mailing list Intel-wired-lan@osuosl.org https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
Re: [Intel-wired-lan] The difference between linux kernel driver and FreeBSD's with Intel X533
On Wed, Oct 18, 2023 at 09:50:35PM +0300, Skyler Mäntysaari wrote: > On Tue, Oct 10, 2023, at 03:39, Skyler Mäntysaari wrote: > > On Tue, Oct 10, 2023, at 02:50, Skyler Mäntysaari wrote: > >> On Mon, Oct 9, 2023, at 18:33, Jesse Brandeburg wrote: > >>> On 10/4/2023 10:08 AM, Skyler Mäntysaari wrote: > >> Hi there, > >> > >> It seems that for reasons unknown to me, my Intel X533 based 10G SFP+ > >> doesn't want to work with kernel 6.1.55 in VyOS 1.4 nor Debian 12 but > >> it does in OPNsense which is based on FreeBSD 13.2. > >> > >> How would I go about debugging this properly? Both sides see light, > >> but no link unless I'm using FreeBSD. > https://forum.vyos.io/t/10g-sfp-trouble-with-linking-intel-x553/12253/11?u=samip537 > >>> > >>> Hi Skyler, > >>> > >>> Response from Intel team: > >>> > >>> In the ethtool -m output pasted I see TX and RX optical power is fine. > >>> Could you request fault status on both sides? Just want to check if link > >>> is down because we are at local-fault or link partner is at local-fault. > >>> > >>> rmmod ixgbe > >>> modprobe ixgbe > >>> ethtool -S eth0 | grep fault > >>> > >>> Since it is 10G, if our side TX is ON (power level says it is) then we > >>> should expect link partner RX to be locked so cannot be at Local Fault. > >>> > >>> Skyler, please gather that ethtool -S data for us. > >>> > >>> Jesse > >>> > >>> > >>> > >>> > >> > >> Hi Jesse, > >> > >> As the other side of the link is an Juniper, I'm not quite sure how I > >> would gather the same data from it as it doesn't have ethtool? > >> > >> I have also somewhat given up hope on it working on VyOS and instead I > >> am using OPNsense for the moment but I still have VyOS installed as > >> well. > >> > >> Skyler > > > > Hi Jesse, > > > > I did verify that the grep doesn't yield any results on the VyOS box > > and all of the data returned has an value of 0. Paste of which is here: > > https://p.kapsi.fi/?4a82cedb4f4801ec#DcEgFMFK7cH13EqypsY4ZaHS5taeA1zXevmmTSVW3P9x > > > > I really think something weird is going on with the driver in Linux as > > otherwise the same exact config on Juniper wouldn't work there either. > > The VyOS box also says that it's unable to modify autoneg settings, or > > speed/duplex of the interface. > > > > Skyler > > It has been verified that the driver in kernel version 5.4.255 seems to work > aka 1.3 VyOS. Post from another user in the same thread about it: > https://forum.vyos.io/t/10g-sfp-trouble-with-linking-intel-x553/12253/46 > > I have also verified that the out-of-tree ixgbe driver does work, but > in-kernel doesn't in kernel 6.1.58. > > Please share these findings with the correct Intel team so that this could be > fixed. > > - Skyler > Hi Skyler, Jesse, I came across this very similar issue when upgrading our networking gear from kernel 5.15 to 6.1. Our 10G link fails with the in-tree 6.1 ixgbe driver but works with the out-of-tree 5.x versions. I found that my link issues were related to this commit: ixgbe: Manual AN-37 for troublesome link partners for X550 SFI https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v6.1.63&id=565736048bd5f9888990569993c6b6bfdf6dcb6d Specifically, our 10G link works when both sides of the fiber are running the in-tree 6.1 ixgbe driver with this autonegotiation change. Our link also works when both sides are running the 5.x ixgbe drivers without this commit. It fails, however, when only one side has this commit. Our current setup compiles the in-tree 6.1 ixgbe driver with this commit reverted, for compatibility with our varying hardware. I would appreciate it if anyone can cross-check my claim with their hardware as well. Also, would anyone be able to help explain what some of those registers and reg_val being written are doing? -Ivan ___ Intel-wired-lan mailing list Intel-wired-lan@osuosl.org https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
Re: [Intel-wired-lan] [PATCH net-next v5 03/14] page_pool: avoid calling no-op externals when possible
From: Jakub Kicinski Date: Mon, 27 Nov 2023 10:17:20 -0800 > On Mon, 27 Nov 2023 15:32:19 +0100 Alexander Lobakin wrote: >>> Sorry for not remembering the suggestion:( >> >> In the previous versions of this change I used a global flag per whole >> page_pool, just like XSk does for the whole XSk buff pool, then you >> proposed to use the lowest bit of ::dma_addr and store it per page, so >> that it would be more granular/precise. I tested it and it doesn't >> perform worse than global, but in some cases may be beneficial. > > FWIW I'd vote to stick to per-page pool. You seem to handle the > sizeof(dma_addr_t) > sizeof(long) case correctly but the code is > growing in complexity, providing no known/measurable benefit. > We can always do this later but for now it seems like a premature > optimization to me. Yeah, this also seems more logical and optimal to me. Will wait a bit for a possible reply from Chris and then send the next rev. Thanks, Olek ___ Intel-wired-lan mailing list Intel-wired-lan@osuosl.org https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
Re: [Intel-wired-lan] [PATCH iwl-net v4] ice: Block PF reinit if attached to bond
> From: Jiri Pirko > Sent: Monday, November 27, 2023 11:38 PM > To: Bahadur, Sachin > Cc: intel-wired-...@lists.osuosl.org; net...@vger.kernel.org; linux- > ker...@vger.kernel.org > Subject: Re: [PATCH iwl-net v4] ice: Block PF reinit if attached to bond > > Mon, Nov 27, 2023 at 05:23:55PM CET, sachin.baha...@intel.com wrote: > > > >> Nack. Remove the netdev during re-init, that would solve your issue. > >> Looks like some checks are needed to be added in devlink code to make > >> sure drivers behave properly. I'm on in. > > > >Sure. This fix should apply to all drivers. Adding it in devlink makes > >more sense. I am not a devlink expert, so I hope you or someone else > >can help with it. > > No, you misunderstood. I'll just add a check-warn in devlink for case when > port > exists during reload. You need to fix it in your driver. What should be fixed in my driver. Can you clarify ? And are suggesting I add the check-warn in devlink code ? > > > >> > >> > >> >+ return -EBUSY; > >> >+ } > >> > ice_unload(pf); > >> > return 0; > >> > case DEVLINK_RELOAD_ACTION_FW_ACTIVATE: > >> >-- > >> >2.25.1 > >> > > >> > ___ Intel-wired-lan mailing list Intel-wired-lan@osuosl.org https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
[Intel-wired-lan] [PATCH iwl-next v1] ice: Print NIC FW version during init
Print NIC FW version during PF initialization. FW version in dmesg is used to identify and isolate issues. Particularly useful when dmesg is read after reboot. Reviewed-by: Pawel Kaminski Signed-off-by: Sachin Bahadur --- drivers/net/ethernet/intel/ice/ice_main.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/net/ethernet/intel/ice/ice_main.c b/drivers/net/ethernet/intel/ice/ice_main.c index 1f159b4362ec..71d3d8cfdd1d 100644 --- a/drivers/net/ethernet/intel/ice/ice_main.c +++ b/drivers/net/ethernet/intel/ice/ice_main.c @@ -4568,6 +4568,12 @@ static int ice_init_dev(struct ice_pf *pf) dev_err(dev, "ice_init_hw failed: %d\n", err); return err; } + dev_info(dev, "fw %u.%u.%u api %u.%u.%u nvm %u.%u 0x%08x %u.%u.%u\n", +hw->fw_maj_ver, hw->fw_min_ver, hw->fw_patch, hw->api_maj_ver, +hw->api_min_ver, hw->api_patch, hw->flash.nvm.major, +hw->flash.nvm.minor, hw->flash.nvm.eetrack, +hw->flash.orom.major, hw->flash.orom.build, +hw->flash.orom.patch); /* Some cards require longer initialization times * due to necessity of loading FW from an external source. -- 2.25.1 ___ Intel-wired-lan mailing list Intel-wired-lan@osuosl.org https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
Re: [Intel-wired-lan] [PATCH iwl-next v1] ice: Print NIC FW version during init
Dear Sachin, Thank you for the patch. Am 28.11.23 um 19:35 schrieb Sachin Bahadur: Print NIC FW version during PF initialization. FW version in dmesg is used to identify and isolate issues. Particularly useful when dmesg is read after reboot. Please paste one example log line into the commit message. Reviewed-by: Pawel Kaminski Signed-off-by: Sachin Bahadur --- drivers/net/ethernet/intel/ice/ice_main.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/net/ethernet/intel/ice/ice_main.c b/drivers/net/ethernet/intel/ice/ice_main.c index 1f159b4362ec..71d3d8cfdd1d 100644 --- a/drivers/net/ethernet/intel/ice/ice_main.c +++ b/drivers/net/ethernet/intel/ice/ice_main.c @@ -4568,6 +4568,12 @@ static int ice_init_dev(struct ice_pf *pf) dev_err(dev, "ice_init_hw failed: %d\n", err); return err; } + dev_info(dev, "fw %u.%u.%u api %u.%u.%u nvm %u.%u 0x%08x %u.%u.%u\n", +hw->fw_maj_ver, hw->fw_min_ver, hw->fw_patch, hw->api_maj_ver, +hw->api_min_ver, hw->api_patch, hw->flash.nvm.major, +hw->flash.nvm.minor, hw->flash.nvm.eetrack, +hw->flash.orom.major, hw->flash.orom.build, +hw->flash.orom.patch); /* Some cards require longer initialization times * due to necessity of loading FW from an external source. Reviewed-by: Paul Menzel Kind regards, Paul ___ Intel-wired-lan mailing list Intel-wired-lan@osuosl.org https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
[Intel-wired-lan] [PATCH iwl-next v4] ice: replace ice_vf_recreate_vsi() with ice_vf_reconfig_vsi()
The ice_vf_create_vsi() function and its VF ops helper introduced by commit
a4c785e8162e ("ice: convert vf_ops .vsi_rebuild to .create_vsi") are used
during an individual VF reset to re-create the VSI. This was done in order
to ensure that the VSI gets properly reconfigured within the hardware.
This is somewhat heavy handed as we completely release the VSI memory and
structure, and then create a new VSI. This can also potentially force a
change of the VSI index as we will re-use the first open slot in the VSI
array which may not be the same.
As part of implementing devlink reload, commit 6624e780a577 ("ice: split
ice_vsi_setup into smaller functions") split VSI setup into smaller
functions, introducing both ice_vsi_cfg() and ice_vsi_decfg() which can be
used to configure or deconfigure an existing software VSI structure.
Rather than completely removing the VSI and adding a new one using the
.create_vsi() VF operation, simply use ice_vsi_decfg() to remove the
current configuration. Save the VSI type and then call ice_vsi_cfg() to
reconfigure the VSI as the same type that it was before.
The existing reset logic assumes that all hardware filters will be removed,
so also call ice_fltr_remove_all() before re-configuring the VSI.
This new operation does not re-create the VSI, so rename it to
ice_vf_reconfig_vsi().
The new approach can safely share the exact same flow for both SR-IOV VFs
as well as the Scalable IOV VFs being worked on. This uses less code and is
a better abstraction over fully deleting the VSI and adding a new one.
Fixes: a4c785e8162e ("ice: convert vf_ops .vsi_rebuild to .create_vsi")
Signed-off-by: Jacob Keller
---
Changes since v3:
* Removal of filters was a side effect of VSI being fully deleted by
firmware. Since we don't do that now, it was not happening. Fix this by
adding a call to ice_fltr_remove_all(). Thanks to Jakub Buchocki for
figuring out this solution.
* Rebase on to current dev-queue.
v3 was posted at
https://lore.kernel.org/intel-wired-lan/2023071936.1048751-1-jacob.e.kel...@intel.com/
v2 was posted at
https://lore.kernel.org/intel-wired-lan/20230712204730.326331-1-jacob.e.kel...@intel.com/
v1 was posted at
https://lore.kernel.org/intel-wired-lan/20230504211829.3869868-1-jacob.e.kel...@intel.com/
drivers/net/ethernet/intel/ice/ice_sriov.c| 24 ++---
drivers/net/ethernet/intel/ice/ice_vf_lib.c | 35 +--
drivers/net/ethernet/intel/ice/ice_vf_lib.h | 1 -
.../ethernet/intel/ice/ice_vf_lib_private.h | 1 +
4 files changed, 28 insertions(+), 33 deletions(-)
diff --git a/drivers/net/ethernet/intel/ice/ice_sriov.c
b/drivers/net/ethernet/intel/ice/ice_sriov.c
index 4ee349fe6409..a94a1c48c3de 100644
--- a/drivers/net/ethernet/intel/ice/ice_sriov.c
+++ b/drivers/net/ethernet/intel/ice/ice_sriov.c
@@ -761,24 +761,6 @@ static void ice_sriov_clear_reset_trigger(struct ice_vf
*vf)
ice_flush(hw);
}
-/**
- * ice_sriov_create_vsi - Create a new VSI for a VF
- * @vf: VF to create the VSI for
- *
- * This is called by ice_vf_recreate_vsi to create the new VSI after the old
- * VSI has been released.
- */
-static int ice_sriov_create_vsi(struct ice_vf *vf)
-{
- struct ice_vsi *vsi;
-
- vsi = ice_vf_vsi_setup(vf);
- if (!vsi)
- return -ENOMEM;
-
- return 0;
-}
-
/**
* ice_sriov_post_vsi_rebuild - tasks to do after the VF's VSI have been
rebuilt
* @vf: VF to perform tasks on
@@ -798,7 +780,6 @@ static const struct ice_vf_ops ice_sriov_vf_ops = {
.poll_reset_status = ice_sriov_poll_reset_status,
.clear_reset_trigger = ice_sriov_clear_reset_trigger,
.irq_close = NULL,
- .create_vsi = ice_sriov_create_vsi,
.post_vsi_rebuild = ice_sriov_post_vsi_rebuild,
};
@@ -1141,8 +1122,7 @@ int ice_sriov_set_msix_vec_count(struct pci_dev *vf_dev,
int msix_vec_count)
if (vf->first_vector_idx < 0)
goto unroll;
- ice_vf_vsi_release(vf);
- if (vf->vf_ops->create_vsi(vf)) {
+ if (ice_vf_reconfig_vsi(vf)) {
/* Try to rebuild with previous values */
needs_rebuild = true;
goto unroll;
@@ -1169,7 +1149,7 @@ int ice_sriov_set_msix_vec_count(struct pci_dev *vf_dev,
int msix_vec_count)
return -EINVAL;
if (needs_rebuild)
- vf->vf_ops->create_vsi(vf);
+ ice_vf_reconfig_vsi(vf);
ice_ena_vf_mappings(vf);
ice_put_vf(vf);
diff --git a/drivers/net/ethernet/intel/ice/ice_vf_lib.c
b/drivers/net/ethernet/intel/ice/ice_vf_lib.c
index d6f74513b495..2ffdae9a82df 100644
--- a/drivers/net/ethernet/intel/ice/ice_vf_lib.c
+++ b/drivers/net/ethernet/intel/ice/ice_vf_lib.c
@@ -248,29 +248,44 @@ static void ice_vf_pre_vsi_rebuild(struct ice_vf *vf)
}
/**
- * ice_vf_recreate_vsi - Release and re-create the VF's VSI
- * @vf: VF to recreate the VSI for
+ * ice_vf_reconfig_vsi - Reconfigure a VF VSI with the device
+ * @vf: VF
Re: [Intel-wired-lan] [PATCH net-next v6 1/7] net: ethtool: pass ethtool_rxfh to get/set_rxfh ethtool ops
> -Original Message- > From: Zaki, Ahmed > Sent: Monday, November 27, 2023 6:15 AM > To: Jakub Kicinski > Cc: net...@vger.kernel.org; intel-wired-...@lists.osuosl.org; cor...@lwn.net; > Brandeburg, Jesse ; Nguyen, Anthony L > ; da...@davemloft.net; eduma...@google.com; > pab...@redhat.com; vladimir.olt...@nxp.com; and...@lunn.ch; > ho...@kernel.org; mkube...@suse.cz; willemdebruijn.ker...@gmail.com; > g...@nvidia.com; alexander.du...@gmail.com; linux-...@vger.kernel.org; > Bagnucki, Igor ; Keller, Jacob E > > Subject: Re: [PATCH net-next v6 1/7] net: ethtool: pass ethtool_rxfh to > get/set_rxfh ethtool ops > > > > On 2023-11-21 16:29, Jakub Kicinski wrote: > > On Mon, 20 Nov 2023 13:56:08 -0700 Ahmed Zaki wrote: > >>u32 (*get_rxfh_key_size)(struct net_device *); > >>u32 (*get_rxfh_indir_size)(struct net_device *); > >> - int (*get_rxfh)(struct net_device *, u32 *indir, u8 *key, > >> - u8 *hfunc); > >> - int (*set_rxfh)(struct net_device *, const u32 *indir, > >> - const u8 *key, const u8 hfunc); > >> + int (*get_rxfh)(struct net_device *, struct ethtool_rxfh *, > >> + u32 *indir, u8 *key); > >> + int (*set_rxfh)(struct net_device *, struct ethtool_rxfh *, > >> + const u32 *indir, const u8 *key); > >>int (*get_rxfh_context)(struct net_device *, u32 *indir, u8 *key, > >>u8 *hfunc, u32 rss_context); > >>int (*set_rxfh_context)(struct net_device *, const u32 *indir, > > > > This conversion looks 1/4th done. You should do the following: > > > > - First simplify the code by always providing a pointer to all params > > (indir, key and func); the fact that some of them may be NULL seems > > like a weird historic thing or a premature optimization. > > It will simplify the drivers if all pointers are always present. > > You don't have to remove the if () checks in the existing drivers. > > > > - Then make the functions take a dev pointer, and a pointer to a > > single struct wrapping all arguments. The set_* should also take > > an extack. > > Can we skip the "extack" part for this series? There is no > "ETHTOOL_MSG_RSS_SET" netlink message, which is needed for user-space to > get the ACK and adding all the netlink stuff seems a bit out of scope. > > I will do the rest in the next version. Please include the extack now even if there isn't an immediate user. A NULL value is acceptable to pass for "there is no extended ACK available", but this way we don't have to modify the drivers *again* when the extack is available if we add a netlink op in the future. Thanks, Jake ___ Intel-wired-lan mailing list Intel-wired-lan@osuosl.org https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
Re: [Intel-wired-lan] The difference between linux kernel driver and FreeBSD's with Intel X533
[Cc: +, +regressi...@lists.linux.dev] #regzbot ^introduced: 565736048bd5f9888990569993c6b6bfdf6dcb6d Dear Ivan, Am 28.11.23 um 03:20 schrieb Ivan Pang: On Wed, Oct 18, 2023 at 09:50:35PM +0300, Skyler Mäntysaari wrote: On Tue, Oct 10, 2023, at 03:39, Skyler Mäntysaari wrote: On Tue, Oct 10, 2023, at 02:50, Skyler Mäntysaari wrote: On Mon, Oct 9, 2023, at 18:33, Jesse Brandeburg wrote: On 10/4/2023 10:08 AM, Skyler Mäntysaari wrote: Hi there, It seems that for reasons unknown to me, my Intel X533 based 10G SFP+ doesn't want to work with kernel 6.1.55 in VyOS 1.4 nor Debian 12 but it does in OPNsense which is based on FreeBSD 13.2. How would I go about debugging this properly? Both sides see light, but no link unless I'm using FreeBSD. https://forum.vyos.io/t/10g-sfp-trouble-with-linking-intel-x553/12253/11?u=samip537 Response from Intel team: In the ethtool -m output pasted I see TX and RX optical power is fine. Could you request fault status on both sides? Just want to check if link is down because we are at local-fault or link partner is at local-fault. rmmod ixgbe modprobe ixgbe ethtool -S eth0 | grep fault Since it is 10G, if our side TX is ON (power level says it is) then we should expect link partner RX to be locked so cannot be at Local Fault. Skyler, please gather that ethtool -S data for us. As the other side of the link is an Juniper, I'm not quite sure how I would gather the same data from it as it doesn't have ethtool? I have also somewhat given up hope on it working on VyOS and instead I am using OPNsense for the moment but I still have VyOS installed as well. I did verify that the grep doesn't yield any results on the VyOS box and all of the data returned has an value of 0. Paste of which is here: https://p.kapsi.fi/?4a82cedb4f4801ec#DcEgFMFK7cH13EqypsY4ZaHS5taeA1zXevmmTSVW3P9x I really think something weird is going on with the driver in Linux as otherwise the same exact config on Juniper wouldn't work there either. The VyOS box also says that it's unable to modify autoneg settings, or speed/duplex of the interface. It has been verified that the driver in kernel version 5.4.255 seems to work aka 1.3 VyOS. Post from another user in the same thread about it: https://forum.vyos.io/t/10g-sfp-trouble-with-linking-intel-x553/12253/46 I have also verified that the out-of-tree ixgbe driver does work, but in-kernel doesn't in kernel 6.1.58. Please share these findings with the correct Intel team so that this could be fixed. I came across this very similar issue when upgrading our networking gear from kernel 5.15 to 6.1. Our 10G link fails with the in-tree 6.1 ixgbe driver but works with the out-of-tree 5.x versions. I found that my link issues were related to this commit: ixgbe: Manual AN-37 for troublesome link partners for X550 SFI https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v6.1.63&id=565736048bd5f9888990569993c6b6bfdf6dcb6d Specifically, our 10G link works when both sides of the fiber are running the in-tree 6.1 ixgbe driver with this autonegotiation change. Our link also works when both sides are running the 5.x ixgbe drivers without this commit. It fails, however, when only one side has this commit. Our current setup compiles the in-tree 6.1 ixgbe driver with this commit reverted, for compatibility with our varying hardware. I would appreciate it if anyone can cross-check my claim with their hardware as well. Also, would anyone be able to help explain what some of those registers and reg_val being written are doing? Thank you for mentioning the culprit. That commit is present since v6.1-rc1. I am adding the regression folks. Kind regards, Paul ___ Intel-wired-lan mailing list Intel-wired-lan@osuosl.org https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
[Intel-wired-lan] [tnguy-next-queue:40GbE] BUILD SUCCESS 95260816b489509c1f5b0141d0ae7b65be3c1d39
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue.git 40GbE branch HEAD: 95260816b489509c1f5b0141d0ae7b65be3c1d39 iavf: use iavf_schedule_aq_request() helper elapsed time: 1484m configs tested: 222 configs skipped: 2 The following configs have been built successfully. More configs may be tested in the coming days. tested configs: alpha allnoconfig gcc alpha defconfig gcc arc allnoconfig gcc arc defconfig gcc arcnsimosci_defconfig gcc arc randconfig-001-20231128 gcc arc randconfig-002-20231128 gcc arm allnoconfig gcc arm aspeed_g5_defconfig gcc arm footbridge_defconfig gcc arm imxrt_defconfig gcc arm integrator_defconfig gcc arm jornada720_defconfig gcc armmulti_v7_defconfig gcc armmvebu_v5_defconfig clang arm nhk8815_defconfig gcc arm pxa3xx_defconfig gcc arm pxa910_defconfig gcc arm randconfig-001-20231128 clang arm randconfig-002-20231128 clang arm randconfig-003-20231128 clang arm randconfig-004-20231128 clang arm rpc_defconfig gcc arm sama5_defconfig gcc armspear6xx_defconfig gcc arm tegra_defconfig gcc arm64allmodconfig clang arm64 allnoconfig gcc arm64 defconfig gcc arm64 randconfig-001-20231128 clang arm64 randconfig-002-20231128 clang arm64 randconfig-003-20231128 clang arm64 randconfig-004-20231128 clang csky allnoconfig gcc cskydefconfig gcc csky randconfig-001-20231128 gcc csky randconfig-002-20231128 gcc hexagon allmodconfig clang hexagon allyesconfig clang hexagon randconfig-001-20231128 clang hexagon randconfig-002-20231128 clang i386 allmodconfig clang i386 allnoconfig clang i386 allyesconfig clang i386 buildonly-randconfig-001-20231128 clang i386 buildonly-randconfig-002-20231128 clang i386 buildonly-randconfig-003-20231128 clang i386 buildonly-randconfig-004-20231128 clang i386 buildonly-randconfig-005-20231128 clang i386 buildonly-randconfig-006-20231128 clang i386defconfig gcc i386 randconfig-001-20231128 clang i386 randconfig-002-20231128 clang i386 randconfig-003-20231128 clang i386 randconfig-004-20231128 clang i386 randconfig-005-20231128 clang i386 randconfig-006-20231128 clang i386 randconfig-011-20231128 gcc i386 randconfig-012-20231128 gcc i386 randconfig-013-20231128 gcc i386 randconfig-014-20231128 gcc i386 randconfig-015-20231128 gcc i386 randconfig-016-20231128 gcc loongarchallmodconfig gcc loongarch allnoconfig gcc loongarchallyesconfig gcc loongarch defconfig gcc loongarch randconfig-001-20231128 gcc loongarch randconfig-002-20231128 gcc m68k allmodconfig gcc m68k allnoconfig gcc m68k allyesconfig gcc m68k amiga_defconfig gcc m68k apollo_defconfig gcc m68k bvme6000_defconfig gcc m68kdefconfig gcc m68km5307c3_defconfig gcc m68km5407c3_defconfig gcc m68kmvme147_defconfig gcc m68kq40_defconfig gcc microblaze allmodconfig gcc microblazeallnoconfig gcc microblaze allyesconfig gcc microblaze defconfig gcc microblaze mmu_defconfig gcc mips
[Intel-wired-lan] [PATCH net-next v18 0/5] add-fwlog-v2-debugfs
Firmware (FW) log support was added to the ice driver, but that version is no longer supported. There is a newer version of FW logging (v2) that adds more control knobs to get the exact data out of the FW for debugging. The interface for FW logging is debugfs. This was chosen based on discussions here: https://lore.kernel.org/netdev/20230214180712.53fc8...@kernel.org/ and https://lore.kernel.org/netdev/20231012164033.1069f...@kernel.org/ We talked about using devlink in a variety of ways, but none of those options made any sense for the way the FW reports data. We briefly talked about using ethtool, but that seemed to go by the wayside. Ultimately it seems like using debugfs is the way to go so re-implement the code to use that. FW logging is across all the PFs on the device so restrict the commands to only PF0. If the device supports FW logging then a directory named 'fwlog' will be created under '/sys/kernel/debug/ice/'. A variety of files will be created to manage the behavior of logging. The following files will be created: - modules/ - nr_messages - enable - log_size - data where modules/ is used to read/write the log level for a specific module nr_messages is used to determine how many events should be in each message sent to the driver enable is used to start/stop FW logging. This is a boolean value so only 1 or 0 are permissible values log_size is used to configure the amount of memory the driver uses for log data data is used to read/clear the log data Generally there is a lot of data and dumping that data to syslog will result in a loss of data. This causes problems when decoding the data and the user doesn't know that data is missing until later. Instead of dumping the FW log output to syslog use debugfs. This ensures that all the data the driver has gets retrieved correctly. The FW log data is binary data that the FW team decodes to determine what happened in firmware. The binary blob is sent to Intel for decoding. --- v18: - changed the memory allocation from a buffer per ring to a single buffer that gets divided up for each ring - updated the documentation to indicate that FW logging must be disabled to clear the data. also clarified that any value written to the 'data' file will clear the data v17 at: https://lore.kernel.org/intel-wired-lan/20231109003830.154-1-paul.m.stillwell...@intel.com/ v17: - changed the log level configuration from a single file for all modules to a file per module. - changed 'nr_buffs' to 'log_size' because users understand memory sizes better than a number of buffers - changed 'resolution' to 'nr_messages' to better reflect what it represents - updated documentation to reflect these changes v16 at: https://lore.kernel.org/intel-wired-lan/20230823222152.106-1-paul.m.stillwell...@intel.com/ v16: - removed CONFIG_DEBUG_FS wrapper around code because the debugfs calls handle this case already - moved ice_debugfs_exit() call to remove unreachable code issue - minor changes to documentation based on community feedback v15 at: https://lore.kernel.org/intel-wired-lan/20230808224310.127-1-paul.m.stillwell...@intel.com/ v15: - changed PAGE_SIZE to ICE_AQ_MAX_BUF_LEN because PAGE_SIZE can be bigger than 4K v14 at: https://lore.kernel.org/intel-wired-lan/20230713222558.142-1-paul.m.stillwell...@intel.com/ v14: - fixed an issue where 0 was a valid number for 'nr_buffs' - fixed an issue with the output from 'enable' not being a 1 when FW logging was enabled v13 at: https://lore.kernel.org/intel-wired-lan/20230628231402.176-1-paul.m.stillwell...@intel.com/ v13: - moved the enable code out into it's own patch - added linux/vmalloc.h header file in ice_fwlog.c - removed NULL check before freeing ring->data v12 at: https://lore.kernel.org/intel-wired-lan/20230607222443.119-1-paul.m.stillwell...@intel.com/ v12: - re-wrote debugfs code to use individual files for configuration instead of parsing the strings within the driver. - use sysfs_match_string() to parse the 2 values we need for configuring the modules instead of strncmp() - use ring buffers to contain log data instead of a list. this allows for wrapping the data instead of stopping log capture - split documentation into it's own patch v11 at: https://lore.kernel.org/intel-wired-lan/20230313231841.113-1-paul.m.stillwell...@intel.com/ v11: - changed 'events' variable to be u32 instead of unsigned long since the FW expects a 32-bit value. This caused some changes to a few functions that pass 'events' and changed the parsing in debugfs. Also fixed an issue with i386 cross compile where BIT_ULL() was being used incorrectly and causing compiler issues on i386 because the value was larger than the variable. v10 at: https://lore.kernel.org/intel-wired-lan/20230308235102.170-1-paul.m.stillwell...@intel.com/ v10: - updated code to only create 'fwlog' file if FW logging is supported - combined code under single ifdef in header file - removed defines that were not used and added them
[Intel-wired-lan] [PATCH net-next v18 5/5] ice: add documentation for FW logging
Add documentation for FW logging in Documentation/networking/device_drivers/ethernet/intel/ice.rst Signed-off-by: Paul M Stillwell Jr --- v17->v18: - updated the documentation for clearing the log data to indicate that logging has to be disabled and that any value will clear the data v16->v17: - fixed incorrect directory path in commit message - updated wording to try to indicate that the FW must support logging in order for the 'fwlog' file to exist - updates based on file name changes v15->v16: minor updates to documentation based on community feedback v14->v15: none v13->v14: none v12->v13: changed to imperitive, updated against latest version of file v11->v12: separated out documentation to it's own patch --- .../device_drivers/ethernet/intel/ice.rst | 141 ++ 1 file changed, 141 insertions(+) diff --git a/Documentation/networking/device_drivers/ethernet/intel/ice.rst b/Documentation/networking/device_drivers/ethernet/intel/ice.rst index e4d065c55ea8..5038e54586af 100644 --- a/Documentation/networking/device_drivers/ethernet/intel/ice.rst +++ b/Documentation/networking/device_drivers/ethernet/intel/ice.rst @@ -895,6 +895,147 @@ driver writes raw bytes by the GNSS object to the receiver through i2c. Please refer to the hardware GNSS module documentation for configuration details. +Firmware (FW) logging +- +The driver supports FW logging via the debugfs interface on PF 0 only. The FW +running on the NIC must support FW logging; if the FW doesn't support FW logging +the 'fwlog' file will not get created in the ice debugfs directory. + +Module configuration + +Firmware logging is configured on a per module basis. Each module can be set to +a value independent of the other modules (unless the module 'all' is specified). +The modules will be instantiated under the 'fwlog/modules' directory. + +The user can set the log level for a module by writing to the module file like +this:: + + # echo > /sys/kernel/debug/ice/\:18\:00.0/fwlog/modules/ + +where + +* log_level is a name as described below. Each level includes the + messages from the previous/lower level + + *none + *error + *warning + *normal + *verbose + +* module is a name that represents the module to receive events for. The + module names are + + *general + *ctrl + *link + *link_topo + *dnl + *i2c + *sdp + *mdio + *adminq + *hdma + *lldp + *dcbx + *dcb + *xlr + *nvm + *auth + *vpd + *iosf + *parser + *sw + *scheduler + *txq + *rsvd + *post + *watchdog + *task_dispatch + *mng + *synce + *health + *tsdrv + *pfreg + *mdlver + *all + +The name 'all' is special and allows the user to set all of the modules to the +specified log_level or to read the log_level of all of the modules. + +Example usage to configure the modules +^^ + +To set a single module to 'verbose':: + + # echo verbose > /sys/kernel/debug/ice/\:18\:00.0/fwlog/modules/link + +To set multiple modules then issue the command multiple times:: + + # echo verbose > /sys/kernel/debug/ice/\:18\:00.0/fwlog/modules/link + # echo warning > /sys/kernel/debug/ice/\:18\:00.0/fwlog/modules/ctrl + # echo none > /sys/kernel/debug/ice/\:18\:00.0/fwlog/modules/dcb + +To set all the modules to the same value:: + + # echo normal > /sys/kernel/debug/ice/\:18\:00.0/fwlog/modules/all + +To read the log_level of a specific module (e.g. module 'general'):: + + # cat /sys/kernel/debug/ice/\:18\:00.0/fwlog/modules/general + +To read the log_level of all the modules:: + + # cat /sys/kernel/debug/ice/\:18\:00.0/fwlog/modules/all + +Enabling FW log +~~~ +Configuring the modules indicates to the FW that the configured modules should +generate events that the driver is interested in, but it **does not** send the +events to the driver until the enable message is sent to the FW. To do this +the user can write a 1 (enable) or 0 (disable) to 'fwlog/enable'. An example +is:: + + # echo 1 > /sys/kernel/debug/ice/\:18\:00.0/fwlog/enable + +Retrieving FW log data +~~ +The FW log data can be retrieved by reading from 'fwlog/data'. The user can +write any value to 'fwlog/data' to clear the data. The data can only be cleared +when FW logging is disabled. The FW log data is a binary file that is sent to +Intel and used to help debug user issues. + +An example to read the data is:: + + # cat /sys/kernel/debug/ice/\:18\:00.0/fwlog/data > fwlog.bin + +An examp
[Intel-wired-lan] [PATCH net-next v18 1/5] ice: remove FW logging code
The FW logging code doesn't work because there is no way to set
cq_ena or uart_ena so remove the code. This code is the original
(v1) way of FW logging so it should be replaced with the v2 way.
Signed-off-by: Paul M Stillwell Jr
---
v17->v18: none
v16->v17: none
v15->v16: none
v14->v15: none
v13->v14: none
v12->v13: none
v11->v12: none
v10->v11: none
v9->v10: none
v8->v9: none
v7->v8: none
v6->v7: none
v5->v6: none
v4->v5: none
v3->v4: none
v2->v3: none
v1->v2: none
---
.../net/ethernet/intel/ice/ice_adminq_cmd.h | 78 ---
drivers/net/ethernet/intel/ice/ice_common.c | 217 --
drivers/net/ethernet/intel/ice/ice_common.h | 1 -
drivers/net/ethernet/intel/ice/ice_main.c | 3 -
drivers/net/ethernet/intel/ice/ice_type.h | 20 --
5 files changed, 319 deletions(-)
diff --git a/drivers/net/ethernet/intel/ice/ice_adminq_cmd.h
b/drivers/net/ethernet/intel/ice/ice_adminq_cmd.h
index 51c241ab6b8e..775adca0a145 100644
--- a/drivers/net/ethernet/intel/ice/ice_adminq_cmd.h
+++ b/drivers/net/ethernet/intel/ice/ice_adminq_cmd.h
@@ -2094,78 +2094,6 @@ struct ice_aqc_add_rdma_qset_data {
struct ice_aqc_add_tx_rdma_qset_entry rdma_qsets[];
};
-/* Configure Firmware Logging Command (indirect 0xFF09)
- * Logging Information Read Response (indirect 0xFF10)
- * Note: The 0xFF10 command has no input parameters.
- */
-struct ice_aqc_fw_logging {
- u8 log_ctrl;
-#define ICE_AQC_FW_LOG_AQ_EN BIT(0)
-#define ICE_AQC_FW_LOG_UART_EN BIT(1)
- u8 rsvd0;
- u8 log_ctrl_valid; /* Not used by 0xFF10 Response */
-#define ICE_AQC_FW_LOG_AQ_VALIDBIT(0)
-#define ICE_AQC_FW_LOG_UART_VALID BIT(1)
- u8 rsvd1[5];
- __le32 addr_high;
- __le32 addr_low;
-};
-
-enum ice_aqc_fw_logging_mod {
- ICE_AQC_FW_LOG_ID_GENERAL = 0,
- ICE_AQC_FW_LOG_ID_CTRL,
- ICE_AQC_FW_LOG_ID_LINK,
- ICE_AQC_FW_LOG_ID_LINK_TOPO,
- ICE_AQC_FW_LOG_ID_DNL,
- ICE_AQC_FW_LOG_ID_I2C,
- ICE_AQC_FW_LOG_ID_SDP,
- ICE_AQC_FW_LOG_ID_MDIO,
- ICE_AQC_FW_LOG_ID_ADMINQ,
- ICE_AQC_FW_LOG_ID_HDMA,
- ICE_AQC_FW_LOG_ID_LLDP,
- ICE_AQC_FW_LOG_ID_DCBX,
- ICE_AQC_FW_LOG_ID_DCB,
- ICE_AQC_FW_LOG_ID_NETPROXY,
- ICE_AQC_FW_LOG_ID_NVM,
- ICE_AQC_FW_LOG_ID_AUTH,
- ICE_AQC_FW_LOG_ID_VPD,
- ICE_AQC_FW_LOG_ID_IOSF,
- ICE_AQC_FW_LOG_ID_PARSER,
- ICE_AQC_FW_LOG_ID_SW,
- ICE_AQC_FW_LOG_ID_SCHEDULER,
- ICE_AQC_FW_LOG_ID_TXQ,
- ICE_AQC_FW_LOG_ID_RSVD,
- ICE_AQC_FW_LOG_ID_POST,
- ICE_AQC_FW_LOG_ID_WATCHDOG,
- ICE_AQC_FW_LOG_ID_TASK_DISPATCH,
- ICE_AQC_FW_LOG_ID_MNG,
- ICE_AQC_FW_LOG_ID_MAX,
-};
-
-/* Defines for both above FW logging command/response buffers */
-#define ICE_AQC_FW_LOG_ID_S0
-#define ICE_AQC_FW_LOG_ID_M(0xFFF << ICE_AQC_FW_LOG_ID_S)
-
-#define ICE_AQC_FW_LOG_CONF_SUCCESS0 /* Used by response */
-#define ICE_AQC_FW_LOG_CONF_BAD_INDX BIT(12) /* Used by response */
-
-#define ICE_AQC_FW_LOG_EN_S12
-#define ICE_AQC_FW_LOG_EN_M(0xF << ICE_AQC_FW_LOG_EN_S)
-#define ICE_AQC_FW_LOG_INFO_EN BIT(12) /* Used by command */
-#define ICE_AQC_FW_LOG_INIT_EN BIT(13) /* Used by command */
-#define ICE_AQC_FW_LOG_FLOW_EN BIT(14) /* Used by command */
-#define ICE_AQC_FW_LOG_ERR_EN BIT(15) /* Used by command */
-
-/* Get/Clear FW Log (indirect 0xFF11) */
-struct ice_aqc_get_clear_fw_log {
- u8 flags;
-#define ICE_AQC_FW_LOG_CLEAR BIT(0)
-#define ICE_AQC_FW_LOG_MORE_DATA_AVAIL BIT(1)
- u8 rsvd1[7];
- __le32 addr_high;
- __le32 addr_low;
-};
-
/* Download Package (indirect 0x0C40) */
/* Also used for Update Package (indirect 0x0C41 and 0x0C42) */
struct ice_aqc_download_pkg {
@@ -2507,8 +2435,6 @@ struct ice_aq_desc {
struct ice_aqc_add_rdma_qset add_rdma_qset;
struct ice_aqc_add_get_update_free_vsi vsi_cmd;
struct ice_aqc_add_update_free_vsi_resp add_update_free_vsi_res;
- struct ice_aqc_fw_logging fw_logging;
- struct ice_aqc_get_clear_fw_log get_clear_fw_log;
struct ice_aqc_download_pkg download_pkg;
struct ice_aqc_set_cgu_input_config set_cgu_input_config;
struct ice_aqc_get_cgu_input_config get_cgu_input_config;
@@ -2717,10 +2643,6 @@ enum ice_adminq_opc {
/* Standalone Commands/Events */
ice_aqc_opc_event_lan_overflow = 0x1001,
-
- /* debug commands */
- ice_aqc_opc_fw_logging = 0xFF09,
- ice_aqc_opc_fw_logging_info = 0xFF10,
};
#endif /* _ICE_ADMINQ_CMD_H_ */
diff --git a/drivers/net/ethernet/intel/ice/ice_common.c
b/drivers/net/ethernet/intel/ice/ice_common.c
index 8df151dd0c90..ade2cff23856 100644
--- a/drivers/net/ethernet/intel/ice/ice_common.c
+++ b/drivers/net/e
[Intel-wired-lan] [PATCH net-next v18 3/5] ice: enable FW logging
Once users have configured the FW logging then allow them to enable it
by writing to the 'fwlog/enable' file. The file accepts a boolean value
(0 or 1) where 1 means enable FW logging and 0 means disable FW logging.
# echo > /sys/kernel/debug/ice/\:18\:00.0/fwlog/enable
Where is 0 or 1.
The user can read the 'fwlog/enable' file to see whether logging is
enabled or not. Reading the actual data is a separate patch. To see the
current value then:
# cat /sys/kernel/debug/ice/\:18\:00.0/fwlog/enable
Signed-off-by: Paul M Stillwell Jr
---
v17->v18: none
v16->v17: commit message changes only
v15->v16: none
v14->v15: none
v13->v14: fixed an issue where reading the file produced an 8 instead of
a 1
v12->v13: created a new patch for the enable code
---
.../net/ethernet/intel/ice/ice_adminq_cmd.h | 3 +
drivers/net/ethernet/intel/ice/ice_debugfs.c | 117 ++
drivers/net/ethernet/intel/ice/ice_fwlog.c| 67 ++
drivers/net/ethernet/intel/ice/ice_fwlog.h| 2 +
4 files changed, 189 insertions(+)
diff --git a/drivers/net/ethernet/intel/ice/ice_adminq_cmd.h
b/drivers/net/ethernet/intel/ice/ice_adminq_cmd.h
index 73452333d342..82139e0ede6a 100644
--- a/drivers/net/ethernet/intel/ice/ice_adminq_cmd.h
+++ b/drivers/net/ethernet/intel/ice/ice_adminq_cmd.h
@@ -2393,6 +2393,7 @@ enum ice_aqc_fw_logging_mod {
};
/* Set FW Logging configuration (indirect 0xFF30)
+ * Register for FW Logging (indirect 0xFF31)
* Query FW Logging (indirect 0xFF32)
*/
struct ice_aqc_fw_log {
@@ -2401,6 +2402,7 @@ struct ice_aqc_fw_log {
#define ICE_AQC_FW_LOG_CONF_AQ_EN BIT(1)
#define ICE_AQC_FW_LOG_QUERY_REGISTEREDBIT(2)
#define ICE_AQC_FW_LOG_CONF_SET_VALID BIT(3)
+#define ICE_AQC_FW_LOG_AQ_REGISTER BIT(0)
#define ICE_AQC_FW_LOG_AQ_QUERYBIT(2)
u8 rsp_flag;
@@ -2722,6 +2724,7 @@ enum ice_adminq_opc {
/* FW Logging Commands */
ice_aqc_opc_fw_logs_config = 0xFF30,
+ ice_aqc_opc_fw_logs_register= 0xFF31,
ice_aqc_opc_fw_logs_query = 0xFF32,
};
diff --git a/drivers/net/ethernet/intel/ice/ice_debugfs.c
b/drivers/net/ethernet/intel/ice/ice_debugfs.c
index 75731cf91274..3d1d2f24ff2f 100644
--- a/drivers/net/ethernet/intel/ice/ice_debugfs.c
+++ b/drivers/net/ethernet/intel/ice/ice_debugfs.c
@@ -389,6 +389,120 @@ static const struct file_operations
ice_debugfs_nr_messages_fops = {
.write = ice_debugfs_nr_messages_write,
};
+/**
+ * ice_debugfs_enable_read - read from 'enable' file
+ * @filp: the opened file
+ * @buffer: where to write the data for the user to read
+ * @count: the size of the user's buffer
+ * @ppos: file position offset
+ */
+static ssize_t ice_debugfs_enable_read(struct file *filp,
+ char __user *buffer, size_t count,
+ loff_t *ppos)
+{
+ struct ice_pf *pf = filp->private_data;
+ struct ice_hw *hw = &pf->hw;
+ char buff[32] = {};
+ int status;
+
+ /* don't allow commands if the FW doesn't support it */
+ if (!ice_fwlog_supported(&pf->hw))
+ return -EOPNOTSUPP;
+
+ snprintf(buff, sizeof(buff), "%u\n",
+(u16)(hw->fwlog_cfg.options &
+ICE_FWLOG_OPTION_IS_REGISTERED) >> 3);
+
+ status = simple_read_from_buffer(buffer, count, ppos, buff,
+strlen(buff));
+
+ return status;
+}
+
+/**
+ * ice_debugfs_enable_write - write into 'enable' file
+ * @filp: the opened file
+ * @buf: where to find the user's data
+ * @count: the length of the user's data
+ * @ppos: file position offset
+ */
+static ssize_t
+ice_debugfs_enable_write(struct file *filp, const char __user *buf,
+size_t count, loff_t *ppos)
+{
+ struct ice_pf *pf = filp->private_data;
+ struct device *dev = ice_pf_to_dev(pf);
+ struct ice_hw *hw = &pf->hw;
+ ssize_t ret;
+ char **argv;
+ int argc;
+
+ /* don't allow commands if the FW doesn't support it */
+ if (!ice_fwlog_supported(hw))
+ return -EOPNOTSUPP;
+
+ /* don't allow partial writes */
+ if (*ppos != 0)
+ return 0;
+
+ ret = ice_debugfs_parse_cmd_line(buf, count, &argv, &argc);
+ if (ret)
+ goto err_copy_from_user;
+
+ if (argc == 1) {
+ bool enable;
+
+ ret = kstrtobool(argv[0], &enable);
+ if (ret)
+ goto enable_write_error;
+
+ if (enable)
+ hw->fwlog_cfg.options |= ICE_FWLOG_OPTION_ARQ_ENA;
+ else
+ hw->fwlog_cfg.options &= ~ICE_FWLOG_OPTION_ARQ_ENA;
+
+ ret = ice_fwlog_set(hw, &hw->fwlog_cfg);
+ if (ret)
+ goto enable_write_error;
+
+ if (enable)
+
[Intel-wired-lan] [PATCH net-next v18 2/5] ice: configure FW logging
Users want the ability to debug FW issues by retrieving the FW logs from the E8xx devices. Use debugfs to allow the user to configure the log level and number of messages for FW logging. If FW logging is supported on the E8xx then the file 'fwlog' will be created under the PCI device ID for the ice driver. If the file does not exist then either the E8xx doesn't support FW logging or debugfs is not enabled on the system. One thing users want to do is control which events are reported. The user can read and write the 'fwlog/modules/' to get/set the log levels. Each module in the FW that suports logging has a file under 'fwlog/modules' that supports reading (to see what the current log level is) and writing (to change the log level). The format to set the log levels for a module are: # echo > /sys/kernel/debug/ice/\:18\:00.0/fwlog/modules/ The supported log levels are: * none * error * warning * normal * verbose Each level includes the messages from the previous/lower level The modules that are supported are: * general * ctrl * link * link_topo * dnl * i2c * sdp * mdio * adminq * hdma * lldp * dcbx * dcb * xlr * nvm * auth * vpd * iosf * parser * sw * scheduler * txq * rsvd * post * watchdog * task_dispatch * mng * synce * health * tsdrv * pfreg * mdlver * all The module 'all' is a special module which allows the user to read or write to all of the modules. The following example command would set the DCB module to the 'normal' log level: # echo normal > /sys/kernel/debug/ice/\:18\:00.0/fwlog/modules/dcb If the user wants to set the DCB, Link, and the AdminQ modules to 'verbose' then the commands are: # echo verbose > /sys/kernel/debug/ice/\:18\:00.0/fwlog/modules/dcb # echo verbose > /sys/kernel/debug/ice/\:18\:00.0/fwlog/modules/link # echo verbose > /sys/kernel/debug/ice/\:18\:00.0/fwlog/modules/adminq If the user wants to set all modules to the 'warning' level then the command is: # echo warning > /sys/kernel/debug/ice/\:18\:00.0/fwlog/modules/all If the user wants to disable logging for a module then they can set the level to 'none'. An example setting the 'watchdog' module is: # echo none > /sys/kernel/debug/ice/\:18\:00.0/fwlog/modules/watchdog If the user wants to see what the log level is for a specific module then the command is: # cat /sys/kernel/debug/ice/\:18\:00.0/fwlog/modules/dcb This will return the log level for the DCB module. If the user wants to see the log level for all the modules then the command is: # cat /sys/kernel/debug/ice/\:18\:00.0/fwlog/modules/all Writing to the module file will update the configuration, but NOT enable the configuration (that is a separate command). In addition to configuring the modules, the user can also configure the number of log messages (nr_messages) to include in a single Admin Receive Queue (ARQ) event.The range is 1-128 (1 means push every log message, 128 means push only when the max AQ command buffer is full). The suggested value is 10. To see/change the resolution the user can read/write the 'fwlog/nr_messages' file. An example changing the value to 50 is # echo 50 > /sys/kernel/debug/ice/\:18\:00.0/fwlog/nr_messages To see the current value of 'nr_messages' then the command is: # cat /sys/kernel/debug/ice/\:18\:00.0/fwlog/nr_messages Signed-off-by: Paul M Stillwell Jr --- v17->v18: none v16->v17: updates based on community feedback - create a file per FW log module under 'fwlog/modules/' instead of having a single file for all the modules. This simplifies the code for writing the log level because we don't have to parse the module name - rename 'resolution' to 'nr_messages' to better reflect what it represents - add a structure to track all the file dentries for the FW modules - moved ice_fwlog_deinit() from a subsequent patch to this patch because the driver has to free the dentry tracking memory - removed the code that printed the entire FW log configuration; only print the module info or the number of messages - fixed an issue where we were using the wrong length when copying data from the user for parsing the command line - release memory sooner in ice_debugfs_parse_cmd_line() so it always gets released v15->v16: - moved ice_debugfs_exit() to fix unreachable code issue - removed CONFIG_DEBUG_FS defines because they aren't needed v14->v15: changed PAGE_SIZE to ICE_AQ_MAX_BUF_LEN v13->v14: none v12->v13: pulled out 'enable' code and put into a separate patch v11->v12: - rewrote debugfs code to use separate file for reading/writing the configuration status (fwlog/modules) - added a file for configuring the resolution (fwlog/resolution) v10->v11: none no data on previous versions --- drivers/net/ethernet/intel/i
[Intel-wired-lan] [PATCH net-next v18 4/5] ice: add ability to read FW log data and configure the amount of memory for log data
Once logging is enabled the user should read the data from the 'data'
file. The data is in the form of a binary blob that can be sent to Intel
for decoding. To read the data use a command like:
# cat /sys/kernel/debug/ice/\:18\:00.0/fwlog/data > log_data.bin
If the user wants to clear the FW log data that has been stored in the
driver then they can write any value to the 'data' file and that will clear
the data. An example is:
# echo 34 > /sys/kernel/debug/ice/\:18\:00.0/fwlog/data
In addition to being able to read the data the user can configure how
much memory is used to store FW log data. This allows the user to
increase/decrease the amount of memory based on the users situation.
The data is stored such that if the memory fills up then the oldest data
will get overwritten in a circular manner. To change the amount of
memory the user can write to the 'log_size' file like this:
# echo > /sys/kernel/debug/ice/\:18\:00.0/fwlog/log_size
Where is one of 128K, 256K, 512K, 1M, and 2M. The default value
is 1M.
The user can see the current value of 'log_size' by reading the file:
# cat /sys/kernel/debug/ice/\:18\:00.0/fwlog/log_size
Signed-off-by: Paul M Stillwell Jr
---
v17->v18:
- changed the memory allocation for the ring buffers to allocate all the
space up front instead of allocating 4K buffers per ring. This makes
it easier because there aren't as many allocations and frees and its
easier to track the memory
v16->v17:
- changed 'nr_buffs' to 'log_size' to make it easier for users to set
the amount of memory they want to use when logging
- changed the 'log_size' values to be set between 128K and 2M instead of
allowing the user to write any power of 2 value between 1 and 2MB
v15->v16: none
v14->v15: changed PAGE_SIZE to ICE_AQ_MAX_BUF_LEN
v13->v14: fixed an issue where 0 was an accepted value to nr_buffs
v12->v13:
- moved 'enable' file addition to the correct patch
- added comment to header file about inclusion of 0xFF33 command
- added linux/vmalloc.h header file in ice_fwlog.c
- removed NULL check before freeing ring->data
v11->v12:
- added fwlog/data file for reading and clearing data
- added fwlog/nr_buffs to change the number of data buffers to store log
data in
---
.../net/ethernet/intel/ice/ice_adminq_cmd.h | 2 +
drivers/net/ethernet/intel/ice/ice_debugfs.c | 249 ++
drivers/net/ethernet/intel/ice/ice_fwlog.c| 150 ++-
drivers/net/ethernet/intel/ice/ice_fwlog.h| 22 ++
drivers/net/ethernet/intel/ice/ice_main.c | 29 ++
drivers/net/ethernet/intel/ice/ice_type.h | 1 +
6 files changed, 452 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/ice/ice_adminq_cmd.h
b/drivers/net/ethernet/intel/ice/ice_adminq_cmd.h
index 82139e0ede6a..6a5e974a1776 100644
--- a/drivers/net/ethernet/intel/ice/ice_adminq_cmd.h
+++ b/drivers/net/ethernet/intel/ice/ice_adminq_cmd.h
@@ -2395,6 +2395,7 @@ enum ice_aqc_fw_logging_mod {
/* Set FW Logging configuration (indirect 0xFF30)
* Register for FW Logging (indirect 0xFF31)
* Query FW Logging (indirect 0xFF32)
+ * FW Log Event (indirect 0xFF33)
*/
struct ice_aqc_fw_log {
u8 cmd_flags;
@@ -2726,6 +2727,7 @@ enum ice_adminq_opc {
ice_aqc_opc_fw_logs_config = 0xFF30,
ice_aqc_opc_fw_logs_register= 0xFF31,
ice_aqc_opc_fw_logs_query = 0xFF32,
+ ice_aqc_opc_fw_logs_event = 0xFF33,
};
#endif /* _ICE_ADMINQ_CMD_H_ */
diff --git a/drivers/net/ethernet/intel/ice/ice_debugfs.c
b/drivers/net/ethernet/intel/ice/ice_debugfs.c
index 3d1d2f24ff2f..953dbeddfb93 100644
--- a/drivers/net/ethernet/intel/ice/ice_debugfs.c
+++ b/drivers/net/ethernet/intel/ice/ice_debugfs.c
@@ -64,6 +64,17 @@ static const char * const ice_fwlog_level_string[] = {
"verbose",
};
+/* the order in this array is important. it matches the ordering of the
+ * values in the FW so the index is the same value as in ice_fwlog_level
+ */
+static const char * const ice_fwlog_log_size[] = {
+ "128K",
+ "256K",
+ "512K",
+ "1M",
+ "2M",
+};
+
/**
* ice_fwlog_print_module_cfg - print current FW logging module configuration
* @hw: pointer to the HW structure
@@ -503,6 +514,238 @@ static const struct file_operations
ice_debugfs_enable_fops = {
.write = ice_debugfs_enable_write,
};
+/**
+ * ice_debugfs_log_size_read - read from 'log_size' file
+ * @filp: the opened file
+ * @buffer: where to write the data for the user to read
+ * @count: the size of the user's buffer
+ * @ppos: file position offset
+ */
+static ssize_t ice_debugfs_log_size_read(struct file *filp,
+char __user *buffer, size_t count,
+loff_t *ppos)
+{
+ struct ice_pf *pf = filp->private_data;
+ struct ice_hw *hw = &pf->hw;
+ char buff[32] = {};
+ int status, index;
Re: [Intel-wired-lan] [PATCH net-next 0/5] igc: ethtool: Check VLAN TCI mask
Kurt Kanzenbach writes: > Hi, > > currently it is possible to configure receive queue assignment using the VLAN > TCI field with arbitrary masks. However, the hardware only supports steering > either by full TCI or the priority (PCP) field. In case a wrong mask is given > by > the user the driver will silently convert it into a PCP filter which is not > desired. Therefore, add a check for it. > > Patches #1 to #4 are minor things found along the way. > Some very minor things: patches 2,3 and 4 have extra long lines in their commit messages that checkpatch.pl doesn't seem to like. Patches 4 and 5 read more like fixes to me. I think they could be proposed to -net, as they contain fixes to user visible issues. Do you think that makes sense? As for the code, feel free to add my Ack to the series: Acked-by: Vinicius Costa Gomes Cheers, -- Vinicius ___ Intel-wired-lan mailing list Intel-wired-lan@osuosl.org https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
Re: [Intel-wired-lan] [PATCH net-next v5 01/14] page_pool: make sure frag API fields don't span between cachelines
On 2023/11/27 22:08, Alexander Lobakin wrote:
> From: Yunsheng Lin
> Date: Sat, 25 Nov 2023 20:29:22 +0800
>
>> On 2023/11/24 23:47, Alexander Lobakin wrote:
>>> After commit 5027ec19f104 ("net: page_pool: split the page_pool_params
>>> into fast and slow") that made &page_pool contain only "hot" params at
>>> the start, cacheline boundary chops frag API fields group in the middle
>>> again.
>>> To not bother with this each time fast params get expanded or shrunk,
>>> let's just align them to `4 * sizeof(long)`, the closest upper pow-2 to
>>> their actual size (2 longs + 2 ints). This ensures 16-byte alignment for
>>> the 32-bit architectures and 32-byte alignment for the 64-bit ones,
>>> excluding unnecessary false-sharing.
>>>
>>> Signed-off-by: Alexander Lobakin
>>> ---
>>> include/net/page_pool/types.h | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/include/net/page_pool/types.h b/include/net/page_pool/types.h
>>> index e1bb92c192de..989d07b831fc 100644
>>> --- a/include/net/page_pool/types.h
>>> +++ b/include/net/page_pool/types.h
>>> @@ -127,7 +127,7 @@ struct page_pool {
>>>
>>> bool has_init_callback;
>>
>> It seems odd to have only a slow field between tow fast
>> field group, isn't it better to move it to the end of
>> page_pool or where is more appropriate?
>
> 1. There will be more in the subsequent patches.
> 2. ::has_init_callback happens each new page allocation, it's not slow.
>Jakub did put it here for purpose.
>
>>
>>>
>>> - long frag_users;
>>> + long frag_users __aligned(4 * sizeof(long));
>>
>> If we need that, why not just use 'cacheline_aligned_in_smp'?
>
> It can be an overkill. We don't need a full cacheline, but only these
> fields to stay within one, no matter whether they are in the beginning
> of it or at the end.
I am still a little lost here, A comment explaining why using '4' in the
above would be really helpful here.
___
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
Re: [Intel-wired-lan] [PATCH net-next v5 03/14] page_pool: avoid calling no-op externals when possible
On 2023/11/27 22:32, Alexander Lobakin wrote:
>
> Chris, any thoughts on a global flag for skipping DMA syncs ladder?
It seems there was one already in the past:
https://lore.kernel.org/netdev/7c55a4d7-b4aa-25d4-1917-f6f355bd7...@arm.com/T/
>
>>
>>
>>> +static inline bool page_pool_set_dma_addr(const struct page_pool *pool,
>>> + struct page *page,
>>> + dma_addr_t addr)
>>> {
>>> + unsigned long val = addr;
>>> +
>>> + if (unlikely(!addr)) {
>>> + page->dma_addr = 0;
>>> + return true;
>>> + }
>>
>> The above seems unrelated change?
>
> Related. We use page_put_set_dma_addr() to clear ::dma_addr as well
> (grep for it in page_pool.c). In this case, we don't want
> dma_need_sync() to be called as we explicitly pass zero. This check
> zeroes the field and exits as quickly as possible.
The question seems to be about if we need to ensure the LSB of
page->dma_addr is not set when page_pool releases a page back to page
allocator?
> In case with the call mentioned above, zero is a compile-time constant
> there, so that this little branch will be inlined with the rest dropped.
>
___
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
Re: [Intel-wired-lan] [PATCH net-next] ice: fix error code in ice_eswitch_attach()
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski :
On Mon, 27 Nov 2023 15:59:17 +0300 you wrote:
> Set the "err" variable on this error path.
>
> Fixes: fff292b47ac1 ("ice: add VF representors one by one")
> Signed-off-by: Dan Carpenter
> ---
> drivers/net/ethernet/intel/ice/ice_eswitch.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
Here is the summary with links:
- [net-next] ice: fix error code in ice_eswitch_attach()
https://git.kernel.org/netdev/net-next/c/1bc9d12e1c92
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
___
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
Re: [Intel-wired-lan] [PATCH iwl-next] i40e: remove fake support of rx-frames-irq
> -Original Message- > From: Intel-wired-lan On Behalf Of Jason > Xing > Sent: Monday, November 27, 2023 2:11 PM > To: Brandeburg, Jesse ; Nguyen, Anthony L > ; da...@davemloft.net; eduma...@google.com; > k...@kernel.org; pab...@redhat.com > Cc: net...@vger.kernel.org; intel-wired-...@lists.osuosl.org; > kerneljasonx...@gmail.com; Jason Xing > Subject: [Intel-wired-lan] [PATCH iwl-next] i40e: remove fake support of > rx-frames-irq > > From: Jason Xing > > Since we never support this feature for I40E driver, we don't have to > display the value when using 'ethtool -c eth0'. > > Before this patch applied, the rx-frames-irq is 256 which is consistent > with tx-frames-irq. Apparently it could mislead users. > > Signed-off-by: Jason Xing > --- > drivers/net/ethernet/intel/i40e/i40e_ethtool.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > Tested-by: Pucha Himasekhar Reddy (A Contingent worker at Intel) ___ Intel-wired-lan mailing list Intel-wired-lan@osuosl.org https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
