RE: [Intel-wired-lan] [PATCH net-next v3 1/2] e1000e: factor out systim sanitization
> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@lists.osuosl.org] On > Behalf Of Jarod Wilson > Sent: Tuesday, July 26, 2016 11:26 AM > To: linux-kernel@vger.kernel.org > Cc: net...@vger.kernel.org; intel-wired-...@lists.osuosl.org > Subject: [Intel-wired-lan] [PATCH net-next v3 1/2] e1000e: factor out systim > sanitization > > This is prepatory work for an expanding list of adapter families that have > occasional ~10 hour clock jumps when being used for PTP. Factor out the > sanitization function and convert to using a feature (bug) flag, per > suggestion from Jesse Brandeburg. > > Littering functional code with device-specific checks is much messier than > simply checking a flag, and having device-specific init set flags as needed. > There are probably a number of other cases in the e1000e code that > could/should be converted similarly. > > Suggested-by: Jesse Brandeburg > CC: Jesse Brandeburg > CC: Jeff Kirsher > CC: intel-wired-...@lists.osuosl.org > CC: net...@vger.kernel.org > Signed-off-by: Jarod Wilson > --- > drivers/net/ethernet/intel/e1000e/82571.c | 6 ++- > drivers/net/ethernet/intel/e1000e/e1000.h | 1 + > drivers/net/ethernet/intel/e1000e/netdev.c | 66 ++--- > - > 3 files changed, 44 insertions(+), 29 deletions(-) Tested-by: Aaron Brown
RE: [Intel-wired-lan] [PATCH net-next v3 2/2] e1000e: fix PTP on e1000_pch_lpt variants
> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@lists.osuosl.org] On > Behalf Of Jarod Wilson > Sent: Tuesday, July 26, 2016 11:26 AM > To: linux-kernel@vger.kernel.org > Cc: net...@vger.kernel.org; intel-wired-...@lists.osuosl.org > Subject: [Intel-wired-lan] [PATCH net-next v3 2/2] e1000e: fix PTP on > e1000_pch_lpt variants > > I've got reports that the Intel I-218V NIC in Intel NUC5i5RYH systems used > as a PTP slave experiences random ~10 hour clock jumps, which are resolved > if the same workaround for the 82574 and 82583 is employed, so set the > appropriate flag2 in e1000_pch_lpt_info too. > > Reported-by: Rupesh Patel > CC: Jesse Brandeburg > CC: Jeff Kirsher > CC: intel-wired-...@lists.osuosl.org > CC: net...@vger.kernel.org > Signed-off-by: Jarod Wilson > --- > drivers/net/ethernet/intel/e1000e/ich8lan.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) Tested-by: Aaron Brown
RE: [Intel-wired-lan] [PATCH net-next v3 1/2] e1000e: factor out systim sanitization
> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@lists.osuosl.org] On > Behalf Of Woodford, Timothy W. > Sent: Friday, July 29, 2016 7:41 AM > To: Woodford, Timothy W. ; Avargil, > Raanan ; Jarod Wilson ; > linux-kernel@vger.kernel.org; Hall, Christopher S > > Cc: net...@vger.kernel.org; intel-wired-...@lists.osuosl.org > Subject: Re: [Intel-wired-lan] [PATCH net-next v3 1/2] e1000e: factor out > systim sanitization > > >>> This is prepatory work for an expanding list of adapter families that have > occasional ~10 hour clock jumps when being used for PTP. Factor out the > sanitization function and convert to using a feature (bug) flag, per > suggestion > from Jesse Brandeburg. > >>> > >>> Littering functional code with device-specific checks is much messier than > simply checking a flag, and having device-specific init set flags as needed. > >>> There are probably a number of other cases in the e1000e code that > could/should be converted similarly. > >> > >> Looks ok to me. > >> Adding Chris who asked what happens if we reach the max retry counter > (E1000_MAX_82574_SYSTIM_REREAD)? > >> This counter is set to 50. > >> Can you, for testing purposes, decreased this value (or even set it to 0) > and see what happens? > > I'll set the max retry counter to 1 and run an overnight test to see what > happens. > > After running with this configuration for about 36 hours, I haven't seen any > timing jumps. Either this configuration eliminates the error, or it makes it > significantly less likely to occur. > > Tim Woodford Feel free to throw a Tested-by: on it if you like. Not a big deal either way, I managed to get enough cycles in on it I'm pretty happy with it as well. > ___ > Intel-wired-lan mailing list > intel-wired-...@lists.osuosl.org > http://lists.osuosl.org/mailman/listinfo/intel-wired-lan
RE: [Intel-wired-lan] [PATCH 1/1] timecounter: Make cyclecounter struct part of timecounter struct
> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On > Behalf Of Jeff Kirsher > Sent: Wednesday, December 6, 2017 8:25 AM > To: Kamble, Sagar A ; linux- > ker...@vger.kernel.org > Cc: alsa-de...@alsa-project.org; linux-r...@vger.kernel.org; > net...@vger.kernel.org; Richard Cochran ; > Stephen Boyd ; Chris Wilson wilson.co.uk>; John Stultz ; intel-wired- > l...@lists.osuosl.org; Thomas Gleixner ; > kvm...@lists.cs.columbia.edu; linux-arm-ker...@lists.infradead.org > Subject: Re: [Intel-wired-lan] [PATCH 1/1] timecounter: Make cyclecounter > struct part of timecounter struct > > On Sat, 2017-12-02 at 10:01 +0530, Sagar Arun Kamble wrote: > > There is no real need for the users of timecounters to define > > cyclecounter > > and timecounter variables separately. Since timecounter will always > > be > > based on cyclecounter, have cyclecounter struct as member of > > timecounter > > struct. > > > > Suggested-by: Chris Wilson > > Signed-off-by: Sagar Arun Kamble > > Cc: Chris Wilson > > Cc: Richard Cochran > > Cc: John Stultz > > Cc: Thomas Gleixner > > Cc: Stephen Boyd > > Cc: linux-kernel@vger.kernel.org > > Cc: linux-arm-ker...@lists.infradead.org > > Cc: net...@vger.kernel.org > > Cc: intel-wired-...@lists.osuosl.org > > Cc: linux-r...@vger.kernel.org > > Cc: alsa-de...@alsa-project.org > > Cc: kvm...@lists.cs.columbia.edu > > Acked-by: Jeff Kirsher > Tested-by: Aaron Brown > For the changes to the Intel drivers. > > > --- > > arch/microblaze/kernel/timer.c | 20 ++-- > > drivers/clocksource/arm_arch_timer.c | 19 ++-- > > drivers/net/ethernet/amd/xgbe/xgbe-dev.c | 3 +- > > drivers/net/ethernet/amd/xgbe/xgbe-ptp.c | 9 +++--- > > drivers/net/ethernet/amd/xgbe/xgbe.h | 1 - > > drivers/net/ethernet/broadcom/bnx2x/bnx2x.h| 1 - > > drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 20 ++-- > > drivers/net/ethernet/freescale/fec.h | 1 - > > drivers/net/ethernet/freescale/fec_ptp.c | 30 +--- > > -- > > drivers/net/ethernet/intel/e1000e/e1000.h | 1 - > > drivers/net/ethernet/intel/e1000e/netdev.c | 27 -- > > -- > > drivers/net/ethernet/intel/e1000e/ptp.c| 2 +- > > drivers/net/ethernet/intel/igb/igb.h | 1 - > > drivers/net/ethernet/intel/igb/igb_ptp.c | 25 -- > > - > > drivers/net/ethernet/intel/ixgbe/ixgbe.h | 1 - > > drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c | 17 +- > > drivers/net/ethernet/mellanox/mlx4/en_clock.c | 28 -- > > --- > > drivers/net/ethernet/mellanox/mlx4/mlx4_en.h | 1 - > > .../net/ethernet/mellanox/mlx5/core/lib/clock.c| 34 ++ > > -- > > drivers/net/ethernet/qlogic/qede/qede_ptp.c| 20 ++-- > > drivers/net/ethernet/ti/cpts.c | 36 > > -- > > drivers/net/ethernet/ti/cpts.h | 1 - > > include/linux/mlx5/driver.h| 1 - > > include/linux/timecounter.h| 4 +-- > > include/sound/hdaudio.h| 1 - > > kernel/time/timecounter.c | 28 -- > > --- > > sound/hda/hdac_stream.c| 7 +++-- > > virt/kvm/arm/arch_timer.c | 6 ++-- > > 28 files changed, 163 insertions(+), 182 deletions(-)
RE: [Intel-wired-lan] [PATCH 20/27] e1000e: Use timecounter_reset interface
> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On > Behalf Of Sagar Arun Kamble > Sent: Thursday, December 14, 2017 11:39 PM > To: linux-kernel@vger.kernel.org > Cc: intel-wired-...@lists.osuosl.org; Richard Cochran > ; Kamble, Sagar A > ; net...@vger.kernel.org > Subject: [Intel-wired-lan] [PATCH 20/27] e1000e: Use timecounter_reset > interface > > With new interface timecounter_reset we can update the start time for > timecounter. Update e1000e_phc_settime with this new function. > > Signed-off-by: Sagar Arun Kamble > Cc: Richard Cochran > Cc: Jeff Kirsher > Cc: intel-wired-...@lists.osuosl.org > Cc: net...@vger.kernel.org > Cc: linux-kernel@vger.kernel.org > --- > drivers/net/ethernet/intel/e1000e/ptp.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > Tested-by: Aaron Brown
RE: [Intel-wired-lan] [PATCH 08/27] e1000e: Use timecounter_initialize interface
> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On > Behalf Of Sagar Arun Kamble > Sent: Thursday, December 14, 2017 11:38 PM > To: linux-kernel@vger.kernel.org > Cc: intel-wired-...@lists.osuosl.org; Richard Cochran > ; Kamble, Sagar A > ; net...@vger.kernel.org > Subject: [Intel-wired-lan] [PATCH 08/27] e1000e: Use timecounter_initialize > interface > > With new interface timecounter_initialize we can initialize timecounter > fields and underlying cyclecounter together. Update e1000e timecounter > init with this new function. > > Signed-off-by: Sagar Arun Kamble > Cc: Richard Cochran > Cc: Jeff Kirsher > Cc: intel-wired-...@lists.osuosl.org > Cc: net...@vger.kernel.org > Cc: linux-kernel@vger.kernel.org > --- > drivers/net/ethernet/intel/e1000e/e1000.h | 4 > drivers/net/ethernet/intel/e1000e/netdev.c | 31 +- > > 2 files changed, 22 insertions(+), 13 deletions(-) > Tested-by: Aaron Brown
RE: [Intel-wired-lan] [PATCH 21/27] igb: Use timecounter_reset interface
> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On > Behalf Of Sagar Arun Kamble > Sent: Thursday, December 14, 2017 11:39 PM > To: linux-kernel@vger.kernel.org > Cc: intel-wired-...@lists.osuosl.org; Richard Cochran > ; Kamble, Sagar A > ; net...@vger.kernel.org > Subject: [Intel-wired-lan] [PATCH 21/27] igb: Use timecounter_reset > interface > > With new interface timecounter_reset we can update the start time for > timecounter. Update igb_ptp_settime_82576 with this new function. > > Signed-off-by: Sagar Arun Kamble > Cc: Richard Cochran > Cc: Jeff Kirsher > Cc: intel-wired-...@lists.osuosl.org > Cc: net...@vger.kernel.org > Cc: linux-kernel@vger.kernel.org > --- > drivers/net/ethernet/intel/igb/igb_ptp.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > Tested-by: Aaron Brown
RE: [Intel-wired-lan] [PATCH 22/27] ixgbe: Use timecounter_reset interface
> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On > Behalf Of Sagar Arun Kamble > Sent: Thursday, December 14, 2017 11:39 PM > To: linux-kernel@vger.kernel.org > Cc: intel-wired-...@lists.osuosl.org; Richard Cochran > ; Kamble, Sagar A > ; net...@vger.kernel.org > Subject: [Intel-wired-lan] [PATCH 22/27] ixgbe: Use timecounter_reset > interface > > With new interface timecounter_reset we can update the start time for > timecounter. Update ixgbe_ptp_settime with this new function. > > Signed-off-by: Sagar Arun Kamble > Cc: Richard Cochran > Cc: Jeff Kirsher > Cc: intel-wired-...@lists.osuosl.org > Cc: net...@vger.kernel.org > Cc: linux-kernel@vger.kernel.org > --- > drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > Tested-by: Aaron Brown
RE: [Intel-wired-lan] [PATCH 22/27] ixgbe: Use timecounter_reset interface
> -Original Message- > From: Brown, Aaron F > Sent: Friday, January 5, 2018 8:34 PM > To: 'Sagar Arun Kamble' ; linux- > ker...@vger.kernel.org > Cc: intel-wired-...@lists.osuosl.org; Richard Cochran > ; Kamble, Sagar A > ; net...@vger.kernel.org > Subject: RE: [Intel-wired-lan] [PATCH 22/27] ixgbe: Use timecounter_reset > interface > > > From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On > > Behalf Of Sagar Arun Kamble > > Sent: Thursday, December 14, 2017 11:39 PM > > To: linux-kernel@vger.kernel.org > > Cc: intel-wired-...@lists.osuosl.org; Richard Cochran > > ; Kamble, Sagar A > > ; net...@vger.kernel.org > > Subject: [Intel-wired-lan] [PATCH 22/27] ixgbe: Use timecounter_reset > > interface > > > > With new interface timecounter_reset we can update the start time for > > timecounter. Update ixgbe_ptp_settime with this new function. > > > > Signed-off-by: Sagar Arun Kamble > > Cc: Richard Cochran > > Cc: Jeff Kirsher > > Cc: intel-wired-...@lists.osuosl.org > > Cc: net...@vger.kernel.org > > Cc: linux-kernel@vger.kernel.org > > --- > > drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > Tested-by: Aaron Brown Strike my Tested-by: for this (ixgbe) instance. It was meant for igb.
RE: [Intel-wired-lan] [PATCH 09/27] igb: Use timecounter_initialize interface
> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On > Behalf Of Sagar Arun Kamble > Sent: Thursday, December 14, 2017 11:38 PM > To: linux-kernel@vger.kernel.org > Cc: intel-wired-...@lists.osuosl.org; Richard Cochran > ; Kamble, Sagar A > ; net...@vger.kernel.org > Subject: [Intel-wired-lan] [PATCH 09/27] igb: Use timecounter_initialize > interface > > With new interface timecounter_initialize we can initialize timecounter > fields and underlying cyclecounter together. Update igb ptp timecounter > init with this new function. > > Signed-off-by: Sagar Arun Kamble > Cc: Richard Cochran > Cc: Jeff Kirsher > Cc: intel-wired-...@lists.osuosl.org > Cc: net...@vger.kernel.org > Cc: linux-kernel@vger.kernel.org > --- > drivers/net/ethernet/intel/igb/igb.h | 4 > drivers/net/ethernet/intel/igb/igb_ptp.c | 23 ++- > 2 files changed, 18 insertions(+), 9 deletions(-) > Tested-by: Aaron Brown
RE: [Intel-wired-lan] [PATCH 01/27] timecounter: Make cyclecounter struct part of timecounter struct
> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On > Behalf Of Sagar Arun Kamble > Sent: Thursday, December 14, 2017 11:38 PM > To: linux-kernel@vger.kernel.org > Cc: alsa-de...@alsa-project.org; linux-r...@vger.kernel.org; > net...@vger.kernel.org; Richard Cochran ; > Stephen Boyd ; Chris Wilson wilson.co.uk>; John Stultz ; intel-wired- > l...@lists.osuosl.org; Thomas Gleixner ; Kamble, Sagar A > ; kvm...@lists.cs.columbia.edu; linux-arm- > ker...@lists.infradead.org > Subject: [Intel-wired-lan] [PATCH 01/27] timecounter: Make cyclecounter > struct part of timecounter struct > > There is no real need for the users of timecounters to define cyclecounter > and timecounter variables separately. Since timecounter will always be > based on cyclecounter, have cyclecounter struct as member of timecounter > struct. > > v2: Rebase. > > Suggested-by: Chris Wilson > Signed-off-by: Sagar Arun Kamble > Cc: Chris Wilson > Cc: Richard Cochran > Cc: John Stultz > Cc: Thomas Gleixner > Cc: Stephen Boyd > Cc: linux-kernel@vger.kernel.org > Cc: linux-arm-ker...@lists.infradead.org > Cc: net...@vger.kernel.org > Cc: intel-wired-...@lists.osuosl.org > Cc: linux-r...@vger.kernel.org > Cc: alsa-de...@alsa-project.org > Cc: kvm...@lists.cs.columbia.edu > Acked-by: Jeff Kirsher (Intel drivers) > --- > arch/microblaze/kernel/timer.c | 20 ++-- > drivers/clocksource/arm_arch_timer.c | 19 ++-- > drivers/net/ethernet/amd/xgbe/xgbe-dev.c | 3 +- > drivers/net/ethernet/amd/xgbe/xgbe-ptp.c | 9 +++--- > drivers/net/ethernet/amd/xgbe/xgbe.h | 1 - > drivers/net/ethernet/broadcom/bnx2x/bnx2x.h| 1 - > drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 20 ++-- > drivers/net/ethernet/freescale/fec.h | 1 - > drivers/net/ethernet/freescale/fec_ptp.c | 30 +- > drivers/net/ethernet/intel/e1000e/e1000.h | 1 - > drivers/net/ethernet/intel/e1000e/netdev.c | 27 > drivers/net/ethernet/intel/e1000e/ptp.c| 2 +- > drivers/net/ethernet/intel/igb/igb.h | 1 - > drivers/net/ethernet/intel/igb/igb_ptp.c | 25 --- > drivers/net/ethernet/intel/ixgbe/ixgbe.h | 1 - > drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c | 17 +- > drivers/net/ethernet/mellanox/mlx4/en_clock.c | 28 - > drivers/net/ethernet/mellanox/mlx4/mlx4_en.h | 1 - > .../net/ethernet/mellanox/mlx5/core/lib/clock.c| 34 ++-- > drivers/net/ethernet/qlogic/qede/qede_ptp.c| 20 ++-- > drivers/net/ethernet/ti/cpts.c | 36 > -- > drivers/net/ethernet/ti/cpts.h | 1 - > include/linux/mlx5/driver.h| 1 - > include/linux/timecounter.h| 4 +-- > include/sound/hdaudio.h| 1 - > kernel/time/timecounter.c | 28 - > sound/hda/hdac_stream.c| 7 +++-- > virt/kvm/arm/arch_timer.c | 6 ++-- > 28 files changed, 163 insertions(+), 182 deletions(-) > For Intel e1000e and igb drivers: Tested-by: Aaron Brown
RE: [Intel-wired-lan] [PATCH 1/2] Revert "e1000e: Separate signaling for link check/link up"
> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On
> Behalf Of Benjamin Poirier
> Sent: Monday, March 5, 2018 5:56 PM
> To: Kirsher, Jeffrey T
> Cc: net...@vger.kernel.org; intel-wired-...@lists.osuosl.org; linux-
> ker...@vger.kernel.org; Lennart Sorensen
> Subject: [Intel-wired-lan] [PATCH 1/2] Revert "e1000e: Separate signaling for
> link check/link up"
>
> This reverts commit 19110cfbb34d4af0cdfe14cd243f3b09dc95b013.
> This reverts commit 4110e02eb45ea447ec6f5459c9934de0a273fb91.
> This reverts commit d3604515c9eda464a92e8e67aae82dfe07fe3c98.
>
> Commit 19110cfbb34d ("e1000e: Separate signaling for link check/link up")
> changed what happens to the link status when there is an error which
> happens after "get_link_status = false" in the copper check_for_link
> callbacks. Previously, such an error would be ignored and the link
> considered up. After that commit, any error implies that the link is down.
>
> Revert commit 19110cfbb34d ("e1000e: Separate signaling for link check/link
> up") and its followups. After reverting, the race condition described in
> the log of commit 19110cfbb34d is reintroduced. It may still be triggered
> by LSC events but this should keep the link down in case the link is
> electrically unstable, as discussed. The race may no longer be
> triggered by RXO events because commit 4aea7a5c5e94 ("e1000e: Avoid
> receiver overrun interrupt bursts") restored reading icr in the Other
> handler.
>
> Link: https://lkml.org/lkml/2018/3/1/789
> Signed-off-by: Benjamin Poirier
> ---
> drivers/net/ethernet/intel/e1000e/ich8lan.c | 13 -
> drivers/net/ethernet/intel/e1000e/mac.c | 13 -
> drivers/net/ethernet/intel/e1000e/netdev.c | 2 +-
> 3 files changed, 9 insertions(+), 19 deletions(-)
>
Tested-by: Aaron Brown
RE: [PATCH 2/2] e1000e: Fix link check race condition
> From: netdev-ow...@vger.kernel.org [mailto:netdev- > ow...@vger.kernel.org] On Behalf Of Benjamin Poirier > Sent: Monday, March 5, 2018 5:56 PM > To: Kirsher, Jeffrey T > Cc: Alexander Duyck ; Lennart Sorensen > ; intel-wired-...@lists.osuosl.org; > net...@vger.kernel.org; linux-kernel@vger.kernel.org > Subject: [PATCH 2/2] e1000e: Fix link check race condition > > Alex reported the following race condition: > > /* link goes up... interrupt... schedule watchdog */ > \ e1000_watchdog_task > \ e1000e_has_link > \ hw->mac.ops.check_for_link() === > e1000e_check_for_copper_link > \ e1000e_phy_has_link_generic(..., &link) > link = true > >/* link goes down... interrupt */ >\ e1000_msix_other >hw->mac.get_link_status = > true > > /* link is up */ > mac->get_link_status = false > > link_active = true > /* link_active is true, wrongly, and stays so because >* get_link_status is false */ > > Avoid this problem by making sure that we don't set get_link_status = false > after having checked the link. > > It seems this problem has been present since the introduction of e1000e. > > Link: https://lkml.org/lkml/2018/1/29/338 > Reported-by: Alexander Duyck > Signed-off-by: Benjamin Poirier > --- > drivers/net/ethernet/intel/e1000e/ich8lan.c | 31 --- > -- > drivers/net/ethernet/intel/e1000e/mac.c | 14 ++--- > 2 files changed, 24 insertions(+), 21 deletions(-) Tested-by: Aaron Brown
RE: [Intel-wired-lan] [PATCH] igb: Fix an issue that PME is not enabled during runtime suspend
> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On
> Behalf Of Kai-Heng Feng
> Sent: Sunday, December 2, 2018 9:55 PM
> To: Kirsher, Jeffrey T
> Cc: net...@vger.kernel.org; Kai-Heng Feng
> ; intel-wired-...@lists.osuosl.org;
> da...@davemloft.net; linux-kernel@vger.kernel.org
> Subject: [Intel-wired-lan] [PATCH] igb: Fix an issue that PME is not enabled
> during runtime suspend
>
> I210 ethernet card doesn't wakeup when a cable gets plugged. It's
> because its PME is not set.
>
> Since commit 42eca2302146 ("PCI: Don't touch card regs after runtime
> suspend D3"), if the PCI state is saved, pci_pm_runtime_suspend() stops
> calling pci_finish_runtime_suspend(), which enables the PCI PME.
>
> To fix the issue, let's not to save PCI states when it's runtime
> suspend, to let the PCI subsytem enables PME.
>
> Fixes: 42eca2302146 ("PCI: Don't touch card regs after runtime suspend D3")
> Signed-off-by: Kai-Heng Feng
> ---
> drivers/net/ethernet/intel/igb/igb_main.c | 8 +---
> 1 file changed, 5 insertions(+), 3 deletions(-)
Tested-by: Aaron Brown
RE: [PATCH 1/2] e1000e: Exclude device from suspend direct complete optimization
> From: netdev-ow...@vger.kernel.org [mailto:netdev- > ow...@vger.kernel.org] On Behalf Of Kai-Heng Feng > Sent: Tuesday, December 11, 2018 12:00 AM > To: Kirsher, Jeffrey T > Cc: da...@davemloft.net; intel-wired-...@lists.osuosl.org; > net...@vger.kernel.org; linux-kernel@vger.kernel.org; Kai-Heng Feng > > Subject: [PATCH 1/2] e1000e: Exclude device from suspend direct complete > optimization > > e1000e sets different WoL settings in system suspend callback and > runtime suspend callback. > > The suspend direct complete optimization leaves e1000e in runtime > suspneded state with wrong WoL setting during system suspend. > > To fix this, we need to disable suspend direct complete optimization to > let e1000e always use suspend callback to set correct WoL during system > suspend. > > Signed-off-by: Kai-Heng Feng > --- > drivers/net/ethernet/intel/e1000e/netdev.c | 2 ++ > 1 file changed, 2 insertions(+) > Tested-by: Aaron Brown
RE: [Intel-wired-lan] [PATCH] e1000e: Ignore TSYNCRXCTL when getting I219 clock attributes
> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On
> Behalf Of Benjamin Poirier
> Sent: Thursday, May 10, 2018 12:29 AM
> To: Kirsher, Jeffrey T
> Cc: ehabk...@redhat.com; net...@vger.kernel.org; jaya...@goubiq.com;
> linux-kernel@vger.kernel.org; bart.vanass...@wdc.com;
> postmodern.m...@gmail.com; Achim Mildenberger
> ; intel-wired-...@lists.osuosl.org;
> olouvig...@gmail.com
> Subject: [Intel-wired-lan] [PATCH] e1000e: Ignore TSYNCRXCTL when getting
> I219 clock attributes
>
> There have been multiple reports of crashes that look like
> kernel: RIP: 0010:[] timecounter_read+0xf/0x50
> [...]
> kernel: Call Trace:
> kernel: [] e1000e_phc_gettime+0x2f/0x60 [e1000e]
> kernel: [] e1000e_systim_overflow_work+0x1d/0x80
> [e1000e]
> kernel: [] process_one_work+0x155/0x440
> kernel: [] worker_thread+0x116/0x4b0
> kernel: [] kthread+0xd2/0xf0
> kernel: [] ret_from_fork+0x3f/0x70
>
> These can be traced back to the fact that e1000e_systim_reset() skips the
> timecounter_init() call if e1000e_get_base_timinca() returns -EINVAL, which
> leads to a null deref in timecounter_read().
>
> Commit 83129b37ef35 ("e1000e: fix systim issues", v4.2-rc1) reworked
> e1000e_get_base_timinca() in such a way that it can return -EINVAL for
> e1000_pch_spt if the SYSCFI bit is not set in TSYNCRXCTL.
>
> Some experimentation has shown that on I219 (e1000_pch_spt, "MAC: 12")
> adapters, the E1000_TSYNCRXCTL_SYSCFI flag is unstable; TSYNCRXCTL reads
> sometimes don't have the SYSCFI bit set. Retrying the read shortly after
> finds the bit to be set. This was observed at boot (probe) but also link up
> and link down.
>
> Moreover, the phc (PTP Hardware Clock) seems to operate normally even
> after
> reads where SYSCFI=0. Therefore, remove this register read and
> unconditionally set the clock parameters.
>
> Reported-by: Achim Mildenberger
> Message-Id: <20180425065243.g5mqewg5irkwgwgv@f2>
> Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=1075876
> Fixes: 83129b37ef35 ("e1000e: fix systim issues")
> Signed-off-by: Benjamin Poirier
> ---
> drivers/net/ethernet/intel/e1000e/netdev.c | 15 ++-
> 1 file changed, 6 insertions(+), 9 deletions(-)
Tested-by: Aaron Brown
RE: [Intel-wired-lan] [PATCH] [net-next] e1000e: fix unused-function warning
> From: Intel-wired-lan On Behalf Of Arnd
> Bergmann
> Sent: Wednesday, May 27, 2020 6:47 AM
> To: Kirsher, Jeffrey T ; David S. Miller
> ; Jakub Kicinski ; Lifshits, Vitaly
>
> Cc: Arnd Bergmann ; Konstantin Khlebnikov
> ; net...@vger.kernel.org; Wysocki, Rafael J
> ; linux-kernel@vger.kernel.org; intel-wired-
> l...@lists.osuosl.org; Alexander Duyck
> Subject: [Intel-wired-lan] [PATCH] [net-next] e1000e: fix unused-function
> warning
>
> The CONFIG_PM_SLEEP #ifdef checks in this file are inconsistent,
> leading to a warning about sometimes unused function:
>
> drivers/net/ethernet/intel/e1000e/netdev.c:137:13: error: unused function
> 'e1000e_check_me' [-Werror,-Wunused-function]
>
> Rather than adding more #ifdefs, just remove them completely
> and mark the PM functions as __maybe_unused to let the compiler
> work it out on it own.
>
> Fixes: e086ba2fccda ("e1000e: disable s0ix entry and exit flows for ME
> systems")
> Signed-off-by: Arnd Bergmann
> ---
> drivers/net/ethernet/intel/e1000e/netdev.c | 16 +---
> 1 file changed, 5 insertions(+), 11 deletions(-)
>
Tested-by: Aaron Brown
RE: [PATCH v2] e1000: use generic power management
> From: Vaibhav Gupta > Sent: Monday, May 25, 2020 5:27 AM > To: Vaibhav Gupta ; Bjorn Helgaas > ; Bjorn Helgaas ; > bj...@helgaas.com; Kirsher, Jeffrey T ; David S. > Miller ; r...@rjwysocki.net > Cc: Vaibhav Gupta ; Brandeburg, Jesse > ; intel-wired-...@lists.osuosl.org; > net...@vger.kernel.org; linux-kernel@vger.kernel.org; linux-kernel- > ment...@lists.linuxfoundation.org; sk...@linuxfoundation.org > Subject: [PATCH v2] e1000: use generic power management > > compile-tested only > > With legacy PM hooks, it was the responsibility of a driver to manage PCI > states and also the device's power state. The generic approach is to let PCI > core handle the work. > > e1000_suspend() calls __e1000_shutdown() to perform intermediate tasks. > __e1000_shutdown() modifies the value of "wake" (device should be wakeup > enabled or not), responsible for controlling the flow of legacy PM. > > Since, PCI core has no idea about the value of "wake", new code for generic > PM may produce unexpected results. Thus, use "device_set_wakeup_enable()" > to wakeup-enable the device accordingly. > > Signed-off-by: Vaibhav Gupta > --- > drivers/net/ethernet/intel/e1000/e1000_main.c | 49 +-- > 1 file changed, 13 insertions(+), 36 deletions(-) I don't have many old PCI systems that handle power management properly before adding this patch. However, the few ones that do continue to do so with the older e1000 parts I still have around. So a small sample, but at least confirmed on _some_ real hardware Tested-by: Aaron Brown
RE: [PATCH] igb: use eth_zero_addr() to clear mac address
> From: linmiaohe > Sent: Monday, July 20, 2020 1:29 AM > To: Kirsher, Jeffrey T ; da...@davemloft.net; > k...@kernel.org > Cc: intel-wired-...@lists.osuosl.org; net...@vger.kernel.org; linux- > ker...@vger.kernel.org; linmia...@huawei.com > Subject: [PATCH] igb: use eth_zero_addr() to clear mac address > > From: Miaohe Lin > > Use eth_zero_addr() to clear mac address insetad of memset(). > > Signed-off-by: Miaohe Lin > --- > drivers/net/ethernet/intel/igb/igb_main.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) Tested-by: Aaron Brown
RE: [PATCH] e1000e: Disable TSO for buffer overrun workaround
> From: netdev-ow...@vger.kernel.org On
> Behalf Of Kai-Heng Feng
> Sent: Thursday, May 7, 2020 7:21 AM
> To: Kirsher, Jeffrey T
> Cc: Kai-Heng Feng ; David S. Miller
> ; Neftin, Sasha ; Dima
> Ruinskiy ; Avargil, Raanan
> ; moderated list:INTEL ETHERNET DRIVERS wired-...@lists.osuosl.org>; open list:NETWORKING DRIVERS
> ; open list
> Subject: [PATCH] e1000e: Disable TSO for buffer overrun workaround
>
> Commit b10effb92e27 ("e1000e: fix buffer overrun while the I219 is
> processing DMA transactions") imposes roughly 30% performance penalty.
>
> The commit log states that "Disabling TSO eliminates performance loss
> for TCP traffic without a noticeable impact on CPU performance", so
> let's disable TSO by default to regain the loss.
>
> Fixes: b10effb92e27 ("e1000e: fix buffer overrun while the I219 is processing
> DMA transactions")
> BugLink: https://bugs.launchpad.net/bugs/1802691
> Signed-off-by: Kai-Heng Feng
> ---
> drivers/net/ethernet/intel/e1000e/netdev.c | 4
> 1 file changed, 4 insertions(+)
Tested-by: Aaron Brown
RE: [PATCH net-next] igb: make igb_set_fc_watermarks() return void
> From: netdev-ow...@vger.kernel.org On > Behalf Of Jason Yan > Sent: Thursday, May 7, 2020 4:09 AM > To: Kirsher, Jeffrey T ; da...@davemloft.net; > yanai...@huawei.com; intel-wired-...@lists.osuosl.org; > net...@vger.kernel.org; linux-kernel@vger.kernel.org > Subject: [PATCH net-next] igb: make igb_set_fc_watermarks() return void > > This function always return 0 now, we can make it return void to > simplify the code. This fixes the following coccicheck warning: > > drivers/net/ethernet/intel/igb/e1000_mac.c:728:5-12: Unneeded variable: > "ret_val". Return "0" on line 751 > > Signed-off-by: Jason Yan > --- > drivers/net/ethernet/intel/igb/e1000_mac.c | 9 +++-- > 1 file changed, 3 insertions(+), 6 deletions(-) > Tested-by: Aaron Brown
RE: [PATCH] e1000e: Relax condition to trigger reset for ME workaround
> From: netdev-ow...@vger.kernel.org On > Behalf Of Punit Agrawal > Sent: Thursday, May 14, 2020 9:31 PM > To: Kirsher, Jeffrey T > Cc: daniel.sangor...@toshiba.co.jp; Punit Agrawal > ; Alexander Duyck > ; David S. Miller ; > intel-wired-...@lists.osuosl.org; net...@vger.kernel.org; linux- > ker...@vger.kernel.org > Subject: [PATCH] e1000e: Relax condition to trigger reset for ME workaround > > It's an error if the value of the RX/TX tail descriptor does not match > what was written. The error condition is true regardless the duration > of the interference from ME. But the driver only performs the reset if > E1000_ICH_FWSM_PCIM2PCI_COUNT (2000) iterations of 50us delay have > transpired. The extra condition can lead to inconsistency between the > state of hardware as expected by the driver. > > Fix this by dropping the check for number of delay iterations. > > While at it, also make __ew32_prepare() static as it's not used > anywhere else. > > Signed-off-by: Punit Agrawal > Reviewed-by: Alexander Duyck > Cc: Jeff Kirsher > Cc: "David S. Miller" > Cc: intel-wired-...@lists.osuosl.org > Cc: net...@vger.kernel.org > Cc: linux-kernel@vger.kernel.org > --- > Hi Jeff, > > If there are no further comments please consider merging the patch. > > Also, should it be marked for backport to stable? > > Thanks, > Punit > > RFC[0] -> v1: > * Dropped return value for __ew32_prepare() as it's not used > * Made __ew32_prepare() static > * Added tags > > [0] https://lkml.org/lkml/2020/5/12/20 > > drivers/net/ethernet/intel/e1000e/e1000.h | 1 - > drivers/net/ethernet/intel/e1000e/netdev.c | 12 +--- > 2 files changed, 5 insertions(+), 8 deletions(-) > Tested-by: Aaron Brown
Re: [PATCH] ixgbevf: delete unneeded call to pci_set_power_state
On Tue, 2014-01-07 at 18:00 +0100, Julia Lawall wrote:
> From: Julia Lawall
>
> This driver does not need to adjust the power state on suspend, so the
> call to pci_set_power_state in the resume function is a no-op. Drop it, to
> make the code more understandable.
>
> Signed-off-by: Julia Lawall
Tested-by: Phil Schmitt
Signed-off-by: Aaron Brown
> ---
> drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c |1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
> b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
> index a5d3167..5709fb0 100644
> --- a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
> +++ b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
> @@ -3226,7 +3226,6 @@ static int ixgbevf_resume(struct pci_dev *pdev)
> struct net_device *netdev = adapter->netdev;
> u32 err;
>
> - pci_set_power_state(pdev, PCI_D0);
> pci_restore_state(pdev);
> /*
>* pci_restore_state clears dev->state_saved so call
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
Re: [PATCH] [trivial] ixgbe: Fix format string in ixgbe_fcoe.c
On Wed, 2014-01-15 at 01:14 +0900, Masanari Iida wrote:
> cppcheck detected following warning in ixgbe_fcoe.c
> (warning) %d in format string (no. 1) requires 'int' but the
> argument type is 'unsigned int'.
>
> Signed-off-by: Masanari Iida
Tested-By: Jack Morgan
Signed-off-by: Aaron Brown
> ---
> drivers/net/ethernet/intel/ixgbe/ixgbe_fcoe.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_fcoe.c
> b/drivers/net/ethernet/intel/ixgbe/ixgbe_fcoe.c
> index f58db45..0872617 100644
> --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_fcoe.c
> +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_fcoe.c
> @@ -585,7 +585,7 @@ static int ixgbe_fcoe_dma_pool_alloc(struct ixgbe_fcoe
> *fcoe,
> struct dma_pool *pool;
> char pool_name[32];
>
> - snprintf(pool_name, 32, "ixgbe_fcoe_ddp_%d", cpu);
> + snprintf(pool_name, 32, "ixgbe_fcoe_ddp_%u", cpu);
>
> pool = dma_pool_create(pool_name, dev, IXGBE_FCPTR_MAX,
> IXGBE_FCPTR_ALIGN, PAGE_SIZE);
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
RE: [PATCH net-next v2 06/20] net: igbvf: slight optimization of addr compare
> From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org]
> On Behalf Of Ding Tianhong
> Sent: Friday, December 27, 2013 10:17 PM
> To: Kirsher, Jeffrey T; Brandeburg, Jesse; Wyborny, Carolyn; Skidmore,
> Donald C; David S. Miller; Netdev; linux-kernel@vger.kernel.org
> Subject: [PATCH net-next v2 06/20] net: igbvf: slight optimization of addr
> compare
>
> Use possibly more efficient ether_addr_equal to instead of memcmp.
>
> Cc: Jeff Kirsher
> Cc: Jesse Brandeburg
> Cc: Carolyn Wyborny
> Cc: Don Skidmore
> Signed-off-by: Ding Tianhong
Signed-off-by: Aaron Brown
Tested by: Aaron Brown
> ---
> drivers/net/ethernet/intel/igbvf/netdev.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/intel/igbvf/netdev.c
> b/drivers/net/ethernet/intel/igbvf/netdev.c
> index 04bf22e..675435f 100644
> --- a/drivers/net/ethernet/intel/igbvf/netdev.c
> +++ b/drivers/net/ethernet/intel/igbvf/netdev.c
> @@ -1745,7 +1745,7 @@ static int igbvf_set_mac(struct net_device *netdev,
> void *p)
>
> hw->mac.ops.rar_set(hw, hw->mac.addr, 0);
>
> - if (memcmp(addr->sa_data, hw->mac.addr, 6))
> + if (!ether_addr_equal(addr->sa_data, hw->mac.addr))
> return -EADDRNOTAVAIL;
>
> memcpy(netdev->dev_addr, addr->sa_data, netdev->addr_len);
> --
> 1.8.0
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
RE: [PATCH] e1000: avoid potential deadlock in e1000_do_[read|write]_eeprom()
> From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org] > On Behalf Of Alexey Khoroshilov > Sent: Friday, December 20, 2013 2:25 PM > To: Kirsher, Jeffrey T > Cc: Alexey Khoroshilov; Brandeburg, Jesse; Allan, Bruce W; Wyborny, > Carolyn; Skidmore, Donald C; Rose, Gregory V; Duyck, Alexander H; Ronciak, > John; e1000-de...@lists.sourceforge.net; net...@vger.kernel.org; linux- > ker...@vger.kernel.org; ldv-proj...@linuxtesting.org > Subject: [PATCH] e1000: avoid potential deadlock in > e1000_do_[read|write]_eeprom() > > If eeprom->word_size is zero, e1000_do_[read|write]_eeprom() invoke > e1000_init_eeprom_params() to reinit eeprom params. > That is not a good idea since e1000_init_eeprom_params() calls > e1000_read_eeprom() if eeprom->type is e1000_eeprom_spi. > That means a deadlock on e1000_eeprom_lock. > > At the same time it is unclear if the reinit is needed at all. > e1000_init_eeprom_params() is called from probe, so it should succeed > before any activities of the module start. > > The patch suggests to remove the try to reinit eeprom params. > > Found by Linux Driver Verification project (linuxtesting.org). > > Signed-off-by: Alexey Khoroshilov Signed-off-by: Aaron Brown Tested by: Aaron Brown > --- > drivers/net/ethernet/intel/e1000/e1000_hw.c | 8 > 1 file changed, 8 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [trivial] ixgbe: Fix format string in ixgbe_fcoe.c
On Wed, 2014-01-15 at 01:14 +0900, Masanari Iida wrote:
> cppcheck detected following warning in ixgbe_fcoe.c
> (warning) %d in format string (no. 1) requires 'int' but the
> argument type is 'unsigned int'.
>
> Signed-off-by: Masanari Iida
> ---
> drivers/net/ethernet/intel/ixgbe/ixgbe_fcoe.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Thanks Masanari, I have added it to our internal queue for testing.
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
Re: [PATCH 1/2 v2] ixgbe: define IXGBE_MAX_VFS_DRV_LIMIT macro and cleanup const 63
On Fri, 2013-12-27 at 01:02 -0800, Jeff Kirsher wrote: > On Wed, 2013-12-25 at 00:12 +0800, Ethan Zhao wrote: > > Because ixgbe driver limit the max number of VF functions could be > > enabled > > to 63, so define one macro IXGBE_MAX_VFS_DRV_LIMIT and cleanup the > > const 63 > > in code. > > > > v2: fix a typo. > > > > Signed-off-by: Ethan Zhao > > --- > > drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 4 ++-- > > drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c | 5 +++-- > > drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.h | 5 + > > 3 files changed, 10 insertions(+), 4 deletions(-) > > Added to my queue, thanks Ethan! Hi Ethan, Did Jeff contact you about this failing to compile? I'm currently providing vacation covering for him and we found this was failing to compile just before he left. We captured the failure in our notes for this but there is no comment on if you were contacted or not. Regardless, when I apply this patch (with or without 2-2) we get the following error on a compilation attempt: Here's the error: Here's the error: drivers/net/ethernet/intel/ixgbe/ixgbe_main.c: In function "ixgbe_sw_init": drivers/net/ethernet/intel/ixgbe/ixgbe_main.c:5033: error: stray "\357" in program drivers/net/ethernet/intel/ixgbe/ixgbe_main.c:5033: error: stray "\274" in program drivers/net/ethernet/intel/ixgbe/ixgbe_main.c:5033: error: stray "\215" in program drivers/net/ethernet/intel/ixgbe/ixgbe_main.c:5033: error: expected ")" before numeric constant drivers/net/ethernet/intel/ixgbe/ixgbe_main.c: In function "ixgbe_probe": drivers/net/ethernet/intel/ixgbe/ixgbe_main.c:7977: error: stray "\357" in program drivers/net/ethernet/intel/ixgbe/ixgbe_main.c:7977: error: stray "\274" in program drivers/net/ethernet/intel/ixgbe/ixgbe_main.c:7977: error: stray "\215" in program drivers/net/ethernet/intel/ixgbe/ixgbe_main.c:7977: error: expected ")" before numeric constant make[5]: *** [drivers/net/ethernet/intel/ixgbe/ixgbe_main.o] Error 1 make[5]: *** Waiting for unfinished jobs make[4]: *** [drivers/net/ethernet/intel/ixgbe] Error 2 make[4]: *** Waiting for unfinished jobs make[3]: *** [drivers/net/ethernet/intel] Error 2 make[2]: *** [drivers/net/ethernet] Error 2 make[1]: *** [drivers/net] Error 2 make: *** [drivers] Error 2 Thanks, Aaron
Re: [PATCH 1/2 v3] ixgbe: define IXGBE_MAX_VFS_DRV_LIMIT macro and cleanup const 63
On Wed, 2014-01-15 at 22:12 +0800, Ethan Zhao wrote:
> Because ixgbe driver limit the max number of VF functions could be enabled
> to 63, so define one macro IXGBE_MAX_VFS_DRV_LIMIT and cleanup the const 63
> in code.
>
> v2: fix a typo.
> v3: fix a encoding issue.
>
> Signed-off-by: Ethan Zhao
> ---
> drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 4 ++--
> drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c | 5 +++--
> drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.h | 5 +
> 3 files changed, 10 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> index 0ade0cd..47e9b44 100644
> --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> @@ -4818,7 +4818,7 @@ static int ixgbe_sw_init(struct ixgbe_adapter *adapter)
> #ifdef CONFIG_PCI_IOV
> /* assign number of SR-IOV VFs */
> if (hw->mac.type != ixgbe_mac_82598EB)
> - adapter->num_vfs = (max_vfs > 63) ? 0 : max_vfs;
Unfortunately the if statement got changed considerably with a recent
commit:
commit 170e85430bcbe4d18e81b5a70bb163c741381092
ixgbe: add warning when max_vfs is out of range.
And the pattern no longer exists to make a match. In other words, this
patch no longer applies to net-next and I have to ask you for yet
another spin if you still want to squash the magic number.
Thanks,
Aaron
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
Re: [E1000-devel] [PATCH] net: ethernet: intel: ixgbe: ixgbe_main.c: Cleaning up missing null-terminate in conjunction with strncpy
On Tue, 2014-07-29 at 14:15 +0200, Rickard Strandqvist wrote: > Den 29 jul 2014 04:40 skrev "Stephen Hemminger" >: > > > > On Sat, 26 Jul 2014 16:24:36 +0200 > > Rickard Strandqvist wrote: > > > > > Replacing strncpy with strlcpy to avoid strings that lacks null > terminate. > > > > > > Signed-off-by: Rickard Strandqvist < > rickard_strandqv...@spectrumdigital.se> > > > --- > >hw->mac.type, hw->phy.type, hw->phy.sfp_type, > > > > This patch doesn't change anything. > > Netdev is already zeroed when allocated therefore doing strncpy() > guarantees > > it will be null terminated. > > Hi Stephen > > It's not clear that alloc_etherdev_mq() will zero the memory area: > Thanks Rickard, given strncpy to strlcpy gets suggested by static code generators this will probably come up again even if it results in no real change. I (covering for Jeff Kirsher) went ahead and added it to our internal tree.
Re: [PATCH 3/9] i40e: use correct structure type name in sizeof
On Tue, 2014-07-29 at 17:16 +0200, Julia Lawall wrote: > From: Julia Lawall > > Correct typo in the name of the type given to sizeof. Because it is the > size of a pointer that is wanted, the typo has no impact on compilation or > execution. > > This problem was found using Coccinelle (http://coccinelle.lip6.fr/). The > semantic patch used can be found in message 0 of this patch series. > > Signed-off-by: Julia Lawall > > --- > drivers/net/ethernet/intel/i40e/i40e_main.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Thanks Julia, I have added your patch to our (Jeff's) queue.
Re: [PATCH] [trivial] ixgbe: Fix format string in ixgbe_fcoe.c
On Wed, 2014-01-15 at 14:55 -0800, David Miller wrote:
> From: Masanari Iida
> Date: Wed, 15 Jan 2014 01:14:42 +0900
>
> > cppcheck detected following warning in ixgbe_fcoe.c
> > (warning) %d in format string (no. 1) requires 'int' but the
> > argument type is 'unsigned int'.
> >
> > Signed-off-by: Masanari Iida
>
> Intel folks, please be sure to pick this up.
Yup, already in our queue.
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
Re: [PATCH 1/2 v3] ixgbe: define IXGBE_MAX_VFS_DRV_LIMIT macro and cleanup const 63
On Thu, 2014-01-16 at 09:27 +0800, Ethan Zhao wrote: > On Thu, Jan 16, 2014 at 6:00 AM, Brown, Aaron F > wrote: > > On Wed, 2014-01-15 at 22:12 +0800, Ethan Zhao wrote: > >> Because ixgbe driver limit the max number of VF functions could be enabled > >> to 63, so define one macro IXGBE_MAX_VFS_DRV_LIMIT and cleanup the const 63 > >> in code. > >> > >> v2: fix a typo. > >> v3: fix a encoding issue. > >> > >> Signed-off-by: Ethan Zhao > >> --- > >> drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 4 ++-- > >> drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c | 5 +++-- > >> drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.h | 5 + > >> 3 files changed, 10 insertions(+), 4 deletions(-) > >> > >> diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c > >> b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c > >> index 0ade0cd..47e9b44 100644 > >> --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c > >> +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c > >> @@ -4818,7 +4818,7 @@ static int ixgbe_sw_init(struct ixgbe_adapter > >> *adapter) > >> #ifdef CONFIG_PCI_IOV > >> /* assign number of SR-IOV VFs */ > >> if (hw->mac.type != ixgbe_mac_82598EB) > >> - adapter->num_vfs = (max_vfs > 63) ? 0 : max_vfs; > > > > > > Unfortunately the if statement got changed considerably with a recent > > commit: > > > > commit 170e85430bcbe4d18e81b5a70bb163c741381092 > > ixgbe: add warning when max_vfs is out of range. > > > > And the pattern no longer exists to make a match. In other words, this > > patch no longer applies to net-next and I have to ask you for yet > > another spin if you still want to squash the magic number. > > It's not a good news. Our distro is waiting for this patch showing up in > stable. > OK, info me if there is a windows for me to revise the patch. I don't think any particular window of time is better than another. I don't see this change as needing very thorough testing so if you send in (yet) another version I'll try to get it through our internal process as rapidly as I can. > > Thanks, > Ethan > > > > > Thanks, > > Aaron
Re: [PATCH 1/2 v3] ixgbe: define IXGBE_MAX_VFS_DRV_LIMIT macro and cleanup const 63
On Thu, 2014-01-16 at 09:58 +0800, Ethan Zhao wrote: > Aaron, > > Is this your net-next repo ? if so, I rebuild the patch with this repo > right now . > git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-next.git > > Thanks, > Ethan > Only sort of. Jeff uses it to push patches up, but I don't have an account there so am simply sending them up the old fashioned way, via email, hence it is probably not getting updated while Jeff is out. As long as your patch can apply cleanly to Dave Miller's net-next tree I should be able to pull it into our internal ones.
RE: [PATCH] ixgbe: remove useless bd_number from adapter struct
> From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel- > ow...@vger.kernel.org] On Behalf Of Ethan Zhao > Sent: Monday, July 28, 2014 12:41 AM > To: Kirsher, Jeffrey T; Brandeburg, Jesse; Allan, Bruce W; Wyborny, > Carolyn; Skidmore, Donald C; Rose, Gregory V; Duyck, Alexander H; Ronciak, > John; Williams, Mitch A > Cc: Linux NICS; e1000-de...@lists.sourceforge.net; net...@vger.kernel.org; > linux-kernel@vger.kernel.org; ethan.ker...@gmail.com; Ethan Zhao > Subject: [PATCH] ixgbe: remove useless bd_number from adapter struct > > Because bd_number is not useful anymore, so remove it from adapter struct, > or > if keep it, we have to fix the boards driven counter bug in ixgbe_remove() > and > ixgbe_probe() only for trival debug purpose -- other output is enough. Thanks Ethan, I (briefly covering for Jeff Kirsher) have added this patch and your other one ofr ixgbevf to Jeff's internal tree. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [E1000-devel] [PATCH 0/2] Remove dead code
> From: Bjorn Helgaas [mailto:bhelg...@google.com] > Sent: Thursday, January 30, 2014 11:21 AM > To: linux-...@vger.kernel.org > Cc: e1000-de...@lists.sourceforge.net; Arjan van de Ven; linux- > ker...@vger.kernel.org > Subject: [E1000-devel] [PATCH 0/2] Remove dead code > > This is a rework of part of Stephen's patch [1]. > > This removes the MMIO exclusivity support that was added as part of an > e1000e bug hunt. > > The e1000e driver still uses pci_request_selected_regions_exclusive(), but > there are no callers of pci_request_region_exclusive() and > pci_request_regions_exclusive(). I thought it was cleaner to remove the > whole thing than to leave parts of it in place. But I could easily be > convinced to leave part or all of this in place if people think it's still > useful. Thanks Bjorn, I have added these to Jeff's queue. > > It also removes SR-IOV migration support, which is completely unused, as > far as I can tell. > > [1] > http://lkml.kernel.org/r/20131227132710.7190647c@nehalam.linuxnetplumber.n > et > > --- > > Bjorn Helgaas (2): > PCI: Remove unused MMIO exclusivity support > PCI: Remove unused SR-IOV VF Migration support > > > Documentation/PCI/pci-iov-howto.txt|4 - > Documentation/kernel-parameters.txt|4 - > arch/x86/mm/init.c |2 > drivers/net/ethernet/intel/e1000e/netdev.c |3 - > drivers/pci/iov.c | 119 --- > - > drivers/pci/pci-sysfs.c|3 - > drivers/pci/pci.c | 112 +++ > --- > drivers/pci/pci.h |4 - > include/linux/ioport.h |5 - > include/linux/pci.h|7 -- > kernel/resource.c | 54 - > 11 files changed, 14 insertions(+), 303 deletions(-) > > -- > > WatchGuard Dimension instantly turns raw network data into actionable > security intelligence. It gives you real-time visual feedback on key > security issues and trends. Skip the complicated setup - simply import a > virtual appliance and go from zero to informed in seconds. > http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clkt > rk > ___ > E1000-devel mailing list > e1000-de...@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/e1000-devel > To learn more about Intel® Ethernet, visit > http://communities.intel.com/community/wired -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [E1000-devel] [PATCH 0/2] Remove dead code
> From: Bjorn Helgaas [mailto:bhelg...@google.com]
> Sent: Friday, January 31, 2014 9:59 AM
> To: Brown, Aaron F
> Cc: linux-...@vger.kernel.org; e1000-de...@lists.sourceforge.net; Arjan
> van de Ven; linux-kernel@vger.kernel.org
> Subject: Re: [E1000-devel] [PATCH 0/2] Remove dead code
>
> On Fri, Jan 31, 2014 at 2:10 AM, Brown, Aaron F
> wrote:
> >> From: Bjorn Helgaas [mailto:bhelg...@google.com]
> >> Sent: Thursday, January 30, 2014 11:21 AM
> >> To: linux-...@vger.kernel.org
> >> Cc: e1000-de...@lists.sourceforge.net; Arjan van de Ven; linux-
> >> ker...@vger.kernel.org
> >> Subject: [E1000-devel] [PATCH 0/2] Remove dead code
> >>
> >> This is a rework of part of Stephen's patch [1].
> >>
> >> This removes the MMIO exclusivity support that was added as part of
> >> an e1000e bug hunt.
> >>
> >> The e1000e driver still uses
> >> pci_request_selected_regions_exclusive(), but there are no callers of
> >> pci_request_region_exclusive() and pci_request_regions_exclusive().
> >> I thought it was cleaner to remove the whole thing than to leave
> >> parts of it in place. But I could easily be convinced to leave part
> >> or all of this in place if people think it's still useful.
> >
> > Thanks Bjorn, I have added these to Jeff's queue.
>
> Let's wait for a bit more discussion on this.
>
> For one thing, Fengguang's autobuilder found a handful of issues,
> including a couple more users of the exclusive mappings. For another,
> Arjan reminded me that the e1000e bug hung was for a problem that bricked
> the device, requiring replacement of the part or significant effort to fix
> the EEPROM. I *suspect* this is a potential issue for many devices, but
> if the e1000e is particularly susceptible for some reason, we might want
> to keep the exclusive mappings for it.
>
> If you want to apply just the e1000e part that removes its use of
> pci_request_selected_regions_exclusive(), I would have no complaints about
> that, of course.
Yes, that was my main intent. I did pull them both in but the second was more
as a heads up to our virtualization guys then as a request to test.
> But we can't apply the whole thing as-is without at
> least fixing the build issues.
Thanks for the heads up on that. I'll sort out something that builds with the
e1000e parts removed on my end.
>
> >> It also removes SR-IOV migration support, which is completely unused,
> >> as far as I can tell.
> >>
> >> [1]
> >> http://lkml.kernel.org/r/20131227132710.7190647c@nehalam.linuxnetplum
> >> ber.n
> >> et
> >>
> >> ---
> >>
> >> Bjorn Helgaas (2):
> >> PCI: Remove unused MMIO exclusivity support
> >> PCI: Remove unused SR-IOV VF Migration support
> >>
> >>
> >> Documentation/PCI/pci-iov-howto.txt|4 -
> >> Documentation/kernel-parameters.txt|4 -
> >> arch/x86/mm/init.c |2
> >> drivers/net/ethernet/intel/e1000e/netdev.c |3 -
> >> drivers/pci/iov.c | 119
> ---
> >> -
> >> drivers/pci/pci-sysfs.c|3 -
> >> drivers/pci/pci.c | 112 +++-
> ---
> >> ---
> >> drivers/pci/pci.h |4 -
> >> include/linux/ioport.h |5 -
> >> include/linux/pci.h|7 --
> >> kernel/resource.c | 54 -
> >> 11 files changed, 14 insertions(+), 303 deletions(-)
> >>
> >> -
> >> -
> >>
> >> WatchGuard Dimension instantly turns raw network data into actionable
> >> security intelligence. It gives you real-time visual feedback on key
> >> security issues and trends. Skip the complicated setup - simply
> >> import a virtual appliance and go from zero to informed in seconds.
> >> http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg
> >> .clkt
> >> rk
> >> ___
> >> E1000-devel mailing list
> >> e1000-de...@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/e1000-devel
> >> To learn more about Intel® Ethernet, visit
> >> http://communities.intel.com/community/wired
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
RE: [Intel-wired-lan] [PATCH] e100: Release skb when DMA mapping is failed in e100_xmit_prepare
> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@lists.osuosl.org] On > Behalf Of Jia-Ju Bai > Sent: Sunday, August 02, 2015 7:41 PM > To: Kirsher, Jeffrey T; Brandeburg, Jesse > Cc: net...@vger.kernel.org; Jia-Ju Bai; intel-wired-...@lists.osuosl.org; > linux-kernel@vger.kernel.org > Subject: [Intel-wired-lan] [PATCH] e100: Release skb when DMA mapping is > failed in e100_xmit_prepare > > When pci_dma_mapping_error in e100_xmit_prepare is failed, the skb buffer > allocated by netdev_alloc_skb_ip_align in e100_rx_alloc_skb is not > released, which causes a possible resource leak. > This patch adds error handling code to fix it. > > Signed-off-by: Jia-Ju Bai > --- > drivers/net/ethernet/intel/e100.c |5 - > 1 file changed, 4 insertions(+), 1 deletion(-) Tested-by: Aaron Brown -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [Intel-wired-lan] [PATCH] e100: Add a check after pci_pool_create to avoid null pointer dereference
> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@lists.osuosl.org] On > Behalf Of Jia-Ju Bai > Sent: Sunday, August 02, 2015 7:17 PM > To: Kirsher, Jeffrey T; Brandeburg, Jesse > Cc: net...@vger.kernel.org; Jia-Ju Bai; intel-wired-...@lists.osuosl.org; > linux-kernel@vger.kernel.org > Subject: [Intel-wired-lan] [PATCH] e100: Add a check after pci_pool_create > to avoid null pointer dereference > > The driver lacks the check of nic->cbs_pool after pci_pool_create > in e100_probe. When this function is failed, a null pointer dereference > occurs when pci_pool_alloc uses nic->cbs_pool in e100_alloc_cbs. > This patch adds a check and related error handling code to fix it. > > Signed-off-by: Jia-Ju Bai > --- > drivers/net/ethernet/intel/e100.c |7 +++ > 1 file changed, 7 insertions(+) Tested-by: Aaron Brown -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [Intel-wired-lan] [PATCH v2] e1000e: Modify tx/rx configurations to avoid null pointer dereferences in e1000_open
> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@lists.osuosl.org] On > Behalf Of Jia-Ju Bai > Sent: Wednesday, August 05, 2015 3:16 AM > To: Kirsher, Jeffrey T; Brandeburg, Jesse > Cc: net...@vger.kernel.org; Jia-Ju Bai; intel-wired-...@lists.osuosl.org; > linux-kernel@vger.kernel.org > Subject: [Intel-wired-lan] [PATCH v2] e1000e: Modify tx/rx configurations > to avoid null pointer dereferences in e1000_open > > When e1000e_setup_rx_resources is failed in e1000_open, > e1000e_free_tx_resources in "err_setup_rx" segment is executed. > "writel(0, tx_ring->head)" statement in e1000_clean_tx_ring > in e1000e_free_tx_resources will cause a null poonter dereference(crash), > because "tx_ring->head" is only assigned in e1000_configure_tx > in e1000_configure, but it is after e1000e_setup_rx_resources. > > This patch moves head/tail register writing to e1000_configure_tx/rx, > which can fix this problem. It is inspired by igb_configure_tx_ring > in the igb driver. > > Specially, thank Alexander Duyck for his valuable suggestion. > > Signed-off-by: Jia-Ju Bai > --- > drivers/net/ethernet/intel/e1000e/netdev.c | 24 --- > - > 1 file changed, 12 insertions(+), 12 deletions(-) Tested-by: Aaron Brown -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH net] igb: Fix oops caused by missing queue pairing
> From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org]
> On Behalf Of Shota Suzuki
> Sent: Tuesday, June 30, 2015 5:26 PM
> To: Kirsher, Jeffrey T; Brandeburg, Jesse; Nelson, Shannon; Wyborny,
> Carolyn; Skidmore, Donald C; Vick, Matthew; Ronciak, John; Williams, Mitch
> A; intel-wired-...@lists.osuosl.org; net...@vger.kernel.org; linux-
> ker...@vger.kernel.org
> Cc: Shota Suzuki
> Subject: [PATCH net] igb: Fix oops caused by missing queue pairing
>
> When initializing igb driver (e.g. 82576, I350), IGB_FLAG_QUEUE_PAIRS is
> set if adapter->rss_queues exceeds half of max_rss_queues in
> igb_init_queue_configuration().
> On the other hand, IGB_FLAG_QUEUE_PAIRS is not set even if the number of
> queues exceeds half of max_combined in igb_set_channels() when changing
> the number of queues by "ethtool -L".
> In this case, if numvecs is larger than MAX_MSIX_ENTRIES (10), the size
> of adapter->msix_entries[], an overflow can occur in
> igb_set_interrupt_capability(), which in turn leads to an oops.
>
> Fix this problem as follows:
> - When changing the number of queues by "ethtool -L", set
>IGB_FLAG_QUEUE_PAIRS in the same way as initializing igb driver.
> - When increasing the size of q_vector, reallocate it appropriately.
>(With IGB_FLAG_QUEUE_PAIRS set, the size of q_vector gets larger.)
>
> Another possible way to fix this problem is to cap the queues at its
> initial number, which is the number of the initial online cpus. But this
> is not the optimal way because we cannnot increase queues when another
> cpu becomes online.
>
> Note that before commit cd14ef54d25b ("igb: Change to use statically
> allocated array for MSIx entries"), this problem did not cause oops
> but just made the number of queues become 1 because of entering msi_only
> mode in igb_set_interrupt_capability().
>
> Fixes: 907b7835799f ("igb: Add ethtool support to configure number of
> channels")
> Signed-off-by: Shota Suzuki
> ---
> Although we might be able to additionally unset IGB_FLAG_QUEUE_PAIRS
> when it is not needed, this patch doesn't change existing behaviour
> because such a change is not a bug fix.
>
> drivers/net/ethernet/intel/igb/igb.h | 1 +
> drivers/net/ethernet/intel/igb/igb_ethtool.c | 5 -
> drivers/net/ethernet/intel/igb/igb_main.c| 16 ++--
> 3 files changed, 19 insertions(+), 3 deletions(-)
Tested-by: Aaron Brown
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] igb: adjust ptp timestamps for tx/rx latency
> From: netdev-ow...@vger.kernel.org [mailto:netdev- > ow...@vger.kernel.org] On Behalf Of Nathan Sullivan > Sent: Tuesday, May 3, 2016 4:11 PM > To: Kirsher, Jeffrey T ; Brandeburg, Jesse > ; Nelson, Shannon > ; Wyborny, Carolyn > ; Skidmore, Donald C > ; Allan, Bruce W ; > Ronciak, John ; Williams, Mitch A > > Cc: intel-wired-...@lists.osuosl.org; net...@vger.kernel.org; linux- > ker...@vger.kernel.org; Nathan Sullivan > Subject: [PATCH] igb: adjust ptp timestamps for tx/rx latency > > Table 7-62 on page 338 of the i210 datasheet lists TX and RX latencies > for the various speeds the chip supports. To give better ptp timestamp > accuracy, adjust the timestamps by the amounts Intel gives based on > current link speed. > > Signed-off-by: Nathan Sullivan > --- > drivers/net/ethernet/intel/igb/igb.h |8 +++ > drivers/net/ethernet/intel/igb/igb_ptp.c | 36 > ++ > 2 files changed, 44 insertions(+) Tested-by: Aaron Brown
RE: [Intel-wired-lan] [RFC PATCH net] e1000e: keep vlan interfaces functional after rxvlan off
> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@lists.osuosl.org] On > Behalf Of Jeff Kirsher > Sent: Wednesday, May 18, 2016 2:40 PM > To: Jarod Wilson ; linux-kernel@vger.kernel.org; > Avargil, Raanan > Cc: net...@vger.kernel.org; intel-wired-...@lists.osuosl.org > Subject: Re: [Intel-wired-lan] [RFC PATCH net] e1000e: keep vlan interfaces > functional after rxvlan off > > On Tue, 2016-05-17 at 15:03 -0400, Jarod Wilson wrote: > > I've got a bug report about an e1000e interface, where a vlan interface > > is > > set up on top of it: > > > > $ ip link add link ens1f0 name ens1f0.99 type vlan id 99 > > $ ip link set ens1f0 up > > $ ip link set ens1f0.99 up > > $ ip addr add 192.168.99.92 dev ens1f0.99 > > > > At this point, I can ping another host on vlan 99, ip 192.168.99.91. > > However, if I do the following: > > > > $ ethtool -K ens1f0 rxvlan off > > > > Then no traffic passes on ens1f0.99. It comes back if I toggle rxvlan on > > again. I'm not sure if this is actually intended behavior, or if there's > > a > > lack of software vlan stripping fallback, or what, but things continue to > > work if I simply don't call e1000e_vlan_strip_disable() if there are > > active vlans (plagiarizing a function from the e1000 driver here) on the > > interface. > > > > Also slipped a related-ish fix to the kerneldoc text for > > e1000e_vlan_strip_disable here... > > > > CC: Jeff Kirsher > > CC: intel-wired-...@lists.osuosl.org > > CC: net...@vger.kernel.org > > Signed-off-by: Jarod Wilson > > --- > > drivers/net/ethernet/intel/e1000e/netdev.c | 15 +-- > > 1 file changed, 13 insertions(+), 2 deletions(-) > > Raanan, please review this patch. Even though it is an RFC I will be > adding it to my queue for testing. > http://patchwork.ozlabs.org/patch/623238/ Yup, without this patch disabling rxvlan offload does indeed break vlan connectivity and with the patch I can disable and re-enable rxvlan offloads as much as I care to. It also makes it through my regression tests without problems. Tested-by: Aaron Brown This is from functional - does it work - testing perspective so review is probably still in order.
RE: [Intel-wired-lan] [PATCH] e1000e: prevent division by zero if TIMINCA is zero
> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@lists.osuosl.org] On
> Behalf Of Denys Vlasenko
> Sent: Friday, May 6, 2016 12:42 PM
> To: Kirsher, Jeffrey T
> Cc: intel-wired-...@lists.osuosl.org; Denys Vlasenko
> ; LKML ;
> net...@vger.kernel.org
> Subject: [Intel-wired-lan] [PATCH] e1000e: prevent division by zero if
> TIMINCA is zero
>
> Users report that under VMWare, er32(TIMINCA) returns zero.
> This causes division by zero at init time as follows:
>
> ==>incvalue = er32(TIMINCA) & E1000_TIMINCA_INCVALUE_MASK;
> for (i = 0; i < E1000_MAX_82574_SYSTIM_REREADS; i++) {
> /* latch SYSTIMH on read of SYSTIML */
> systim_next = (cycle_t)er32(SYSTIML);
> systim_next |= (cycle_t)er32(SYSTIMH) << 32;
>
> time_delta = systim_next - systim;
> temp = time_delta;
> > rem = do_div(temp, incvalue);
>
> This change makes kernel survive this, and users report that
> NIC does work after this change.
>
> Since on real hardware incvalue is never zero, this should not affect
> real hardware use case.
>
> Signed-off-by: Denys Vlasenko
> CC: Jeff Kirsher
> CC: "Ruinskiy, Dima"
> CC: intel-wired-...@lists.osuosl.org
> CC: net...@vger.kernel.org
> CC: LKML
> ---
> drivers/net/ethernet/intel/e1000e/netdev.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
As Mark Rustad pointed out I recall this was earlier rejected as something that
is a VMWare error and it should be fixed there so that existing VMs will start
working without installing a new driver. Having said that, it does not seem to
be causing any harm in my testing, so...
Tested-by: Aaron Brown
RE: [Intel-wired-lan] [PATCH v2] igb: improve handling of disconnected adapters
> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@lists.osuosl.org] On > Behalf Of Jarod Wilson > Sent: Monday, October 19, 2015 8:52 AM > To: linux-kernel@vger.kernel.org > Cc: net...@vger.kernel.org; Jarod Wilson ; intel-wired- > l...@lists.osuosl.org > Subject: [Intel-wired-lan] [PATCH v2] igb: improve handling of disconnected > adapters > > Clean up array_rd32 so that it uses igb_rd32 the same as rd32, per the > suggestion of Alexander Duyck, and use io_addr in more places, so that > we don't have the need to call E1000_REMOVED (which simply looks for a > null hw_addr) nearly as much. > > CC: Mark Rustad > CC: Jeff Kirsher > CC: Alexander Duyck > CC: intel-wired-...@lists.osuosl.org > CC: net...@vger.kernel.org > Acked-by: Alexander Duyck > Signed-off-by: Jarod Wilson > --- > Note: this patch is rebased on Jeff's next-queue/dev-queue branch, which > already had an earlier revision of this applied, so I've essentially > reverted a2675ab and applied the revised version of this, squashed them > together, and here is the end result, which matches the version Alex acked. > > drivers/net/ethernet/intel/igb/e1000_regs.h | 3 +-- > drivers/net/ethernet/intel/igb/igb_main.c | 15 ++- > 2 files changed, 3 insertions(+), 15 deletions(-) > Tested-by: Aaron Brown -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] e1000e: fix division by zero on jumbo MTUs
> From: netdev-ow...@vger.kernel.org [mailto:netdev- > ow...@vger.kernel.org] On Behalf Of Leonid Bloch > Sent: Tuesday, October 13, 2015 2:48 AM > To: linux-kernel@vger.kernel.org > Cc: Kirsher, Jeffrey T ; Brandeburg, Jesse > ; Nelson, Shannon > ; Wyborny, Carolyn > ; Skidmore, Donald C > ; Vick, Matthew ; > Ronciak, John ; Williams, Mitch A > ; intel-wired-...@lists.osuosl.org; > net...@vger.kernel.org; Dmitry Fleytman > Subject: [PATCH] e1000e: fix division by zero on jumbo MTUs > > From: Dmitry Fleytman > > This patch fixes possible division by zero in receive > interrupt handler when working without adaptive interrupt > moderation. > > The adaptive interrupt moderation mechanism is typically > disabled on jumbo MTUs. > > Signed-off-by: Dmitry Fleytman > Signed-off-by: Leonid Bloch > --- > drivers/net/ethernet/intel/e1000e/netdev.c | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) Tested-by: Aaron Brown -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH -v2] drivers: net: ethernet: intel: e1000e: fix ethtool autoneg off for non-copper
> From: netdev-ow...@vger.kernel.org [mailto:netdev- > ow...@vger.kernel.org] On Behalf Of Daniel Walker > Sent: Tuesday, April 5, 2016 11:30 AM > To: Ruinskiy, Dima ; Kirsher, Jeffrey T > ; Brandeburg, Jesse > ; Nelson, Shannon > ; Wyborny, Carolyn > ; Skidmore, Donald C > ; Allan, Bruce W ; > Ronciak, John ; Williams, Mitch A > > Cc: Steve Shih ; xe-ker...@external.cisco.com; Daniel > Walker ; intel-wired-...@lists.osuosl.org; > net...@vger.kernel.org; linux-kernel@vger.kernel.org > Subject: [PATCH -v2] drivers: net: ethernet: intel: e1000e: fix ethtool > autoneg > off for non-copper > > From: Steve Shih > > This patch fixes the issues for disabling auto-negotiation and forcing > speed and duplex settings for the non-copper media. > > For non-copper media, e1000_get_settings should return > ETH_TP_MDI_INVALID for > eth_tp_mdix_ctrl instead of ETH_TP_MDI_AUTO so subsequent > e1000_set_settings > call would not fail with -EOPNOTSUPP. > > e1000_set_spd_dplx should not automatically turn autoneg back on for > forced > 1000 Mbps full duplex settings for non-copper media. > > Cc: xe-ker...@external.cisco.com > Cc: Daniel Walker > Signed-off-by: Steve Shih > --- > drivers/net/ethernet/intel/e1000e/ethtool.c | 11 +-- > 1 file changed, 9 insertions(+), 2 deletions(-) Tested-by: Aaron Brown
Re: [PATCH] igb/igc: Don't warn on fatal read failures when the device is removed
On Thu, 2019-08-22 at 14:33 -0400, Lyude Paul wrote:
> Fatal read errors are worth warning about, unless of course the device
> was just unplugged from the machine - something that's a rather normal
> occurence when the igb/igc adapter is located on a Thunderbolt dock. So,
> let's only WARN() if there's a fatal read error while the device is
> still present.
>
> This fixes the following WARN splat that's been appearing whenever I
> unplug my Caldigit TS3 Thunderbolt dock from my laptop:
>
> igb :09:00.0 enp9s0: PCIe link lost
> [ cut here ]
> igb: Failed to read reg 0x18!
> WARNING: CPU: 7 PID: 516 at
> drivers/net/ethernet/intel/igb/igb_main.c:756 igb_rd32+0x57/0x6a [igb]
> Modules linked in: igb dca thunderbolt fuse vfat fat elan_i2c mei_wdt
> mei_hdcp i915 wmi_bmof intel_wmi_thunderbolt iTCO_wdt
> iTCO_vendor_support x86_pkg_temp_thermal intel_powerclamp joydev
> coretemp crct10dif_pclmul crc32_pclmul i2c_algo_bit ghash_clmulni_intel
> intel_cstate drm_kms_helper intel_uncore syscopyarea sysfillrect
> sysimgblt fb_sys_fops intel_rapl_perf intel_xhci_usb_role_switch mei_me
> drm roles idma64 i2c_i801 ucsi_acpi typec_ucsi mei intel_lpss_pci
> processor_thermal_device typec intel_pch_thermal intel_soc_dts_iosf
> intel_lpss int3403_thermal thinkpad_acpi wmi int340x_thermal_zone
> ledtrig_audio int3400_thermal acpi_thermal_rel acpi_pad video
> pcc_cpufreq ip_tables serio_raw nvme nvme_core crc32c_intel uas
> usb_storage e1000e i2c_dev
> CPU: 7 PID: 516 Comm: kworker/u16:3 Not tainted 5.2.0-rc1Lyude-Test+ #14
> Hardware name: LENOVO 20L8S2N800/20L8S2N800, BIOS N22ET35W (1.12 )
> 04/09/2018
> Workqueue: kacpi_hotplug acpi_hotplug_work_fn
> RIP: 0010:igb_rd32+0x57/0x6a [igb]
> Code: 87 b8 fc ff ff 48 c7 47 08 00 00 00 00 48 c7 c6 33 42 9b c0 4c 89
> c7 e8 47 45 cd dc 89 ee 48 c7 c7 43 42 9b c0 e8 c1 94 71 dc <0f> 0b eb
> 08 8b 00 ff c0 75 b0 eb c8 44 89 e0 5d 41 5c c3 0f 1f 44
> RSP: 0018:ba5801cf7c48 EFLAGS: 00010286
> RAX: RBX: 9e7956608840 RCX: 0007
> RDX: RSI: ba5801cf7b24 RDI: 9e795e3d6a00
> RBP: 0018 R08: 9dec4a01 R09: 9e61018f
> R10: R11: ba5801cf7ae5 R12:
> R13: 9e7956608840 R14: 9e795a6f10b0 R15:
> FS: () GS:9e795e3c() knlGS:
> CS: 0010 DS: ES: CR0: 80050033
> CR2: 564317bc4088 CR3: 00010e00a006 CR4: 003606e0
> DR0: DR1: DR2:
> DR3: DR6: fffe0ff0 DR7: 0400
> Call Trace:
>igb_release_hw_control+0x1a/0x30 [igb]
>igb_remove+0xc5/0x14b [igb]
>pci_device_remove+0x3b/0x93
>device_release_driver_internal+0xd7/0x17e
>pci_stop_bus_device+0x36/0x75
>pci_stop_bus_device+0x66/0x75
>pci_stop_bus_device+0x66/0x75
>pci_stop_and_remove_bus_device+0xf/0x19
>trim_stale_devices+0xc5/0x13a
>? __pm_runtime_resume+0x6e/0x7b
>trim_stale_devices+0x103/0x13a
>? __pm_runtime_resume+0x6e/0x7b
>trim_stale_devices+0x103/0x13a
>acpiphp_check_bridge+0xd8/0xf5
>acpiphp_hotplug_notify+0xf7/0x14b
>? acpiphp_check_bridge+0xf5/0xf5
>acpi_device_hotplug+0x357/0x3b5
>acpi_hotplug_work_fn+0x1a/0x23
>process_one_work+0x1a7/0x296
>worker_thread+0x1a8/0x24c
>? process_scheduled_works+0x2c/0x2c
>kthread+0xe9/0xee
>? kthread_destroy_worker+0x41/0x41
>ret_from_fork+0x35/0x40
> ---[ end trace 252bf10352c63d22 ]---
>
> Signed-off-by: Lyude Paul
> Fixes: 47e16692b26b ("igb/igc: warn when fatal read failure happens")
> Cc: Feng Tang
> Cc: Sasha Neftin
> Cc: Jeff Kirsher
> Cc: intel-wired-...@lists.osuosl.org
> ---
> drivers/net/ethernet/intel/igb/igb_main.c | 3 ++-
> drivers/net/ethernet/intel/igc/igc_main.c | 3 ++-
> 2 files changed, 4 insertions(+), 2 deletions(-)
>
Tested-by: Aaron Brown
Re: [PATCH] e1000: fix memory leaks
On Mon, 2019-08-12 at 00:59 -0500, Wenwen Wang wrote: > In e1000_set_ringparam(), 'tx_old' and 'rx_old' are not deallocated if > e1000_up() fails, leading to memory leaks. Refactor the code to fix this > issue. > > Signed-off-by: Wenwen Wang > --- > drivers/net/ethernet/intel/e1000/e1000_ethtool.c | 7 +++ > 1 file changed, 3 insertions(+), 4 deletions(-) Tested-by: Aaron Brown
RE: [PATCH] ethernet/intel: release the local packet buffer
> From: netdev-ow...@vger.kernel.org [mailto:netdev- > ow...@vger.kernel.org] On Behalf Of Navid Emamdoost > Sent: Tuesday, September 17, 2019 5:00 PM > Cc: emamd...@umn.edu; smcca...@umn.edu; k...@umn.edu; Navid > Emamdoost ; Kirsher, Jeffrey T > ; David S. Miller ; > intel-wired-...@lists.osuosl.org; net...@vger.kernel.org; linux- > ker...@vger.kernel.org > Subject: [PATCH] ethernet/intel: release the local packet bufferq > > In e100_loopback_test the buffer allocated for the local packet needs to > be released. > > Signed-off-by: Navid Emamdoost > --- > drivers/net/ethernet/intel/e100.c | 1 + > 1 file changed, 1 insertion(+) Sorry for the delay getting to this, took me a bit to get the hardware together. NAK, this patch introduces a trace to my test machines when I run the ethtool diagnostic on an e100 port, the system will sometimes survive a bit after the trace, however if I try to run traffic across the interface after the trace the system panics and locks up with a kernel not syncing message. I do not have a capture of the lock up panic (I can probably get one via serial port or netconsole if really necessary.) The trace before the lock up panic is as follows: --- [ 102.460446] BUG: Bad page state in process ethtool pfn:78db8 [ 102.460474] page:d5bf41e36e00 refcount:-1 mapcount:0 mapping: index:0x0 [ 102.460505] flags: 0xfc000() [ 102.460523] raw: 000fc000 dead0100 dead0122 [ 102.460553] raw: [ 102.460582] page dumped because: nonzero _refcount [ 102.460602] Modules linked in: snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel snd_intel_nhlt snd_hda_codec snd_hwdep snd_hda_core snd_seq snd_seq_device snd_pcm mei_wdt snd_timer iTCO_wdt mei_me snd iTCO_vendor_support gpio_ic h mei coretemp lpc_ich pcspkr sg soundcore i2c_i801 joydev acpi_cpufreq nfsd auth_rpcgss nfs_acl lockd grace sunrpc ip_t ables xfs libcrc32c sd_mod sr_mod cdrom i915 video i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_ fops e1000e ata_generic firewire_ohci pata_marvell ata_piix drm pata_acpi serio_raw e100 firewire_core libata ptp pps_co re mii crc_itu_t [ 102.460800] CPU: 3 PID: 1541 Comm: ethtool Not tainted 5.4.0-rc1_next-queue_dev-queue_regress-00576-g16390e0 #3 [ 102.460836] Hardware name: /DQ35JO, BIOS JOQ3510J.86A.0954.2008.0922.2331 09/22/2008 [ 102.460865] Call Trace: [ 102.460883] dump_stack+0x5a/0x73 [ 102.460900] bad_page+0xf5/0x10f [ 102.460916] get_page_from_freelist+0x103e/0x1290 [ 102.460936] ? __switch_to_asm+0x40/0x70 [ 102.460955] ? __build_skb+0x20/0x190 [ 102.460972] __alloc_pages_nodemask+0x17d/0x320 [ 102.460991] page_frag_alloc+0x87/0x130 [ 102.461008] __netdev_alloc_skb+0x10b/0x130 [ 102.461029] e100_rx_alloc_skb+0x20/0x180 [e100] [ 102.461050] e100_rx_alloc_list+0x98/0x160 [e100] [ 102.461070] e100_up+0x11/0x120 [e100] [ 102.461088] e100_diag_test+0x14e/0x157 [e100] [ 102.461107] ? _cond_resched+0x15/0x30 [ 102.461125] ? dev_ethtool+0x1133/0x2c30 [ 102.461143] dev_ethtool+0x1159/0x2c30 [ 102.461161] ? inet_ioctl+0x1a0/0x1d0 [ 102.461178] ? netdev_run_todo+0x5d/0x2d0 [ 102.461196] dev_ioctl+0xb3/0x4e0 [ 102.461212] sock_do_ioctl+0xa0/0x140 [ 102.461228] ? do_anonymous_page+0x361/0x670 [ 102.461247] sock_ioctl+0x26e/0x380 [ 102.461264] do_vfs_ioctl+0xa9/0x630 [ 102.461281] ? handle_mm_fault+0xe2/0x1f0 [ 102.462101] ? __do_page_fault+0x247/0x490 [ 102.462911] ksys_ioctl+0x60/0x90 [ 102.463715] __x64_sys_ioctl+0x16/0x20 [ 102.464519] do_syscall_64+0x5b/0x1b0 [ 102.465321] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 102.466134] RIP: 0033:0x7f03e53f32f7 [ 102.466948] Code: 44 00 00 48 8b 05 79 1b 2d 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 49 1b 2d 00 f7 d8 64 89 01 48 [ 102.468728] RSP: 002b:7c72ebf8 EFLAGS: 0246 ORIG_RAX: 0010 [ 102.469657] RAX: ffda RBX: 7c72ec50 RCX: 7f03e53f32f7 [ 102.470595] RDX: 7c72ec60 RSI: 8946 RDI: 0003 [ 102.471532] RBP: 0001 R08: 0002 R09: 0038 [ 102.472453] R10: 7c72e7c0 R11: 0246 R12: 0038 [ 102.473359] R13: 01428010 R14: 014280d0 R15: 7c72edc8 [ 102.474260] Disabling lock debugging due to kernel taint [ 104.924447] e100 :06:00.0 eth0: NIC Link is Up 100 Mbps Full Duplex ---
RE: [PATCH] e1000e: fix cyclic resets at link up with active tx
> -Original Message- > From: netdev-ow...@vger.kernel.org [mailto:netdev- > ow...@vger.kernel.org] On Behalf Of Konstantin Khlebnikov > Sent: Monday, January 14, 2019 5:30 AM > To: net...@vger.kernel.org; intel-wired-...@lists.osuosl.org; Kirsher, > Jeffrey T > Cc: linux-kernel@vger.kernel.org; David S. Miller > Subject: [PATCH] e1000e: fix cyclic resets at link up with active tx > > I'm seeing series of e1000e resets (sometimes endless) at system boot > if something generates tx traffic at this time. In my case this is > netconsole who sends message "e1000e :02:00.0: Some CPU C-states > have been disabled in order to enable jumbo frames" from e1000e itself. > As result e1000_watchdog_task sees used tx buffer while carrier is off > and start this reset cycle again. > > [ 17.794359] e1000e: eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow > Control: None > [ 17.794714] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready > [ 22.936455] e1000e :02:00.0 eth1: changing MTU from 1500 to 9000 > [ 23.06] e1000e :02:00.0: Some CPU C-states have been disabled in > order to enable jumbo frames > [ 26.102364] e1000e: eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow > Control: None > [ 27.174495] 8021q: 802.1Q VLAN Support v1.8 > [ 27.174513] 8021q: adding VLAN 0 to HW filter on device eth1 > [ 30.671724] cgroup: cgroup: disabling cgroup2 socket matching due to > net_prio or net_cls activation > [ 30.898564] netpoll: netconsole: local port > [ 30.898566] netpoll: netconsole: local IPv6 address > 2a02:6b8:0:80b:beae:c5ff:fe28:23f8 > [ 30.898567] netpoll: netconsole: interface 'eth1' > [ 30.898568] netpoll: netconsole: remote port > [ 30.898568] netpoll: netconsole: remote IPv6 address > 2a02:6b8:b000:605c:e61d:2dff:fe03:3790 > [ 30.898569] netpoll: netconsole: remote ethernet address b0:a8:6e:f4:ff:c0 > [ 30.917747] console [netcon0] enabled > [ 30.917749] netconsole: network logging started > [ 31.453353] e1000e :02:00.0: Some CPU C-states have been disabled in > order to enable jumbo frames > [ 34.185730] e1000e :02:00.0: Some CPU C-states have been disabled in > order to enable jumbo frames > [ 34.321840] e1000e :02:00.0: Some CPU C-states have been disabled in > order to enable jumbo frames > [ 34.465822] e1000e :02:00.0: Some CPU C-states have been disabled in > order to enable jumbo frames > [ 34.597423] e1000e :02:00.0: Some CPU C-states have been disabled in > order to enable jumbo frames > [ 34.745417] e1000e :02:00.0: Some CPU C-states have been disabled in > order to enable jumbo frames > [ 34.877356] e1000e :02:00.0: Some CPU C-states have been disabled in > order to enable jumbo frames > [ 35.005441] e1000e :02:00.0: Some CPU C-states have been disabled in > order to enable jumbo frames > [ 35.157376] e1000e :02:00.0: Some CPU C-states have been disabled in > order to enable jumbo frames > [ 35.289362] e1000e :02:00.0: Some CPU C-states have been disabled in > order to enable jumbo frames > [ 35.417441] e1000e :02:00.0: Some CPU C-states have been disabled in > order to enable jumbo frames > [ 37.790342] e1000e: eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow > Control: None > > This patch flushes tx buffers only once when carrier is off > rather than at each watchdog iteration. > > Signed-off-by: Konstantin Khlebnikov > --- > drivers/net/ethernet/intel/e1000e/netdev.c | 15 ++- > 1 file changed, 6 insertions(+), 9 deletions(-) Tested-by: Aaron Brown
RE: [PATCH] igb: fix various indentation issues
> From: netdev-ow...@vger.kernel.org [mailto:netdev- > ow...@vger.kernel.org] On Behalf Of Colin King > Sent: Wednesday, January 16, 2019 10:53 AM > To: Kirsher, Jeffrey T ; David S . Miller > ; intel-wired-...@lists.osuosl.org; > net...@vger.kernel.org > Cc: kernel-janit...@vger.kernel.org; linux-kernel@vger.kernel.org > Subject: [PATCH] igb: fix various indentation issues > > From: Colin Ian King > > There are some lines that have indentation issues, fix these > > Signed-off-by: Colin Ian King > --- > drivers/net/ethernet/intel/igb/igb_ethtool.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > Tested-by: Aaron Brown
RE: [PATCH 2/2] igb: Exclude device from suspend direct complete optimization
> From: netdev-ow...@vger.kernel.org [mailto:netdev- > ow...@vger.kernel.org] On Behalf Of Kai-Heng Feng > Sent: Tuesday, December 11, 2018 12:00 AM > To: Kirsher, Jeffrey T > Cc: da...@davemloft.net; intel-wired-...@lists.osuosl.org; > net...@vger.kernel.org; linux-kernel@vger.kernel.org; Kai-Heng Feng > > Subject: [PATCH 2/2] igb: Exclude device from suspend direct complete > optimization > > igb sets different WoL settings in system suspend callback and runtime > suspend callback. > > The suspend direct complete optimization leaves igb in runtime suspneded > state with wrong WoL setting during system suspend. > > To fix this, we need to disable suspend direct complete optimization to > let igb always use suspend callback to set correct WoL during system > suspend. > > Signed-off-by: Kai-Heng Feng > --- > drivers/net/ethernet/intel/igb/igb_main.c | 3 +++ > 1 file changed, 3 insertions(+) > Tested-by: Aaron Brown
Re: [Intel-wired-lan] [PATCH v2] e1000e: Make speed detection on hotplugging cable more reliable
On Mon, 2019-07-15 at 20:25 +0800, Kai-Heng Feng wrote:
> After hotplugging an 1Gbps ethernet cable with 1Gbps link partner, the
> MII_BMSR may report 10Mbps, renders the network rather slow.
>
> The issue has much lower fail rate after commit 59653e6497d1 ("e1000e:
> Make watchdog use delayed work"), which essentially introduces some
> delay before running the watchdog task.
>
> But there's still a chance that the hotplugging event and the queued
> watchdog task gets run at the same time, then the original issue can be
> observed once again.
>
> So let's use mod_delayed_work() to add a deterministic 1 second delay
> before running watchdog task, after an interrupt.
>
> Signed-off-by: Kai-Heng Feng
> ---
> drivers/net/ethernet/intel/e1000e/netdev.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
Tested-by: Aaron Brown
RE: [PATCH v3] e1000e: Make watchdog use delayed work
> From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org] > On Behalf Of Detlev Casanova > Sent: Saturday, June 22, 2019 8:15 PM > To: Kirsher, Jeffrey T ; David S. Miller > ; intel-wired-...@lists.osuosl.org; > net...@vger.kernel.org; linux-kernel@vger.kernel.org > Cc: Detlev Casanova > Subject: [PATCH v3] e1000e: Make watchdog use delayed work > > Use delayed work instead of timers to run the watchdog of the e1000e > driver. > > Simplify the code with one less middle function. > > Signed-off-by: Detlev Casanova > --- > drivers/net/ethernet/intel/e1000e/e1000.h | 5 +- > drivers/net/ethernet/intel/e1000e/netdev.c | 54 -- > 2 files changed, 32 insertions(+), 27 deletions(-) Tested-by: Aaron Brown
Re: [Intel-wired-lan] [PATCH 1/2] e1000e: add workaround for possible stalled packet
On Mon, 2019-07-08 at 12:55 +0800, Kai-Heng Feng wrote: > Forwardport from http://mails.dpdk.org/archives/dev/2016-November/050657.html > > This works around a possible stalled packet issue, which may occur due to > clock recovery from the PCH being too slow, when the LAN is transitioning > from K1 at 1G link speed. > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=204057 > > Signed-off-by: Kai-Heng Feng > --- > drivers/net/ethernet/intel/e1000e/ich8lan.c | 10 ++ > drivers/net/ethernet/intel/e1000e/ich8lan.h | 2 +- > 2 files changed, 11 insertions(+), 1 deletion(-) Tested-by: Aaron Brown
Re: [Intel-wired-lan] [PATCH 2/2] e1000e: disable force K1-off feature
On Mon, 2019-07-08 at 12:55 +0800, Kai-Heng Feng wrote: > Forwardport from http://mails.dpdk.org/archives/dev/2016-November/050658.html > > MAC-PHY desync may occur causing misdetection of link up event. > Disabling K1-off feature can work around the problem. > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=204057 > > Signed-off-by: Kai-Heng Feng > --- > drivers/net/ethernet/intel/e1000e/hw.h | 1 + > drivers/net/ethernet/intel/e1000e/ich8lan.c | 3 +++ > 2 files changed, 4 insertions(+) > Tested-by: Aaron Brown
RE: [Intel-wired-lan] [PATCH] e1000e: Disable runtime PM on CNP+
> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On > Behalf Of Kai-Heng Feng > Sent: Saturday, February 2, 2019 9:40 AM > To: Kirsher, Jeffrey T > Cc: net...@vger.kernel.org; Kai-Heng Feng > ; intel-wired-...@lists.osuosl.org; linux- > ker...@vger.kernel.org > Subject: [Intel-wired-lan] [PATCH] e1000e: Disable runtime PM on CNP+ > > There are some new e1000e devices can only be woken up from D3 one > time, > by plugging ethernet cable. Subsequent cable plugging does set PME bit > correctly, but it still doesn't get woken up. > > Since e1000e connects to the root complex directly, we rely on ACPI to > wake it up. In this case, the GPE from _PRW only works once and stops > working after that. Though it appears to be a platform bug, e1000e > maintainers confirmed that I219 does not support D3. > > So disable runtime PM on CNP+ chips. We may need to disable earlier > generations if this bug also hit older platforms. > > Bugzilla: https://bugzilla.kernel.org/attachment.cgi?id=280819 > Signed-off-by: Kai-Heng Feng > --- > drivers/net/ethernet/intel/e1000e/netdev.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > Tested-by: Aaron Brown
RE: Documentation: networking: ixgb: Remove reference to IXGB_NAPI
> From patchwork Mon Jan 29 12:17:54 2018
> Content-Type: text/plain; charset="utf-8"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Subject: Documentation: networking: ixgb: Remove reference to IXGB_NAPI
> X-Patchwork-Submitter: Corentin Labbe
> X-Patchwork-Id: 867294
> X-Patchwork-Delegate: jeffrey.t.kirs...@intel.com
> Message-Id: <1517228274-1305-1-git-send-email-cla...@baylibre.com>
> To: cor...@lwn.net, jeffrey.t.kirs...@intel.com
> Cc: Corentin Labbe , intel-wired-...@lists.osuosl.org,
> linux-kernel@vger.kernel.org, linux-...@vger.kernel.org
> Date: Mon, 29 Jan 2018 12:17:54 +
> From: Corentin Labbe
> List-Id: Intel Wired Ethernet Linux Kernel Driver Development
>
>
> NAPI is enabled by default and IXGB_NAPI was removed since
> commit 6d37ab282e24 ("ixgb: make NAPI the only option and the default")
> Update the doc accordingly.
>
> Signed-off-by: Corentin Labbe
> ---
> Documentation/networking/ixgb.txt | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
Tested-by: Aaron Brown
RE: [Intel-wired-lan] [PATCH] igb: use igb_adapter->io_addr instead of e1000_hw->hw_addr
> From: Intel-wired-lan [intel-wired-lan-boun...@lists.osuosl.org] on behalf of > Cao jin [caoj.f...@cn.fujitsu.com] > Sent: Monday, November 07, 2016 11:06 PM To> : linux-kernel@vger.kernel.org; net...@vger.kernel.org > Cc: izumi.t...@jp.fujitsu.com; intel-wired-...@lists.osuosl.org > Subject: [Intel-wired-lan] [PATCH] igb: use igb_adapter->io_addr instead of > e1000_hw->hw_addr > > When running as guest, under certain condition, it will oops as following. > writel() in igb_configure_tx_ring() results in oops, because hw->hw_addr > is NULL. While other register access won't oops kernel because they use > wr32/rd32 which have a defense against NULL pointer. > > [ 141.225449] pcieport :00:1c.0: AER: Multiple Uncorrected (Fatal) > error received: id=0101 > [ 141.225523] igb :01:00.1: PCIe Bus Error: > severity=Uncorrected (Fatal), type=Unaccessible, > id=0101(Unregistered Agent ID) > [ 141.299442] igb :01:00.1: broadcast error_detected message > [ 141.300539] igb :01:00.0 enp1s0f0: PCIe link lost, device now > detached > [ 141.351019] igb :01:00.1 enp1s0f1: PCIe link lost, device now > detached > [ 143.465904] pcieport :00:1c.0: Root Port link has been reset > [ 143.465994] igb :01:00.1: broadcast slot_reset message > [ 143.466039] igb :01:00.0: enabling device ( -> 0002) > [ 144.389078] igb :01:00.1: enabling device ( -> 0002) > [ 145.312078] igb :01:00.1: broadcast resume message > [ 145.322211] BUG: unable to handle kernel paging request at > 3818 > [ 145.361275] IP: [] > igb_configure_tx_ring+0x14d/0x280 [igb] > [ 145.400048] PGD 0 > [ 145.438007] Oops: 0002 [#1] SMP > > A similiar issue & solution could be found at: > http://patchwork.ozlabs.org/patch/689592/ > > Signed-off-by: Cao jin > --- > drivers/net/ethernet/intel/igb/igb_main.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) Tested-by: Aaron Brown
RE: [PATCH 1/1] igb: Fix hw_dbg logging in igb_update_flash_i210
> From: netdev-ow...@vger.kernel.org [mailto:netdev- > ow...@vger.kernel.org] On Behalf Of Peter Senna Tschudin > Sent: Monday, January 2, 2017 9:26 AM > Cc: Hannu Lounento ; Peter Senna Tschudin > ; Kirsher, Jeffrey T > ; moderated list:INTEL ETHERNET DRIVERS > ; open list:NETWORKING DRIVERS > ; open list > Subject: [PATCH 1/1] igb: Fix hw_dbg logging in igb_update_flash_i210 > > From: Hannu Lounento > > Fix an if statement with hw_dbg lines where the logic was inverted with > regards to the corresponding return value used in the if statement. > > Signed-off-by: Hannu Lounento > Signed-off-by: Peter Senna Tschudin > --- > drivers/net/ethernet/intel/igb/e1000_i210.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) Tested-by: Aaron Brown
RE: [Intel-wired-lan] [PATCH net v2] e1000e: keep vlan interfaces functional after rxvlan off
> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@lists.osuosl.org] On > Behalf Of Jarod Wilson > Sent: Thursday, June 9, 2016 4:50 PM > To: linux-kernel@vger.kernel.org > Cc: net...@vger.kernel.org; intel-wired-...@lists.osuosl.org > Subject: [Intel-wired-lan] [PATCH net v2] e1000e: keep vlan interfaces > functional after rxvlan off > > I've got a bug report about an e1000e interface, where a vlan interface is > set up on top of it: > > $ ip link add link ens1f0 name ens1f0.99 type vlan id 99 > $ ip link set ens1f0 up > $ ip link set ens1f0.99 up > $ ip addr add 192.168.99.92 dev ens1f0.99 > > At this point, I can ping another host on vlan 99, ip 192.168.99.91. > However, if I do the following: > > $ ethtool -K ens1f0 rxvlan off > > Then no traffic passes on ens1f0.99. It comes back if I toggle rxvlan on > again. Upon discussion with folks here, and closer inspection, it appears > that the software *receive* fallback is working correctly, but outbound > traffic is broken. Upon glancing at the e1000 driver, I saw a note about > having to keep RX and TX accel flags in sync, because there's no > (hardware?) support for separate vlan accel toggle. Swipe the same hack > from the e1000 driver, and things start to behave again with rxvlan off. > > After patch: > > $ ping 192.168.99.91 > PING 192.168.99.91 (192.168.99.91) 56(84) bytes of data. > 64 bytes from 192.168.99.91: icmp_seq=1 ttl=64 time=0.591 ms > 64 bytes from 192.168.99.91: icmp_seq=2 ttl=64 time=0.335 ms > 64 bytes from 192.168.99.91: icmp_seq=3 ttl=64 time=0.417 ms > ^C > --- 192.168.99.91 ping statistics --- > 3 packets transmitted, 3 received, 0% packet loss, time 2000ms > rtt min/avg/max/mdev = 0.335/0.447/0.591/0.109 ms > > $ sudo ethtool -K ens1f0 rxvlan off > Actual changes: > rx-vlan-offload: off > tx-vlan-offload: off [requested on] > > $ ping 192.168.99.91 > PING 192.168.99.91 (192.168.99.91) 56(84) bytes of data. > 64 bytes from 192.168.99.91: icmp_seq=1 ttl=64 time=0.327 ms > 64 bytes from 192.168.99.91: icmp_seq=2 ttl=64 time=0.393 ms > 64 bytes from 192.168.99.91: icmp_seq=3 ttl=64 time=0.424 ms > ^C > --- 192.168.99.91 ping statistics --- > 3 packets transmitted, 3 received, 0% packet loss, time 1999ms > rtt min/avg/max/mdev = 0.327/0.381/0.424/0.043 ms > > Also slipped a related-ish fix to the kerneldoc text for > e1000e_vlan_strip_disable here... > > CC: Jeff Kirsher > CC: intel-wired-...@lists.osuosl.org > CC: net...@vger.kernel.org > Signed-off-by: Jarod Wilson > --- > drivers/net/ethernet/intel/e1000e/netdev.c | 10 +- > 1 file changed, 9 insertions(+), 1 deletion(-) Tested-by: Aaron Brown
RE: [PATCH] e1000e: x86: e1000 driver trying to free already-free irq.
> From: netdev-ow...@vger.kernel.org [mailto:netdev- > ow...@vger.kernel.org] On Behalf Of David Singleton > Sent: Monday, October 17, 2016 9:51 AM > To: Kirsher, Jeffrey T > Cc: khalidm ; intel-wired-...@lists.osuosl.org; > net...@vger.kernel.org; linux-kernel@vger.kernel.org > Subject: [PATCH] e1000e: x86: e1000 driver trying to free already-free irq. > > From: khalidm > > During systemd reboot sequence network driver interface is shutdown > by e1000_close. The PCI driver interface is shut by e1000_shutdown. > The e1000_shutdown checks for netif_running status, if still up it > brings down driver. But it disables msi outside of this if statement, > regardless of netif status. All this is OK when e1000_close happens > after shutdown. However, by default, everything in systemd is done > in parallel. This creates a conditions where e1000_shutdown is called > after e1000_close, therefore hitting BUG_ON assert in free_msi_irqs. > > Cc-Id: xe-ker...@external.cisco.com > Signed-off-by: khalidm > Signed-off-by: David Singleton > --- > drivers/net/ethernet/intel/e1000e/netdev.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Tested-by: Aaron Brown
RE: [PATCH] igb: Workaround for igb i210 firmware issue.
> From: netdev-ow...@vger.kernel.org [mailto:netdev- > ow...@vger.kernel.org] On Behalf Of Chris J Arges > Sent: Wednesday, November 2, 2016 7:14 AM > To: j...@henneberg-systemdesign.com > Cc: intel-wired-...@lists.osuosl.org; Chris J Arges > ; Kirsher, Jeffrey T > ; net...@vger.kernel.org; linux- > ker...@vger.kernel.org > Subject: [PATCH] igb: Workaround for igb i210 firmware issue. > > Sometimes firmware may not properly initialize I347AT4_PAGE_SELECT > causing > the probe of an igb i210 NIC to fail. This patch adds an addition zeroing of > this register during igb_get_phy_id to workaround this issue. > > Thanks for Jochen Henneberg for the idea and original patch. > > Signed-off-by: Chris J Arges > --- > drivers/net/ethernet/intel/igb/e1000_phy.c | 4 > 1 file changed, 4 insertions(+) Tested-by: Aaron Brown
RE: [PATCH] igb/e1000: correct register comments
> From: netdev-ow...@vger.kernel.org [mailto:netdev- > ow...@vger.kernel.org] On Behalf Of Cao jin > Sent: Wednesday, November 2, 2016 12:20 AM > To: linux-kernel@vger.kernel.org; net...@vger.kernel.org > Cc: intel-wired-...@lists.osuosl.org; Kirsher, Jeffrey T > > Subject: [PATCH] igb/e1000: correct register comments > > Signed-off-by: Cao jin > --- > drivers/net/ethernet/intel/igb/e1000_regs.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Tested-by: Aaron Brown
RE: Kernel regression introduced by "e1000e: Do not write lsc to ics in msi-x mode" and/or "e1000e: Do not read ICR in Other interrupt"
> From: Jack Suter [mailto:j...@suter.io] > Sent: Tuesday, November 1, 2016 4:57 PM > To: Kirsher, Jeffrey T > Cc: intel-wired-...@lists.osuosl.org; bpoir...@suse.com; Brown, Aaron F > ; jhod...@ucdavis.edu; linux- > ker...@vger.kernel.org > Subject: Kernel regression introduced by "e1000e: Do not write lsc to ics in > msi-x mode" and/or "e1000e: Do not read ICR in Other interrupt" > > Hi there, > > I have some servers with an 82574L based NIC and recently upgraded from > a 4.4 series kernel to 4.7. Upon doing so, servers with this chipset > have begun frequently reporting "Link is Down" and "Link is Up" > messages. No other related network errors are reported by the kernel or > e1000e driver. I saw some reports about using "ethtool -s $iface msglvl > 6" to reveal more information, but nothing extra was reported. > > Some testing showed that this was introduced between the 4.4 and 4.5 > series. I was able to further narrow it down to two commits that look > related: > > e1000e: Do not write lsc to ics in msi-x mode > (a61cfe4ffad7864a07e0c74969ca7ceb77ab2f1f) > e1000e: Do not read ICR in Other interrupt > (16ecba59bc333d6282ee057fb02339f77a880beb) I did not notice any link flapping when I tested those patches, I would have rejected them if I had. I have several systems with 82574L LOMs and as yet am not able to reproduce a link flap with recent upstream kernels/drivers (net-next 4.8.0 on one and 4.9.0-rc3 on another.) One of those systems is dedicated to a kernel regression setup, I checked the test logs from it and am not seeing any evidence of flaps in the 4.4, through 4.6 range either. > > Reverting these two commits resolves the Link is Down/Link is Up > messages. This has been tested on about six servers so far and all have > stopped reporting these link flaps. Are you able to revert either of the patches independently, I don't recall if they were stand alone or not. > > In total I have about ten servers that are frequently seeing this issue, > and a couple dozen more triggering it sporadically. Are they all 82574L or does it affect others? > > This is about the extent of my troubleshooting knowledge so far. I am > happy to test code changes and provide any additional information as > necessary. While I do not understand what specifically causes the link > flaps, they reliably begin occurring on the affected servers within a > couple hours of boot. Is there any particular traffic pattern involved? Sitting idle, moderate use, heavy constant flow? > > A snip of one such instance is below. > > Thank you for any assistance troubleshooting this. Which kernel tree are you using? Linus's upstream kernel from kernel.org, a distribution provided one or? I'm generally working off of David Miller's net-next, but can try to repro the issue on my boxes if I know the exact kernel to work from. Perhaps a power saving state trying to kick in? Bad cables or speed/duplex mismatches are common causes of link flap, but they seem unlikely given reverting the patches resolves the issue. Those patches are interrupt related, what kind of interrupts are in use? What is interrupt moderation (coalescing set to)? What is the link partner? Same type switch for all problem machines or a mix? cat /proc/interrupts ethtool -c enp2s0 maybe an `lspci` dump could help shed some more light. > > Kind regards, > > Jack Suter > > # ethtool -i enp2s0 > driver: e1000e > version: 3.2.6-k > firmware-version: 2.1-2 > bus-info: :02:00.0 > supports-statistics: yes > supports-test: yes > supports-eeprom-access: yes > supports-register-dump: yes > supports-priv-flags: no > > [ 3532.745587] e1000e: enp2s0 NIC Link is Down > [ 3532.771461] e1000e: enp2s0 NIC Link is Up 1000 Mbps Full Duplex, Flow > Control: Rx/Tx > [15463.117592] e1000e: enp2s0 NIC Link is Down > [15463.119419] e1000e: enp2s0 NIC Link is Up 1000 Mbps Full Duplex, Flow > Control: Rx/Tx > [15469.155922] e1000e: enp2s0 NIC Link is Up 1000 Mbps Full Duplex, Flow > Control: Rx/Tx > [15648.196579] e1000e: enp2s0 NIC Link is Down > [15651.405310] e1000e: enp2s0 NIC Link is Up 1000 Mbps Full Duplex, Flow > Control: Rx/Tx > [15728.959981] e1000e: enp2s0 NIC Link is Down > [15729.000625] e1000e: enp2s0 NIC Link is Up 1000 Mbps Full Duplex, Flow > Control: Rx/Tx > [15835.132034] e1000e: enp2s0 NIC Link is Down > [15835.185222] e1000e: enp2s0 NIC Link is Up 1000 Mbps Full Duplex, Flow > Control: Rx/Tx > [15839.104020] e1000e: enp2s0 NIC Link is Down > [15839.142346] e1000e: enp2s0 NIC Link is Up 1000 Mbps Full Duplex, Flow > Control: Rx/Tx > [15845.142287] e1000e: enp2s0 NIC Link is Up 1000 Mbps Full Duplex, Flow > Control
RE: [PATCH] e1000e: fix timing for 82579 Gigabit Ethernet controller
> From: netdev-ow...@vger.kernel.org [mailto:netdev- > ow...@vger.kernel.org] On Behalf Of Bernd Faust > Sent: Thursday, February 16, 2017 10:42 AM > To: Kirsher, Jeffrey T ; Lubetkin, YanirX > ; intel-wired-...@lists.osuosl.org; > net...@vger.kernel.org; linux-kernel@vger.kernel.org > Cc: Bernd Faust > Subject: [PATCH] e1000e: fix timing for 82579 Gigabit Ethernet controller > > After an upgrade to Linux kernel v4.x the hardware timestamps of the > 82579 Gigabit Ethernet Controller are different than expected. > The values that are being read are almost four times as big as before > the kernel upgrade. > > The difference is that after the upgrade the driver sets the clock > frequency to 25MHz, where before the upgrade it was set to 96MHz. Intel > confirmed that the correct frequency for this network adapter is 96MHz. > > Signed-off-by: Bernd Faust > --- > drivers/net/ethernet/intel/e1000e/netdev.c | 6 ++ > 1 file changed, 6 insertions(+) Tested-by: Aaron Brown
RE: [4.10][regression][PM] Oops pci_restore_msi_state() e1000e? (Re: [BUG] 4.11.0-rc1 panic on shutdown X61s)
> From: Shawn Starr [mailto:shawn.st...@rogers.com] > Sent: Tuesday, March 14, 2017 1:43 PM > To: linux-kernel@vger.kernel.org > Cc: Brown, Aaron F > Subject: Re: [4.10][regression][PM] Oops pci_restore_msi_state() e1000e? > (Re: [BUG] 4.11.0-rc1 panic on shutdown X61s) > > This isn't just Lenovo, > > My Dell laptop experiences same problem, there is bugzilla: > > https://bugzilla.kernel.org/show_bug.cgi?id=194801 Yes, I had noticed a Dell laptop in one of the reports in addition to the Thinkpads. As it turns out one of the systems I have been trying to reproduce it on is a Lenova with an 82677LM, a newer chipset than the one Vito Caputo is seeing the problem on (82566) and a slightly older one than the one Boris Petkov reported (82579LM.) I also have been trying with a SuperMicro that has an 82579LM that matches Boris's lspci output very closely and still have not managed to trigger it. I used the config Boris provided to build a kernel and tried it on those systems (and a number of other ones) and still have not succeeded in making it break. Given I've tried with the same config as one that's breaking and the range of chipsets it is appearing on I'm suspicious it's more to do with the system environment than the exact kernel config or e1000e chipset, but really don't know. If I try to pursue it more I guess I'll try installing a Debian build on some of the systems. Regardless, Sasha Neftin weighed in on it agreeing it needs to be reverted and the upstream people were included, so hopefully it will get reverted in one of the next dot releases. -Aaron
RE: [BUG] 4.11.0-rc1 panic on shutdown X61s
> From: Bjørn Mork [mailto:bj...@mork.no]
> Sent: Monday, March 13, 2017 9:46 AM
> To: Borislav Petkov
> Cc: Andy Shevchenko ; l...@pengaru.com;
> linux-kernel ; vcap...@pengaru.com; linux-
> p...@vger.kernel.org; intel-wired-...@lists.osuosl.org; khalidm
> ; David Singleton ; Brown, Aaron
> F ; Kirsher, Jeffrey T
>
> Subject: Re: [BUG] 4.11.0-rc1 panic on shutdown X61s
>
> Borislav Petkov writes:
> > On Sun, Mar 12, 2017 at 03:55:08PM +0200, Andy Shevchenko wrote:
> >
> >> The only change that IMHO matters happened between v4.10 and v4.11-
> rc1 is this:
> >>
> >> @@ -6276,8 +6274,8 @@ static int e1000e_pm_freeze(struct device *dev)
> >> /* Quiesce the device without resetting the hardware */
> >> e1000e_down(adapter, false);
> >> e1000_free_irq(adapter);
> >> + e1000e_reset_interrupt_capability(adapter);
> >> }
> >> - e1000e_reset_interrupt_capability(adapter);
> >>
> >> So, it apparently misses something for the other case, like
> >> pci_disable_msi() call or so.
> >
> > Well, lemme add the people from
> >
> > 7e54d9d063fa ("e1000e: driver trying to free already-free irq")
> >
> > to CC then. :-)
>
> Already did that a week ago:
> https://www.spinics.net/lists/netdev/msg423379.html
>
> Haven't heard anything back yet. Wondering if they are waiting for
> someone else to submit the pretty obvious revert? Don't understand why
> that should take more than a minute to figure out. It's not like they
> are testing these changes anyway...
Believe it or not we actually do test these changes. This one was tested by me
and I did not have the same results you and the other people reporting this
trace did. I made it back in the lab today and have spent a good part of the
day attempting to reproduce this bug without success. Freeze / resume works
for me on all the systems I have tried, which includes a sampling of all the
current parts and many older ones. Given there are several other reports of
this it is obviously an issue and I would like to be able to reproduce it in
case another patch to resolve the issue this attempts to fix comes back in
another form. So I want to know what's different between the systems that hit
this and my bank of systems that don't.
What exact part (or parts) are we looking at (lspci|grep -i eth) that trigger
this? Could it be a difference in .config files? The trace says it is falling
back to legacy interrupts, does the system continue to work and does the
network continue to function in that mode? In case it's related to user space
what is the base distro? Any other information you think can help me reproduce
the issue would be appreciated.
Thanks,
Aaron
>
>
> Bjørn
RE: [Intel-wired-lan] [PATCH] net: intel: igb: use new api ethtool_{get|set}_link_ksettings
> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@lists.osuosl.org] On
> Behalf Of Philippe Reynes
> Sent: Sunday, February 5, 2017 9:56 AM
> To: Kirsher, Jeffrey T ; da...@davemloft.net
> Cc: net...@vger.kernel.org; intel-wired-...@lists.osuosl.org; linux-
> ker...@vger.kernel.org; Philippe Reynes
> Subject: [Intel-wired-lan] [PATCH] net: intel: igb: use new api
> ethtool_{get|set}_link_ksettings
>
> The ethtool api {get|set}_settings is deprecated.
> We move this driver to new api {get|set}_link_ksettings.
>
> As I don't have the hardware, I'd be very pleased if
> someone may test this patch.
>
> Signed-off-by: Philippe Reynes
> ---
> drivers/net/ethernet/intel/igb/igb_ethtool.c | 108 ++---
> -
> 1 files changed, 59 insertions(+), 49 deletions(-)
>
Tested-by: Aaron Brown
RE: [Intel-wired-lan] [PATCH] net: intel: igbvf: use new api ethtool_{get|set}_link_ksettings
> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@lists.osuosl.org] On
> Behalf Of Philippe Reynes
> Sent: Sunday, February 5, 2017 2:55 PM
> To: Kirsher, Jeffrey T ; da...@davemloft.net
> Cc: net...@vger.kernel.org; intel-wired-...@lists.osuosl.org; linux-
> ker...@vger.kernel.org; Philippe Reynes
> Subject: [Intel-wired-lan] [PATCH] net: intel: igbvf: use new api
> ethtool_{get|set}_link_ksettings
>
> The ethtool api {get|set}_settings is deprecated.
> We move this driver to new api {get|set}_link_ksettings.
>
> As I don't have the hardware, I'd be very pleased if
> someone may test this patch.
>
> Signed-off-by: Philippe Reynes
> ---
> drivers/net/ethernet/intel/igbvf/ethtool.c | 38
> ++--
> 1 files changed, 19 insertions(+), 19 deletions(-)
Tested-by: Aaron Brown
RE: [Intel-wired-lan] [PATCH] net: intel: ixgb: use new api ethtool_{get|set}_link_ksettings
> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@lists.osuosl.org] On
> Behalf Of Philippe Reynes
> Sent: Sunday, February 5, 2017 3:11 PM
> To: Kirsher, Jeffrey T ; da...@davemloft.net
> Cc: net...@vger.kernel.org; intel-wired-...@lists.osuosl.org; linux-
> ker...@vger.kernel.org; Philippe Reynes
> Subject: [Intel-wired-lan] [PATCH] net: intel: ixgb: use new api
> ethtool_{get|set}_link_ksettings
>
> The ethtool api {get|set}_settings is deprecated.
> We move this driver to new api {get|set}_link_ksettings.
>
> As I don't have the hardware, I'd be very pleased if
> someone may test this patch.
>
> Signed-off-by: Philippe Reynes
> ---
> drivers/net/ethernet/intel/ixgb/ixgb_ethtool.c | 39 ++-
> -
> 1 files changed, 23 insertions(+), 16 deletions(-)
>
Tested-by: Aaron Brown
Well, compile / static tested by: I probably have an ixgb adapter somewhere as
well as a PCI-X slot that might work for it, but am not sure I can find them or
that they still function. If I stumble upon one I'll fire it up and run it
through some paces, but the variant of this patch for other drivers seem good
and I don't want to hold this patch up any longer.
RE: [PATCH] net: intel: e1000e: use new api ethtool_{get|set}_link_ksettings
> From: netdev-ow...@vger.kernel.org [mailto:netdev-
> ow...@vger.kernel.org] On Behalf Of Philippe Reynes
> Sent: Thursday, January 26, 2017 1:20 PM
> To: Kirsher, Jeffrey T ; da...@davemloft.net
> Cc: intel-wired-...@lists.osuosl.org; net...@vger.kernel.org; linux-
> ker...@vger.kernel.org; Philippe Reynes
> Subject: [PATCH] net: intel: e1000e: use new api
> ethtool_{get|set}_link_ksettings
>
> The ethtool api {get|set}_settings is deprecated.
> We move this driver to new api {get|set}_link_ksettings.
>
> As I don't have the hardware, I'd be very pleased if
> someone may test this patch.
>
> Signed-off-by: Philippe Reynes
> ---
> drivers/net/ethernet/intel/e1000e/ethtool.c | 91 ++-
> ---
> 1 files changed, 49 insertions(+), 42 deletions(-)
Tested-by: Aaron Brown
RE: [PATCH] net: intel: e1000: use new api ethtool_{get|set}_link_ksettings
> From: netdev-ow...@vger.kernel.org [mailto:netdev-
> ow...@vger.kernel.org] On Behalf Of Philippe Reynes
> Sent: Saturday, January 21, 2017 7:06 AM
> To: Kirsher, Jeffrey T ; da...@davemloft.net
> Cc: intel-wired-...@lists.osuosl.org; net...@vger.kernel.org; linux-
> ker...@vger.kernel.org; Philippe Reynes
> Subject: [PATCH] net: intel: e1000: use new api
> ethtool_{get|set}_link_ksettings
>
> The ethtool api {get|set}_settings is deprecated.
> We move this driver to new api {get|set}_link_ksettings.
>
> As I don't have the hardware, I'd be very pleased if
> someone may test this patch.
>
> Signed-off-by: Philippe Reynes
> ---
> drivers/net/ethernet/intel/e1000/e1000_ethtool.c | 93 +++-
> --
> 1 files changed, 46 insertions(+), 47 deletions(-)
Tested-by: Aaron Brown
RE: [Intel-wired-lan] e1000e: PHY cann't be initialized correctly on some I218 controllers
> -Original Message- > From: Avargil, Raanan > Sent: Tuesday, August 9, 2016 8:11 AM > To: Denis Turischev ; intel-wired- > l...@lists.osuosl.org; Brown, Aaron F ; Kirsher, > Jeffrey T > Cc: net...@vger.kernel.org; linux-kernel@vger.kernel.org > Subject: Re: [Intel-wired-lan] e1000e: PHY cann't be initialized correctly on > some I218 controllers > > > > On 8/7/2016 11:56, Denis Turischev wrote: > > Hi Raanan, > > > > On 08/04/2016 07:18 PM, Raanan Avargil wrote: > >> It is hard to determine what is exactly the problem here and what causes > the -3 error, but this is not the place to perform hw reset and retry to init > the > phy. > > I agree that may be this is not the correct place for hw reset, can you > > advice > about another solution? > > > > It works, not only for me, for example it helps here: > > http://www.linux.org.ru/forum/linux-hardware/10268216 > > > > Another fact that Windows drivers work fine with the same hw. > > > > Denis > > > > Hi Denis, > > More suitable place to retry init the device would be in probe function. > However, we haven't seen initialization issues like this on i218. > > Adding Aaron. > > @Aaron - have you seen initialization errors on i218 devices? I have not. But I don't have many systems with i218 so all that means is my systems do not exhibit the problem. > > Raanan
RE: [Intel-wired-lan] [PATCH net-next v3 1/2] e1000e: factor out systim sanitization
> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@lists.osuosl.org] On > Behalf Of Jarod Wilson > Sent: Monday, August 1, 2016 6:32 PM > To: Avargil, Raanan > Cc: Hall, Christopher S ; > net...@vger.kernel.org; intel-wired-...@lists.osuosl.org; linux- > ker...@vger.kernel.org > Subject: Re: [Intel-wired-lan] [PATCH net-next v3 1/2] e1000e: factor out > systim sanitization > > On Wed, Jul 27, 2016 at 11:01:55AM -0400, Jarod Wilson wrote: > > On Wed, Jul 27, 2016 at 02:09:13PM +, Avargil, Raanan wrote: > > >> This is prepatory work for an expanding list of adapter families that > > >> have > occasional ~10 hour clock jumps when being used for PTP. Factor out the > sanitization function and convert to using a feature (bug) flag, per > suggestion > from Jesse Brandeburg. > > >> > > >> Littering functional code with device-specific checks is much messier > than simply checking a flag, and having device-specific init set flags as > needed. > > >> There are probably a number of other cases in the e1000e code that > could/should be converted similarly. > > > > > > Looks ok to me. > > > Adding Chris who asked what happens if we reach the max retry counter > (E1000_MAX_82574_SYSTIM_REREAD)? > > > This counter is set to 50. > > > Can you, for testing purposes, decreased this value (or even set it to 0) > and see what happens? > > > > Unfortunately, I don't have direct access to the affected hardware myself, > > so I'd have to prep a test build, hand it off to someone and play relay. I > > could do that, but it'd have some lag and possible multiple round-trips... > > Anyone inside Intel have hardware handy to test on? :p > > Was tied up with other work the middle of last week, then on vacation for > a bit. There was some testing feedback provided from someone at neither > Red Hat or Intel, but I'm not sure where it leaves us right now. What > needs to happen next? Probably nothing else needs to be done on your end. I was out for the last week and a half and am now running the patches through a series of regression test covering a fair number of the different e1000e parts. I will also try to duplicate Tim Woodford' success on a NUC with an i218 in my lab. Assuming nothing jumps out at me I'll probably give it a tested-by later this week so that Jeff can push it on up. > > -- > Jarod Wilson > ja...@redhat.com > > ___ > Intel-wired-lan mailing list > intel-wired-...@lists.osuosl.org > http://lists.osuosl.org/mailman/listinfo/intel-wired-lan
RE: [PATCH] igb: Fix a deadlock in igb_sriov_reinit
> From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org] > On Behalf Of Jia-Ju Bai > Sent: Sunday, August 02, 2015 8:36 PM > To: Kirsher, Jeffrey T; Brandeburg, Jesse > Cc: intel-wired-...@lists.osuosl.org; net...@vger.kernel.org; linux- > ker...@vger.kernel.org; Jia-Ju Bai > Subject: [PATCH] igb: Fix a deadlock in igb_sriov_reinit > > When igb_init_interrupt_scheme in igb_sriov_reinit is failed, the lock > acquired by rtnl_lock() is not released, which causes a deadlock. > This patch adds rtnl_unlock() in error handling to fix it. > > Signed-off-by: Jia-Ju Bai > --- > drivers/net/ethernet/intel/igb/igb_main.c |1 + > 1 file changed, 1 insertion(+) Tested-by: Aaron Brown -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [Intel-wired-lan] [PATCH 1/2] igb: Teardown SR-IOV before unregister_netdev()
> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@lists.osuosl.org] On > Behalf Of Alex Williamson > Sent: Monday, July 27, 2015 4:19 PM > To: intel-wired-...@lists.osuosl.org; Kirsher, Jeffrey T > Cc: net...@vger.kernel.org; linux-kernel@vger.kernel.org > Subject: [Intel-wired-lan] [PATCH 1/2] igb: Teardown SR-IOV before > unregister_netdev() > > When the .remove() callback for a PF is called, SR-IOV support for the > device is disabled, which requires unbinding and removing the VFs. > The VFs may be in-use either by the host kernel or userspace, such as > assigned to a VM through vfio-pci. In this latter case, the VFs may > be removed either by shutting down the VM or hot-unplugging the > devices from the VM. Unfortunately in the case of a Windows 2012 R2 > guest, hot-unplug is broken due to the ordering of the PF driver > teardown. Disabling SR-IOV prior to unregister_netdev() avoids this > issue. > > Signed-off-by: Alex Williamson > --- > drivers/net/ethernet/intel/igb/igb_main.c |8 > 1 file changed, 4 insertions(+), 4 deletions(-) Tested-by: Aaron Brown -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] igb: Fix a memory leak in igb_probe
> From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org] > On Behalf Of Jia-Ju Bai > Sent: Wednesday, August 05, 2015 7:05 AM > To: Kirsher, Jeffrey T; Brandeburg, Jesse > Cc: intel-wired-...@lists.osuosl.org; net...@vger.kernel.org; linux- > ker...@vger.kernel.org; Jia-Ju Bai > Subject: [PATCH] igb: Fix a memory leak in igb_probe > > In error handling code of igb_probe, the memory adapter->shadow_vfta > allocated by kcalloc in igb_sw_init is not freed. So when register_netdev > or igb_init_i2c is failed, a memory leak will occur. > This patch adds kfree to fix it. > > Signed-off-by: Jia-Ju Bai > --- > drivers/net/ethernet/intel/igb/igb_main.c |1 + > 1 file changed, 1 insertion(+) Tested-by: Aaron Brown -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [Intel-wired-lan] [PATCH v2 1/2] igb: Teardown SR-IOV before unregister_netdev()
> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@lists.osuosl.org] On > Behalf Of Alex Williamson > Sent: Wednesday, July 29, 2015 1:38 PM > To: intel-wired-...@lists.osuosl.org; da...@davemloft.net; Kirsher, > Jeffrey T > Cc: net...@vger.kernel.org; linux-kernel@vger.kernel.org > Subject: [Intel-wired-lan] [PATCH v2 1/2] igb: Teardown SR-IOV before > unregister_netdev() > > When the .remove() callback for a PF is called, SR-IOV support for the > device is disabled, which requires unbinding and removing the VFs. > The VFs may be in-use either by the host kernel or userspace, such as > assigned to a VM through vfio-pci. In this latter case, the VFs may > be removed either by shutting down the VM or hot-unplugging the > devices from the VM. Unfortunately in the case of a Windows 2012 R2 > guest, hot-unplug is broken due to the ordering of the PF driver > teardown. Disabling SR-IOV prior to unregister_netdev() avoids this > issue. > > Signed-off-by: Alex Williamson > Acked-by: Mitch Williams > --- > drivers/net/ethernet/intel/igb/igb_main.c |8 > 1 file changed, 4 insertions(+), 4 deletions(-) Tested-by: Aaron Brown -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [net] igbvf: remove "link is Up" message when registering mcast address
> From: netdev-ow...@vger.kernel.org [netdev-ow...@vger.kernel.org] on behalf > of Jon Maxwell [jmaxwel...@gmail.com] > Sent: Sunday, January 24, 2016 3:22 PM > To: Kirsher, Jeffrey T > Cc: da...@davemloft.net; jmaxw...@redhat.com; vinsc...@redhat.com; > intel-wired-...@lists.osuosl.org; net...@vger.kernel.org; > linux-kernel@vger.kernel.org; Jon Maxwell > Subject: [net] igbvf: remove "link is Up" message when registering mcast > address > > A similar issue was addressed a few years ago in the following thread: > > http://www.spinics.net/lists/netdev/msg245877.html > > At that time there were concerns that removing this statement may cause other > side effects. However the submitter addressed those concerns. But the dialogue > went cold. We have a new case where a customers application is registering and > un-registering multicast addresses every few seconds. This is leading to many > "Link is Up" messages in the logs as a result of the > "netif_carrier_off(netdev)" statement called by igbvf_msix_other(). Also on > some kernels it is interfering with the bonding driver causing it to failover > and subsequently affecting connectivity. > > The Sourgeforge driver does not make this call and is therefore not affected. > If there were any side effects I would expect that driver to also be affected. > I have tested re-loading the igbvf driver and downing the adapter with the PF > entity on the host where the VM has this patch. When I bring it back up again > connectivity is restored as expected. Therefore I request that this patch gets > submitted. > > Signed-off-by: Jon Maxwell > --- > drivers/net/ethernet/intel/igbvf/netdev.c | 1 - > 1 file changed, 1 deletion(-) > Tested-by: Aaron Brown
RE: [Intel-wired-lan] [PATCH 2/3] e1000e: Add Dell's Comet Lake systems into s0ix heuristics
> From: Intel-wired-lan On Behalf Of
> Mario Limonciello
> Sent: Sunday, September 27, 2020 9:40 PM
> To: Kirsher, Jeffrey T ; intel-wired-
> l...@lists.osuosl.org
> Cc: perry.y...@dell.com; yijun.s...@dell.com; linux-kernel@vger.kernel.org;
> Mario Limonciello
> Subject: [Intel-wired-lan] [PATCH 2/3] e1000e: Add Dell's Comet Lake systems
> into s0ix heuristics
>
> Dell's Comet Lake Latitude and Precision systems containing i219LM are
> properly configured and should use the s0ix flows.
>
> Signed-off-by: Mario Limonciello
> ---
> drivers/net/ethernet/intel/Kconfig| 1 +
> drivers/net/ethernet/intel/e1000e/param.c | 80 ++-
> 2 files changed, 80 insertions(+), 1 deletion(-)
Is there anyone who touched this hardware with this patch willing to provide a
Tested-by:?
I am happy to do regression / sanity checks against other e1000e based systems,
but do not have access to these devices.
>
> diff --git a/drivers/net/ethernet/intel/Kconfig
> b/drivers/net/ethernet/intel/Kconfig
> index 5aa86318ed3e..280af47d74d2 100644
> --- a/drivers/net/ethernet/intel/Kconfig
> +++ b/drivers/net/ethernet/intel/Kconfig
> @@ -58,6 +58,7 @@ config E1000
> config E1000E
> tristate "Intel(R) PRO/1000 PCI-Express Gigabit Ethernet support"
> depends on PCI && (!SPARC32 || BROKEN)
> + depends on DMI
> select CRC32
> imply PTP_1588_CLOCK
> help
> diff --git a/drivers/net/ethernet/intel/e1000e/param.c
> b/drivers/net/ethernet/intel/e1000e/param.c
> index e66b222c824b..58e6718c4f75 100644
> --- a/drivers/net/ethernet/intel/e1000e/param.c
> +++ b/drivers/net/ethernet/intel/e1000e/param.c
> @@ -1,6 +1,7 @@
> // SPDX-License-Identifier: GPL-2.0
> /* Copyright(c) 1999 - 2018 Intel Corporation. */
>
> +#include
> #include
> #include
> #include
> @@ -201,6 +202,80 @@ static const struct e1000e_me_supported
> me_supported[] = {
> {0}
> };
>
> +static const struct dmi_system_id s0ix_supported_systems[] = {
> + {
> + /* Dell Latitude 5310 */
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
> + DMI_MATCH(DMI_PRODUCT_SKU, "099F"),
> + },
> + },
> + {
> + /* Dell Latitude 5410 */
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
> + DMI_MATCH(DMI_PRODUCT_SKU, "09A0"),
> + },
> + },
> + {
> + /* Dell Latitude 5410 */
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
> + DMI_MATCH(DMI_PRODUCT_SKU, "09C9"),
> + },
> + },
> + {
> + /* Dell Latitude 5510 */
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
> + DMI_MATCH(DMI_PRODUCT_SKU, "09A1"),
> + },
> + },
> + {
> + /* Dell Precision 3550 */
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
> + DMI_MATCH(DMI_PRODUCT_SKU, "09A2"),
> + },
> + },
> + {
> + /* Dell Latitude 5411 */
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
> + DMI_MATCH(DMI_PRODUCT_SKU, "09C0"),
> + },
> + },
> + {
> + /* Dell Latitude 5511 */
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
> + DMI_MATCH(DMI_PRODUCT_SKU, "09C1"),
> + },
> + },
> + {
> + /* Dell Precision 3551 */
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
> + DMI_MATCH(DMI_PRODUCT_SKU, "09C2"),
> + },
> + },
> + {
> + /* Dell Precision 7550 */
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
> + DMI_MATCH(DMI_PRODUCT_SKU, "09C3"),
> + },
> + },
> + {
> + /* Dell Precision 7750 */
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
> + DMI_MATCH(DMI_PRODUCT_SKU, "09C4"),
> + },
> + },
> + { }
> +};
> +
> static bool e1000e_check_me(u16 device_id)
> {
> struct e1000e_me_supported *id;
> @@ -599,8 +674,11 @@ void e1000e_check_options(struct e1000_adapter
> *adapter)
> }
>
> if (enabled == S0IX_HEURISTICS) {
> + /* check for allowlist of systems */
> + if (dmi_check_system(s0ix_supported_systems))
> + enabled = S0IX_FORCE_ON;
> /* default to off for ME configurations */
> - if (e1000e_check_me(hw->adapter->pdev->device))
> + else if (e1000e_check_me(hw->adapter->pdev-
>
RE: [Intel-wired-lan] [PATCH 3/3] e1000e: Add more Dell CML systems into s0ix heuristics
> From: Intel-wired-lan On Behalf Of
> Mario Limonciello
> Sent: Sunday, September 27, 2020 9:40 PM
> To: Kirsher, Jeffrey T ; intel-wired-
> l...@lists.osuosl.org
> Cc: perry.y...@dell.com; yijun.s...@dell.com; linux-
> ker...@vger.kernel.org; Mario Limonciello
> Subject: [Intel-wired-lan] [PATCH 3/3] e1000e: Add more Dell CML systems
> into s0ix heuristics
>
> These comet lake systems are not yet released, but have been validated
> on pre-release hardware.
Same basic question as with 2/3 of the series, would it be possible to get
someone who touched / validated the code on the pre-release hardware to provide
a Tested-by: to this patch?
>
> This is being submitted separately from released hardware in case of
> a regression between pre-release and release hardware so this commit
> can be reverted alone.
>
> Signed-off-by: Mario Limonciello
> ---
> drivers/net/ethernet/intel/e1000e/param.c | 21 +
> 1 file changed, 21 insertions(+)
>
> diff --git a/drivers/net/ethernet/intel/e1000e/param.c
> b/drivers/net/ethernet/intel/e1000e/param.c
> index 58e6718c4f75..fe3157c8aa4a 100644
> --- a/drivers/net/ethernet/intel/e1000e/param.c
> +++ b/drivers/net/ethernet/intel/e1000e/param.c
> @@ -273,6 +273,27 @@ static const struct dmi_system_id
> s0ix_supported_systems[] = {
> DMI_MATCH(DMI_PRODUCT_SKU, "09C4"),
> },
> },
> + {
> + /* Dell Notebook 0x0A40 */
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
> + DMI_MATCH(DMI_PRODUCT_SKU, "0A40"),
> + },
> + },
> + {
> + /* Dell Notebook 0x0A41 */
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
> + DMI_MATCH(DMI_PRODUCT_SKU, "0A41"),
> + },
> + },
> + {
> + /* Dell Notebook 0x0A42 */
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
> + DMI_MATCH(DMI_PRODUCT_SKU, "0A42"),
> + },
> + },
> { }
> };
>
> --
> 2.25.1
>
> ___
> Intel-wired-lan mailing list
> intel-wired-...@osuosl.org
> https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
RE: [Intel-wired-lan] [PATCH] e1000: do not panic on malformed rx_desc
> From: Intel-wired-lan On Behalf Of Tong > Zhang > Sent: Tuesday, September 8, 2020 9:23 AM > To: Kirsher, Jeffrey T ; David S. Miller > ; Jakub Kicinski ; intel-wired- > l...@lists.osuosl.org; net...@vger.kernel.org; linux-kernel@vger.kernel.org > Cc: ztong0...@gmail.com > Subject: [Intel-wired-lan] [PATCH] e1000: do not panic on malformed rx_desc > > length may be corrupted in rx_desc and lead to panic, so check the > sanity before passing it to skb_put > > [ 167.667701] skbuff: skb_over_panic: text:b1e32cc1 len:60224 > put:60224 head:888055ac5000 data:888055ac5040 tail:0xeb80 end:0x6c0 > dev:e > th0 > [ 167.668429] [ cut here ] > [ 167.668661] kernel BUG at net/core/skbuff.c:109! > [ 167.668910] invalid opcode: [#1] SMP DEBUG_PAGEALLOC KASAN PTI > [ 167.669220] CPU: 1 PID: 170 Comm: sd-resolve Tainted: GW > 5.8.0+ > #1 > [ 167.670161] RIP: 0010:skb_panic+0xc4/0xc6 > [ 167.670363] Code: 89 f0 48 c7 c7 60 f2 de b2 55 48 8b 74 24 18 4d 89 f9 56 > 48 > 8b 54 24 18 4c 89 e6 52 48 8b 44 24 18 4c 89 ea 50 e8 31 c5 2a ff <0f> > 0b 4c 8b 64 24 18 e8 f1 b4 48 ff 48 c7 c1 00 fc de b2 44 89 ee > [ 167.671272] RSP: 0018:88806d109c68 EFLAGS: 00010286 > [ 167.671527] RAX: 008c RBX: 888065e9af40 RCX: > > [ 167.671878] RDX: 11100da24c91 RSI: 0008 RDI: > ed100da21380 > [ 167.672227] RBP: 88806bde4000 R08: 008c R09: > ed100da25cfb > [ 167.672583] R10: 88806d12e7d7 R11: ed100da25cfa R12: > b2defc40 > [ 167.672931] R13: b1e32cc1 R14: eb40 R15: > 888055ac5000 > [ 167.673286] FS: 7fc5f5375700() GS:88806d10() > knlGS: > [ 167.673681] CS: 0010 DS: ES: CR0: 80050033 > [ 167.673973] CR2: 00cb3008 CR3: 63d36000 CR4: > 06e0 > [ 167.674330] DR0: DR1: DR2: > > [ 167.674677] DR3: DR6: fffe0ff0 DR7: > 0400 > [ 167.675035] Call Trace: > [ 167.675168] > [ 167.675315] ? e1000_clean_rx_irq+0x311/0x630 > [ 167.687459] skb_put.cold+0x1f/0x1f > [ 167.687637] e1000_clean_rx_irq+0x311/0x630 > [ 167.687852] e1000e_poll+0x19a/0x4d0 > [ 167.688038] ? e1000_watchdog_task+0x9d0/0x9d0 > [ 167.688262] ? credit_entropy_bits.constprop.0+0x6f/0x1c0 > [ 167.688527] net_rx_action+0x26e/0x650 > > Signed-off-by: Tong Zhang > --- > drivers/net/ethernet/intel/e1000/e1000_main.c | 7 ++- > 1 file changed, 6 insertions(+), 1 deletion(-) Tested-by: Aaron Brown I was not able to trigger the panic prior to the patch, so just a regression check on several e1000 adapters.
RE: [Intel-wired-lan] [PATCH] e1000: do not panic on malformed rx_desc
> From: Intel-wired-lan On Behalf Of Tong > Zhang > Sent: Tuesday, September 8, 2020 9:23 AM > To: Kirsher, Jeffrey T ; David S. Miller > ; Jakub Kicinski ; intel-wired- > l...@lists.osuosl.org; net...@vger.kernel.org; linux-kernel@vger.kernel.org > Cc: ztong0...@gmail.com > Subject: [Intel-wired-lan] [PATCH] e1000: do not panic on malformed rx_desc > > length may be corrupted in rx_desc and lead to panic, so check the > sanity before passing it to skb_put > > [ 167.667701] skbuff: skb_over_panic: text:b1e32cc1 len:60224 > put:60224 head:888055ac5000 data:888055ac5040 tail:0xeb80 end:0x6c0 > dev:e > th0 > [ 167.668429] [ cut here ] > [ 167.668661] kernel BUG at net/core/skbuff.c:109! > [ 167.668910] invalid opcode: [#1] SMP DEBUG_PAGEALLOC KASAN PTI > [ 167.669220] CPU: 1 PID: 170 Comm: sd-resolve Tainted: GW > 5.8.0+ > #1 > [ 167.670161] RIP: 0010:skb_panic+0xc4/0xc6 > [ 167.670363] Code: 89 f0 48 c7 c7 60 f2 de b2 55 48 8b 74 24 18 4d 89 f9 56 > 48 > 8b 54 24 18 4c 89 e6 52 48 8b 44 24 18 4c 89 ea 50 e8 31 c5 2a ff <0f> > 0b 4c 8b 64 24 18 e8 f1 b4 48 ff 48 c7 c1 00 fc de b2 44 89 ee > [ 167.671272] RSP: 0018:88806d109c68 EFLAGS: 00010286 > [ 167.671527] RAX: 008c RBX: 888065e9af40 RCX: > > [ 167.671878] RDX: 11100da24c91 RSI: 0008 RDI: > ed100da21380 > [ 167.672227] RBP: 88806bde4000 R08: 008c R09: > ed100da25cfb > [ 167.672583] R10: 88806d12e7d7 R11: ed100da25cfa R12: > b2defc40 > [ 167.672931] R13: b1e32cc1 R14: eb40 R15: > 888055ac5000 > [ 167.673286] FS: 7fc5f5375700() GS:88806d10() > knlGS: > [ 167.673681] CS: 0010 DS: ES: CR0: 80050033 > [ 167.673973] CR2: 00cb3008 CR3: 63d36000 CR4: > 06e0 > [ 167.674330] DR0: DR1: DR2: > > [ 167.674677] DR3: DR6: fffe0ff0 DR7: > 0400 > [ 167.675035] Call Trace: > [ 167.675168] > [ 167.675315] ? e1000_clean_rx_irq+0x311/0x630 > [ 167.687459] skb_put.cold+0x1f/0x1f > [ 167.687637] e1000_clean_rx_irq+0x311/0x630 > [ 167.687852] e1000e_poll+0x19a/0x4d0 > [ 167.688038] ? e1000_watchdog_task+0x9d0/0x9d0 > [ 167.688262] ? credit_entropy_bits.constprop.0+0x6f/0x1c0 > [ 167.688527] net_rx_action+0x26e/0x650 > > Signed-off-by: Tong Zhang > --- > drivers/net/ethernet/intel/e1000/e1000_main.c | 7 ++- > 1 file changed, 6 insertions(+), 1 deletion(-) Tested-by: Aaron Brown Again, regression tested. I was not able to trigger the panic with or without patch.
RE: [Intel-wired-lan] [PATCH] e100: switch from 'pci_' to 'dma_' API
> From: Intel-wired-lan On Behalf Of > Christophe JAILLET > Sent: Saturday, July 18, 2020 4:56 AM > To: k...@kernel.org; da...@davemloft.net; Kirsher, Jeffrey T > > Cc: net...@vger.kernel.org; kernel-janit...@vger.kernel.org; Christophe > JAILLET ; intel-wired-...@lists.osuosl.org; > linux-kernel@vger.kernel.org > Subject: [Intel-wired-lan] [PATCH] e100: switch from 'pci_' to 'dma_' API > > The wrappers in include/linux/pci-dma-compat.h should go away. > > The patch has been generated with the coccinelle script below and has been > hand modified to replace GFP_ with a correct flag. > It has been compile tested. > > When memory is allocated in 'e100_alloc()', GFP_KERNEL can be used because > it is only called from the probe function and no lock is acquired. > > > @@ > @@ > -PCI_DMA_BIDIRECTIONAL > +DMA_BIDIRECTIONAL > > @@ > @@ > -PCI_DMA_TODEVICE > +DMA_TO_DEVICE > > @@ > @@ > -PCI_DMA_FROMDEVICE > +DMA_FROM_DEVICE > > @@ > @@ > -PCI_DMA_NONE > +DMA_NONE > > @@ > expression e1, e2, e3; > @@ > -pci_alloc_consistent(e1, e2, e3) > +dma_alloc_coherent(&e1->dev, e2, e3, GFP_) > > @@ > expression e1, e2, e3; > @@ > -pci_zalloc_consistent(e1, e2, e3) > +dma_alloc_coherent(&e1->dev, e2, e3, GFP_) > > @@ > expression e1, e2, e3, e4; > @@ > -pci_free_consistent(e1, e2, e3, e4) > +dma_free_coherent(&e1->dev, e2, e3, e4) > > @@ > expression e1, e2, e3, e4; > @@ > -pci_map_single(e1, e2, e3, e4) > +dma_map_single(&e1->dev, e2, e3, e4) > > @@ > expression e1, e2, e3, e4; > @@ > -pci_unmap_single(e1, e2, e3, e4) > +dma_unmap_single(&e1->dev, e2, e3, e4) > > @@ > expression e1, e2, e3, e4, e5; > @@ > -pci_map_page(e1, e2, e3, e4, e5) > +dma_map_page(&e1->dev, e2, e3, e4, e5) > > @@ > expression e1, e2, e3, e4; > @@ > -pci_unmap_page(e1, e2, e3, e4) > +dma_unmap_page(&e1->dev, e2, e3, e4) > > @@ > expression e1, e2, e3, e4; > @@ > -pci_map_sg(e1, e2, e3, e4) > +dma_map_sg(&e1->dev, e2, e3, e4) > > @@ > expression e1, e2, e3, e4; > @@ > -pci_unmap_sg(e1, e2, e3, e4) > +dma_unmap_sg(&e1->dev, e2, e3, e4) > > @@ > expression e1, e2, e3, e4; > @@ > -pci_dma_sync_single_for_cpu(e1, e2, e3, e4) > +dma_sync_single_for_cpu(&e1->dev, e2, e3, e4) > > @@ > expression e1, e2, e3, e4; > @@ > -pci_dma_sync_single_for_device(e1, e2, e3, e4) > +dma_sync_single_for_device(&e1->dev, e2, e3, e4) > > @@ > expression e1, e2, e3, e4; > @@ > -pci_dma_sync_sg_for_cpu(e1, e2, e3, e4) > +dma_sync_sg_for_cpu(&e1->dev, e2, e3, e4) > > @@ > expression e1, e2, e3, e4; > @@ > -pci_dma_sync_sg_for_device(e1, e2, e3, e4) > +dma_sync_sg_for_device(&e1->dev, e2, e3, e4) > > @@ > expression e1, e2; > @@ > -pci_dma_mapping_error(e1, e2) > +dma_mapping_error(&e1->dev, e2) > > @@ > expression e1, e2; > @@ > -pci_set_dma_mask(e1, e2) > +dma_set_mask(&e1->dev, e2) > > @@ > expression e1, e2; > @@ > -pci_set_consistent_dma_mask(e1, e2) > +dma_set_coherent_mask(&e1->dev, e2) > > Signed-off-by: Christophe JAILLET > --- > If needed, see post from Christoph Hellwig on the kernel-janitors ML: >https://marc.info/?l=kernel-janitors&m=158745678307186&w=4 > --- > drivers/net/ethernet/intel/e100.c | 92 --- > 1 file changed, 49 insertions(+), 43 deletions(-) > And I finally managed to get a couple functional e100 adapters up and running again. Tested-by: Aaron Brown
RE: [PATCH] Fix typo in the comment
> From: Hari > Sent: Friday, May 22, 2020 3:30 AM > To: da...@davemloft.net; k...@kernel.org > Cc: Hari ; net...@vger.kernel.org; linux- > ker...@vger.kernel.org; intel-wired-...@lists.osuosl.org > Subject: [PATCH] Fix typo in the comment > > Continuous Double "the" in a comment. Changed it to single "the" > > Signed-off-by: Hari > --- > drivers/net/ethernet/intel/e1000/e1000_hw.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Tested-by: Aaron Brown
RE: [PATCH] igb: read PBA number from flash
> From: Gal Hammer > Sent: Saturday, August 29, 2020 10:45 PM > To: linux-kernel@vger.kernel.org > Cc: Kirsher, Jeffrey T ; David S . Miller > ; Jakub Kicinski ; intel-wired- > l...@lists.osuosl.org; net...@vger.kernel.org; Marcel Apfelbaum > ; Gal Hammer > Subject: [PATCH] igb: read PBA number from flash > > Fixed flash presence check for 82576 controllers so the part > number string is read and displayed correctly. > > Signed-off-by: Gal Hammer > --- > drivers/net/ethernet/intel/igb/igb_main.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > Tested-by: Aaron Brown
RE: [PATCH] ice: Fix memleak in ice_set_ringparam
> From: Dinghao Liu > Sent: Wednesday, August 26, 2020 7:34 PM > To: dinghao@zju.edu.cn; k...@umn.edu > Cc: Kirsher, Jeffrey T ; David S. Miller > ; Jakub Kicinski ; Alexei > Starovoitov ; Daniel Borkmann ; > Jesper Dangaard Brouer ; John Fastabend > ; intel-wired-...@lists.osuosl.org; > net...@vger.kernel.org; linux-kernel@vger.kernel.org; > b...@vger.kernel.org > Subject: [PATCH] ice: Fix memleak in ice_set_ringparam > > When kcalloc() on rx_rings fails, we should free tx_rings > and xdp_rings to prevent memleak. Similarly, when > ice_alloc_rx_bufs() fails, we should free xdp_rings. > > Signed-off-by: Dinghao Liu > --- > drivers/net/ethernet/intel/ice/ice_ethtool.c | 13 +++-- > 1 file changed, 11 insertions(+), 2 deletions(-) Tested-by: Aaron Brown
RE: [Intel-wired-lan] [PATCH 1/3] e1000e: allow turning s0ix flows on for systems with ME
> From: Intel-wired-lan On Behalf Of
> Mario Limonciello
> Sent: Sunday, September 27, 2020 9:40 PM
> To: Kirsher, Jeffrey T ; intel-wired-
> l...@lists.osuosl.org
> Cc: perry.y...@dell.com; yijun.s...@dell.com; linux-kernel@vger.kernel.org;
> Mario Limonciello
> Subject: [Intel-wired-lan] [PATCH 1/3] e1000e: allow turning s0ix flows on for
> systems with ME
>
> S0ix for GBE flows are needed for allowing the system to get into deepest
> power state, but these require coordination of components outside of
> control of Linux kernel. For systems that have confirmed to coordinate
> this properly, allow turning on the s0ix flows at load time or runtime.
>
> Fixes: e086ba2fccda ("e1000e: disable s0ix entry and exit flows for ME
> systems")
> Signed-off-by: Mario Limonciello
> ---
> .../device_drivers/ethernet/intel/e1000e.rst | 23
> drivers/net/ethernet/intel/e1000e/e1000.h | 7 ++
> drivers/net/ethernet/intel/e1000e/netdev.c| 64 +-
> drivers/net/ethernet/intel/e1000e/param.c | 110 ++
> 4 files changed, 166 insertions(+), 38 deletions(-)
>
Tested-by: Aaron Brown
RE: [Intel-wired-lan] [v4][PATCH] e1000e: continue to init phy even when failed to disable ULP
> From: Intel-wired-lan On Behalf Of
> Aaron Ma
> Sent: Wednesday, June 17, 2020 11:55 PM
> To: k...@kernel.org; Kirsher, Jeffrey T ;
> da...@davemloft.net; intel-wired-...@lists.osuosl.org;
> net...@vger.kernel.org; linux-kernel@vger.kernel.org; Lifshits, Vitaly
> ; kai.heng.f...@canonical.com; Neftin, Sasha
>
> Subject: [Intel-wired-lan] [v4][PATCH] e1000e: continue to init phy even when
> failed to disable ULP
>
> After 'commit e086ba2fccda4 ("e1000e: disable s0ix entry and exit flows
> for ME systems")',
> ThinkPad P14s always failed to disable ULP by ME.
> 'commit 0c80cdbf3320 ("e1000e: Warn if disabling ULP failed")'
> break out of init phy:
>
> error log:
> [ 42.364753] e1000e :00:1f.6 enp0s31f6: Failed to disable ULP
> [ 42.524626] e1000e :00:1f.6 enp0s31f6: PHY Wakeup cause - Unicast
> Packet
> [ 42.822476] e1000e :00:1f.6 enp0s31f6: Hardware Error
>
> When disable s0ix, E1000_FWSM_ULP_CFG_DONE will never be 1.
> If continue to init phy like before, it can work as before.
> iperf test result good too.
>
> Fixes: 0c80cdbf3320 ("e1000e: Warn if disabling ULP failed")
> Signed-off-by: Aaron Ma
> ---
> drivers/net/ethernet/intel/e1000e/ich8lan.c | 1 -
> 1 file changed, 1 deletion(-)
I never did find a system that triggered the initial problem, but from a
compatibility with the set of systems I do have working...
Tested-by: Aaron Brown
RE: [Intel-wired-lan] [PATCH v2] igb: reinit_locked() should be called with rtnl_lock
> From: Intel-wired-lan On Behalf Of
> Francesco Ruggeri
> Sent: Thursday, July 2, 2020 3:39 PM
> To: linux-kernel@vger.kernel.org; net...@vger.kernel.org; intel-wired-
> l...@lists.osuosl.org; k...@kernel.org; da...@davemloft.net; Kirsher, Jeffrey
> T ; frugg...@arista.com
> Subject: [Intel-wired-lan] [PATCH v2] igb: reinit_locked() should be called
> with
> rtnl_lock
>
> We observed two panics involving races with igb_reset_task.
> The first panic is caused by this race condition:
>
> kworker reboot -f
>
> igb_reset_task
> igb_reinit_locked
> igb_down
> napi_synchronize
> __igb_shutdown
> igb_clear_interrupt_scheme
> igb_free_q_vectors
> igb_free_q_vector
> adapter->q_vector[v_idx] = NULL;
> napi_disable
> Panics trying to access
> adapter->q_vector[v_idx].napi_state
>
> The second panic (a divide error) is caused by this race:
>
> kworker reboot -f tx packet
>
> igb_reset_task
> __igb_shutdown
> rtnl_lock()
> ...
> igb_clear_interrupt_scheme
> igb_free_q_vectors
> adapter->num_tx_queues = 0
> ...
> rtnl_unlock()
> rtnl_lock()
> igb_reinit_locked
> igb_down
> igb_up
> netif_tx_start_all_queues
> dev_hard_start_xmit
> igb_xmit_frame
> igb_tx_queue_mapping
> Panics on
> r_idx % adapter->num_tx_queues
>
> This commit applies to igb_reset_task the same changes that
> were applied to ixgbe in commit 2f90b8657ec9 ("ixgbe: this patch
> adds support for DCB to the kernel and ixgbe driver"),
> commit 8f4c5c9fb87a ("ixgbe: reinit_locked() should be called with
> rtnl_lock") and commit 88adce4ea8f9 ("ixgbe: fix possible race in
> reset subtask").
>
> v2: add fix for second race condition above.
>
> Signed-off-by: Francesco Ruggeri
>
> ---
> drivers/net/ethernet/intel/igb/igb_main.c | 9 +
> 1 file changed, 9 insertions(+)
Tested-by: Aaron Brown
RE: [PATCH 1/4] e1000/e1000_ethtool.c: Remove unnecessary usages of memset
> From: Suraj Upadhyay > Sent: Tuesday, July 14, 2020 12:41 PM > To: Kirsher, Jeffrey T ; da...@davemloft.net; > k...@kernel.org > Cc: intel-wired-...@lists.osuosl.org; net...@vger.kernel.org; linux- > ker...@vger.kernel.org; kernel-janit...@vger.kernel.org > Subject: [PATCH 1/4] e1000/e1000_ethtool.c: Remove unnecessary usages of > memset > > Replace memsets of 1 byte with simple assignments. > Issue reported by checkpatch.pl. > > Signed-off-by: Suraj Upadhyay > --- > drivers/net/ethernet/intel/e1000/e1000_ethtool.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > Tested-by: Aaron Brown
RE: [PATCH 2/4] e1000e/ethtool.c : Remove unnecessary usages of memset.
> From: Suraj Upadhyay > Sent: Tuesday, July 14, 2020 12:41 PM > To: Kirsher, Jeffrey T ; da...@davemloft.net; > k...@kernel.org > Cc: intel-wired-...@lists.osuosl.org; net...@vger.kernel.org; linux- > ker...@vger.kernel.org; kernel-janit...@vger.kernel.org > Subject: [PATCH 2/4] e1000e/ethtool.c : Remove unnecessary usages of > memset. > > Replace memsets of 1 byte with simple assignments. > Issue found with checkpatch.pl > > Signed-off-by: Suraj Upadhyay > --- > drivers/net/ethernet/intel/e1000e/ethtool.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > Tested-by: Aaron Brown
RE: [PATCH 3/4] igb/igb_ethtool.c : Remove unnecessary usages of memset.
> From: Suraj Upadhyay > Sent: Tuesday, July 14, 2020 12:42 PM > To: Kirsher, Jeffrey T ; da...@davemloft.net; > k...@kernel.org > Cc: intel-wired-...@lists.osuosl.org; net...@vger.kernel.org; linux- > ker...@vger.kernel.org; kernel-janit...@vger.kernel.org > Subject: [PATCH 3/4] igb/igb_ethtool.c : Remove unnecessary usages of > memset. > > Replace memsets of 1 byte with simple assignment. > Issue found with checkpatch.pl > > Signed-off-by: Suraj Upadhyay > --- > drivers/net/ethernet/intel/igb/igb_ethtool.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > Tested-by: Aaron Brown
RE: [Intel-wired-lan] [PATCH v1 2/5] igbvf: netdev: use generic power management
> From: Intel-wired-lan On Behalf Of > Vaibhav Gupta > Sent: Monday, June 29, 2020 2:30 AM > To: Bjorn Helgaas ; Bjorn Helgaas > ; bj...@helgaas.com; Vaibhav Gupta > ; David S. Miller ; > Jakub Kicinski ; Kirsher, Jeffrey T > > Cc: Vaibhav Gupta ; net...@vger.kernel.org; > linux-kernel@vger.kernel.org; intel-wired-...@lists.osuosl.org; > sk...@linuxfoundation.org; linux-kernel-ment...@lists.linuxfoundation.org > Subject: [Intel-wired-lan] [PATCH v1 2/5] igbvf: netdev: use generic power > management > > Remove legacy PM callbacks and use generic operations. With legacy code, > drivers were responsible for handling PCI PM operations like > pci_save_state(). In generic code, all these hre andled by PCI core. > > The generic suspend() and resume() are called at the same point the legacy > ones were called. Thus, it does not affect the normal functioning of the > driver. > > __maybe_unused attribute is used with .resume() but not with .suspend(), as > .suspend() is calleb by .shutdown(). > > Compile-tested only. > > Signed-off-by: Vaibhav Gupta > --- > drivers/net/ethernet/intel/igbvf/netdev.c | 37 +-- > 1 file changed, 8 insertions(+), 29 deletions(-) > Tested-by: Aaron Brown
RE: [Intel-wired-lan] [PATCH v1 5/5] e100: use generic power management
> From: Intel-wired-lan On Behalf Of > Vaibhav Gupta > Sent: Monday, June 29, 2020 2:30 AM > To: Bjorn Helgaas ; Bjorn Helgaas > ; bj...@helgaas.com; Vaibhav Gupta > ; David S. Miller ; > Jakub Kicinski ; Kirsher, Jeffrey T > > Cc: Vaibhav Gupta ; net...@vger.kernel.org; > linux-kernel@vger.kernel.org; intel-wired-...@lists.osuosl.org; > sk...@linuxfoundation.org; linux-kernel-ment...@lists.linuxfoundation.org > Subject: [Intel-wired-lan] [PATCH v1 5/5] e100: use generic power management > > With legacy PM hooks, it was the responsibility of a driver to manage PCI > states and also the device's power state. The generic approach is to let > PCI core handle the work. > > e100_suspend() calls __e100_shutdown() to perform intermediate tasks. > __e100_shutdown() calls pci_save_state() which is not recommended. > > e100_suspend() also calls __e100_power_off() which is calling PCI helper > functions, pci_prepare_to_sleep(), pci_set_power_state(), along with > pci_wake_from_d3(...,false). Hence, the functin call is removed and wol is > disabled as earlier using device_wakeup_disable(). > > Compile-tested only. > > Signed-off-by: Vaibhav Gupta > --- > drivers/net/ethernet/intel/e100.c | 31 +-- > 1 file changed, 13 insertions(+), 18 deletions(-) I do have several e100 based adapters still working and a few old systems with plain old PCI that still function, however all of these older systems have broken power management. Regardless of if I use the kernel before or after this patch is applied, or even if the e100 driver is loaded or not I can't get a reliable suspend / resume cycle to work on them. I did run some basic regression with this patch against the remaining pro100 cards I could scrounge up and aside from broken power management (again with or without patch) the system seems good, so (hesitantly) from a regression perspective I will go ahead and say... Tested-by: Aaron Brown
Re: [Intel-wired-lan] [PATCH v2] e1000e: Make watchdog use delayed work
On Tue, 2019-06-18 at 18:08 -0400, Detlev Casanova wrote: > Use delayed work instead of timers to run the watchdog of the e1000e > driver. > > Simplify the code with one less middle function. > > Signed-off-by: Detlev Casanova > --- > drivers/net/ethernet/intel/e1000e/e1000.h | 3 +- > drivers/net/ethernet/intel/e1000e/netdev.c | 54 -- > 2 files changed, 30 insertions(+), 27 deletions(-) > This patch is causing a NULL pointer dereference trace (or just a freeze) on a number of my regression systems when I unload the e1000e driver. The crashing test systems each have multiple e1000e based ports, I can pull the systems from the rack and change cards out if necessary, though it's not a trivial task getting to them. Systems affected had the following e1000e chipsets: - 82579LM Gigabit Network Connection rev 05) LOM - 82574L LOM - I217-LM LOM - 82572EI (Rimon) - 80003ES2LAN x2 LOMs - 82572EI Add in card - 80003ES2LAN x2 LOMs - 82571EB (Ophir) copper (dual port card) - 82571EB (Ophir) fibre (dual port card) Here is the trace caputrued from the last system listed, the 80003ES2LAN LOMs and 2 dual port Ophir cards: - u1462:[ttyS1]/root> rmmod e1000e [ 131.799739] BUG: kernel NULL pointer dereference, address: [ 131.806908] #PF: supervisor write access in kernel mode [ 131.812285] #PF: error_code(0x0002) - not-present page [ 131.817565] PGD 800072327067 P4D 800072327067 PUD 3050f067 PMD 0 [ 131.824540] Oops: 0002 [#1] SMP PTI [ 131.828133] CPU: 3 PID: 4306 Comm: rmmod Not tainted 5.2.0-rc5_next-queue_dev-queue_15bf1c7+ #9 [ 131.837073] Hardware name: Supermicro X7DBX/X7DBX, BIOS 2.1 06/23/2008 [ 131.843791] RIP: 0010:_raw_spin_lock_irq+0x13/0x30 [ 131.848722] Code: 00 75 02 f3 c3 e9 3d 16 8a ff 0f 1f 00 66 2e 0f 1f 84 00 00 00 00 00 66 66 66 66 90 fa 66 66 90 66 66 90 31 c0 ba 01 00 00 00 0f b1 17 0f 94 c2 84 d2 74 02 f3 c3 89 c6 e9 b2 fd 89 ff 66 0f [ 131.867998] RSP: 0018:b85601f87d58 EFLAGS: 00010046 [ 131.873377] RAX: RBX: 9a5a9faa5b90 RCX: 0003 [ 131.880702] RDX: 0001 RSI: 0002 RDI: [ 131.888032] RBP: 0002 R08: R09: [ 131.895356] R10: 9a5ab340a550 R11: e13500cd0280 R12: 0003 [ 131.902679] R13: 0002 R14: 9a5a9faa4400 R15: [ 131.910003] FS: 7f37948a9740() GS:9a5afcac() knlGS: [ 131.918325] CS: 0010 DS: ES: CR0: 80050033 [ 131.924229] CR2: CR3: 20602000 CR4: 06e0 [ 131.931557] Call Trace: [ 131.934093] flush_workqueue_prep_pwqs+0x55/0x120 [ 131.938929] flush_workqueue+0x1b6/0x460 [ 131.942987] e1000_remove+0x93/0x190 [e1000e] [ 131.947466] pci_device_remove+0x3b/0xc0 [ 131.951511] device_release_driver_internal+0xdf/0x1a0 [ 131.956797] driver_detach+0x43/0x80 [ 131.960487] bus_remove_driver+0x55/0xd0 [ 131.964535] pci_unregister_driver+0x26/0xa0 [ 131.968938] __x64_sys_delete_module+0x16c/0x250 [ 131.973698] ? exit_to_usermode_loop+0xaa/0xc6 [ 131.978270] do_syscall_64+0x5b/0x1b0 [ 131.982041] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 131.987237] RIP: 0033:0x7f3793d82397 [ 131.990923] Code: 73 01 c3 48 8b 0d f9 7a 2c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 b8 b0 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d c9 7a 2c 00 f7 d8 64 89 01 48 [ 132.010190] RSP: 002b:7ffc6b3dea18 EFLAGS: 0206 ORIG_RAX: 00b0 [ 132.017972] RAX: ffda RBX: 01a23190 RCX: 7f3793d82397 [ 132.034233] RDX: 7f3793df6b20 RSI: 0800 RDI: 01a231f8 [ 132.050479] RBP: R08: 7f379404b060 R09: 7f3793df6b20 [ 132.066683] R10: 7ffc6b3de5e0 R11: 0206 R12: 7ffc6b3e0d4a [ 132.082874] R13: R14: 01a23190 R15: 01a23010 [ 132.098961] Modules linked in: xt_CHECKSUM iptable_mangle xt_MASQUERADE iptable_nat nf_nat xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ipt_REJECT nf_reject_ipv4 tun bridge stp llc ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter dm_mirror dm_region_hash dm_log dm_mod coretemp kvm_intel kvm iTCO_wdt i2c_i801 gpio_ich iTCO_vendor_support lpc_ich pcspkr i5000_edac sg irqbypass acpi_cpufreq i5k_amb nfsd auth_rpcgss nfs_acl lockd grace sunrpc ip_tables xfs libcrc32c radeon sr_mod sd_mod cdrom ata_generic pata_acpi i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm ata_piix libata serio_raw e1000e(-) e1000 [ 132.215961] CR2: [ 132.229473] ---[ end trace 31a92a65bb543b98 ]--- [ 132.244260] RIP: 0010:_raw_spin_lock_irq+0x13/0x30 [ 132.259217] Code: 00 75 02 f3 c3 e9 3d 16 8a ff 0f 1f 00 66 2e 0f 1f 84 00 00 00 00 00 66 66 66 66 90 fa
RE: [PATCH v2] igb: Report speed and duplex as unknown when device is runtime suspended
> From: Kai-Heng Feng > Sent: Monday, May 4, 2020 9:02 PM > To: Kirsher, Jeffrey T > Cc: Kai-Heng Feng ; Brown, Aaron F > ; David S. Miller ; > moderated list:INTEL ETHERNET DRIVERS ; > open list:NETWORKING DRIVERS ; open list ker...@vger.kernel.org> > Subject: [PATCH v2] igb: Report speed and duplex as unknown when device is > runtime suspended > > igb device gets runtime suspended when there's no link partner. We can't > get correct speed under that state: > $ cat /sys/class/net/enp3s0/speed > 1000 > > In addition to that, an error can also be spotted in dmesg: > [ 385.991957] igb :03:00.0 enp3s0: PCIe link lost > > Since device can only be runtime suspended when there's no link partner, > we can skip reading register and let the following logic set speed and > duplex with correct status. > > The more generic approach will be wrap get_link_ksettings() with begin() > and complete() callbacks. However, for this particular issue, begin() > calls igb_runtime_resume() , which tries to rtnl_lock() while the lock > is already hold by upper ethtool layer. > > So let's take this approach until the igb_runtime_resume() no longer > needs to hold rtnl_lock. > > Cc: Jeff Kirsher > Cc: Aaron Brown > Suggested-by: Alexander Duyck > Signed-off-by: Kai-Heng Feng > --- > v2: > - Don't early return the routine so other info can be set. > > drivers/net/ethernet/intel/igb/igb_ethtool.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > Tested-by: Aaron Brown
RE: [PATCH 1/2] e1000e: Do not wake up the system via WOL if device wakeup is disabled
> From: Chen Yu
> Sent: Thursday, May 21, 2020 10:59 AM
> To: Kirsher, Jeffrey T ; David S. Miller
> ; Jakub Kicinski ; Kok, Auke-jan H
> ; Jeff Garzik
> Cc: intel-wired-...@lists.osuosl.org; net...@vger.kernel.org; linux-
> ker...@vger.kernel.org; Brown, Len ; Rafael J. Wysocki
> ; Shevchenko, Andriy ;
> Neftin, Sasha ; Lifshits, Vitaly
> ; Chen, Yu C ;
> sta...@vger.kernel.org
> Subject: [PATCH 1/2] e1000e: Do not wake up the system via WOL if device
> wakeup is disabled
>
> Currently the system will be woken up via WOL(Wake On Lan) even if the
> device wakeup ability has been disabled via sysfs:
> cat /sys/devices/pci:00/:00:1f.6/power/wakeup
> disabled
>
> The system should not be woken up if the user has explicitly
> disabled the wake up ability for this device.
>
> This patch clears the WOL ability of this network device if the
> user has disabled the wake up ability in sysfs.
>
> Fixes: bc7f75fa9788 ("[E1000E]: New pci-express e1000 driver")
> Reported-by: Rafael J. Wysocki
> Reviewed-by: Andy Shevchenko
> Cc:
> Signed-off-by: Chen Yu
> ---
> drivers/net/ethernet/intel/e1000e/netdev.c | 14 ++
> 1 file changed, 10 insertions(+), 4 deletions(-)
>
Tested-by: Aaron Brown
