On 3/17/2021 16:52, 'w00385741 wrote:
From: Wei Yongjun
The function e1000e_pm_prepare() may have no callers depending
on configuration, so it must be marked __maybe_unused to avoid
harmless warning:
drivers/net/ethernet/intel/e1000e/netdev.c:6926:12:
warning: 'e1000e_pm_prepare' defined but
On 2/28/2021 11:44, Dinghao Liu wrote:
There is one e1e_wphy() call in e1000_set_d0_lplu_state_82571
that we have caught its return value but lack further handling.
Check and terminate the execution flow just like other e1e_wphy()
in this function.
Signed-off-by: Dinghao Liu
---
drivers/net/e
On 2/22/2021 06:00, Tom Seewald wrote:
The include guard "_E1000_HW_H_" is used by header files in three
different drivers (e1000/e1000_hw.h, e1000e/hw.h, and igb/e1000_hw.h).
Using the same include guard macro in more than one header file may
cause unexpected behavior from the compiler. Fix the
On 1/30/2021 20:12, Jakub Kicinski wrote:
On Sat, 30 Jan 2021 16:00:06 +0200 Neftin, Sasha wrote:
On 1/30/2021 08:22, Jakub Kicinski wrote:
On Thu, 28 Jan 2021 13:38:48 -0800 Tony Nguyen wrote:
From: Kai-Heng Feng
Similar to commit 165ae7a8feb5 ("igb: Report speed and duplex as unknown
On 1/30/2021 08:22, Jakub Kicinski wrote:
On Thu, 28 Jan 2021 13:38:48 -0800 Tony Nguyen wrote:
From: Kai-Heng Feng
Similar to commit 165ae7a8feb5 ("igb: Report speed and duplex as unknown
when device is runtime suspended"), if we try to read speed and duplex
sysfs while the device is runtime
On 12/15/2020 19:20, Limonciello, Mario wrote:
Absolutely - I'll ask them to look into this again.
we need to explain why on Windows systems required 1s and on Linux
systems up to 2.5s - otherwise it is not reliable approach - you will
encounter others buggy system.
(ME not POR on the Linux s
On 12/14/2020 20:40, Mark Pearson wrote:
Thanks Hans
On 14/12/2020 13:31, Mark Pearson wrote:
*From:* Hans de Goede
*Sent:* December 14, 2020 13:24
*To:* Mario Limonciello ; Jeff Kirsher
; Tony Nguyen ;
intel-wired-...@
On 12/10/2020 07:28, Neftin, Sasha wrote:
On 12/10/2020 04:24, Alexander Duyck wrote:
On Wed, Dec 9, 2020 at 6:44 AM Hans de Goede wrote:
Hi,
On 12/8/20 5:14 PM, Alexander Duyck wrote:
On Tue, Dec 8, 2020 at 1:30 AM Hans de Goede
wrote:
Hi,
On 12/8/20 6:08 AM, Neftin, Sasha wrote:
On
On 12/10/2020 04:24, Alexander Duyck wrote:
On Wed, Dec 9, 2020 at 6:44 AM Hans de Goede wrote:
Hi,
On 12/8/20 5:14 PM, Alexander Duyck wrote:
On Tue, Dec 8, 2020 at 1:30 AM Hans de Goede wrote:
Hi,
On 12/8/20 6:08 AM, Neftin, Sasha wrote:
On 12/7/2020 17:41, Limonciello, Mario wrote
On 12/7/2020 17:41, Limonciello, Mario wrote:
First of all thank you for working on this.
I must say though that I don't like the approach taken here very
much.
This is not so much a criticism of this series as it is a criticism
of the earlier decision to simply disable s0ix on all devices
with
On 12/2/2020 09:50, Kai-Heng Feng wrote:
Similar to commit 165ae7a8feb5 ("igb: Report speed and duplex as unknown
when device is runtime suspended"), if we try to read speed and duplex
sysfs while the device is runtime suspeneded, igc will complain and
stops working:
[ 123.449883] igc :03:0
Hello Kai-Heng,
On 9/29/2020 16:31, Kai-Heng Feng wrote:
Hi Sasha,
On Sep 29, 2020, at 21:08, Neftin, Sasha wrote:
On 9/28/2020 11:36, Kai-Heng Feng wrote:
We are seeing the following error after S3 resume:
[ 704.746874] e1000e :00:1f.6 eno1: Setting page 0x6020
[ 704.844232] e1000e
On 9/28/2020 11:36, Kai-Heng Feng wrote:
We are seeing the following error after S3 resume:
[ 704.746874] e1000e :00:1f.6 eno1: Setting page 0x6020
[ 704.844232] e1000e :00:1f.6 eno1: MDI Write did not complete
[ 704.902817] e1000e :00:1f.6 eno1: Setting page 0x6020
[ 704.903075]
On 7/17/2020 05:12, Nathan Chancellor wrote:
On Thu, Jul 16, 2020 at 07:29:03PM +0300, Neftin, Sasha wrote:
On 7/16/2020 07:49, Nathan Chancellor wrote:
Clang warns:
Hello Nathan,
Thanks for tracking our code.Please, look at
https://patchwork.ozlabs.org/project/intel-wired-lan/patch
On 7/16/2020 07:49, Nathan Chancellor wrote:
Clang warns:
Hello Nathan,
Thanks for tracking our code.Please, look at
https://patchwork.ozlabs.org/project/intel-wired-lan/patch/20200709073416.14126-1-sasha.nef...@intel.com/
- I hope this patch already address this Clang warns - please, let me
On 6/10/2020 04:49, Palmer Dabbelt wrote:
From: Palmer Dabbelt
e1000e_check_me is only used under CONFIG_PM_SLEEP but exists
unconditionally, which triggers a warning.
Signed-off-by: Palmer Dabbelt
---
drivers/net/ethernet/intel/e1000e/netdev.c | 2 ++
1 file changed, 2 insertions(+)
diff
On 10/17/2019 03:02, Jakub Kicinski wrote:
On Wed, 16 Oct 2019 16:47:08 -0700, Jeff Kirsher wrote:
static int e1000e_pm_freeze(struct device *dev)
{
struct net_device *netdev = dev_get_drvdata(dev);
@@ -6650,6 +6822,9 @@ static int e1000e_pm_thaw(struct device *dev)
static int e100
On 5/21/2019 18:42, Juliana Rodrigueiro wrote:
So I ask myself, how actually feasible is it to gamble the usage of "ethtool"
to turn on or off TSO every time the network configuration changes?
Hello Juliana,
There are many PCH2 devices with different SKU's. Not all devices have
this problem (T
On 5/9/2019 13:34, Juliana Rodrigueiro wrote:
When forwarding traffic to a client behind NAT, some e1000e devices
become unstable, hanging and then being reset by the watchdog.
Output from syslog:
kernel: e1000e :00:19.0 eth0: Detected Hardware Unit Hang:
kernel: TDH <5f>
On 3/7/2019 09:29, David Miller wrote:
From: Arnd Bergmann
Date: Thu, 7 Mar 2019 10:29:57 +0100
clang points out that the igc_priv_flags_strings[] array is never
referenced, aside from being used for calculating its length:
drivers/net/ethernet/intel/igc/igc_ethtool.c:9:19: error: variable
On 22/02/2019 6:09, Florian Fainelli wrote:
Provide precision hints to snprintf() since we know the destination
buffer size of the RX/TX ring names are IFNAMSIZ + 5 - 1. This fixes the
following warnings:
drivers/net/ethernet/intel/e1000e/netdev.c: In function
'e1000_request_msix':
drivers/net/e
On 2/17/2019 12:06, Neftin, Sasha wrote:
On 2/16/2019 04:04, Wei Yongjun wrote:
Fixes the following sparse warning:
drivers/net/ethernet/intel/igc/igc_ethtool.c:646:6: warning:
symbol 'igc_write_rss_indir_tbl' was not declared. Should it be static?
Fixes: 8c5ad0dae93c ("i
On 2/16/2019 04:04, Wei Yongjun wrote:
Fixes the following sparse warning:
drivers/net/ethernet/intel/igc/igc_ethtool.c:646:6: warning:
symbol 'igc_write_rss_indir_tbl' was not declared. Should it be static?
Fixes: 8c5ad0dae93c ("igc: Add ethtool support")
Signed-off-by: Wei Yongjun
---
dr
On 1/14/2019 15:29, Konstantin Khlebnikov wrote:
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 jumb
On 11/8/2018 13:00, Joe Perches wrote:
On Wed, 2018-11-07 at 14:48 -0800, Jeff Kirsher wrote:
From: Sasha Neftin
Address few community comments.
Remove unused code, will be added per demand.
Remove blank lines and unneeded includes.
Signed-off-by: Sasha Neftin
Tested-by: Aaron Brown
Signed-
On 10/18/2018 20:15, Jakub Kicinski wrote:
On Wed, 17 Oct 2018 15:23:14 -0700, Jeff Kirsher wrote:
+/**
+ * igc_ioctl - I/O control method
+ * @netdev: network interface device structure
+ * @ifreq: frequency
Is it? :)
Ah... Good catch. I will fix that and submit patch.
+ * @cmd: command
+
On 10/19/2018 21:16, Colin King wrote:
From: Colin Ian King
The call to netif_set_real_num_tx_queues is not assigning the error
return to variable err even though the next line checks err for an
error. Fix this by adding the missing err assignment.
Detected by CoverityScan, CID#1474551 ("Logi
On 10/19/2018 15:40, YueHaibing wrote:
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/net/ethernet/intel/igc/igc_base.c: In function
'igc_init_phy_params_base':
drivers/net/ethernet/intel/igc/igc_base.c:240:6: warning:
variable 'ctrl_ext' set but not used [-Wunused-but-set-variable]
On 10/19/2018 15:48, YueHaibing wrote:
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/net/ethernet/intel/igc/igc_main.c: In function 'igc_probe':
drivers/net/ethernet/intel/igc/igc_main.c:3535:11: warning:
variable 'pci_using_dac' set but not used [-Wunused-but-set-variable]
It never
On 10/18/2018 20:14, Jakub Kicinski wrote:
On Wed, 17 Oct 2018 15:23:12 -0700, Jeff Kirsher wrote:
From: Sasha Neftin
This patch adds the beginning framework onto which I am going to add
the igc driver which supports the Intel(R) I225-LM/I225-V 2.5G
Ethernet Controller.
Signed-off-by: Sasha N
On 8/8/2018 17:24, Neftin, Sasha wrote:
On 8/7/2018 09:42, Camille Bordignon wrote:
Le lundi 06 août 2018 à 15:45:29 (-0700), Alexander Duyck a écrit :
On Mon, Aug 6, 2018 at 4:59 AM, Camille Bordignon
wrote:
Hello,
Recently we experienced some issues with intel NIC (I219-LM and
I219-V
On 8/7/2018 09:42, Camille Bordignon wrote:
Le lundi 06 août 2018 à 15:45:29 (-0700), Alexander Duyck a écrit :
On Mon, Aug 6, 2018 at 4:59 AM, Camille Bordignon
wrote:
Hello,
Recently we experienced some issues with intel NIC (I219-LM and I219-V).
It seems that after a wire reconnection, aut
On 5/10/2018 21:42, Keller, Jacob E wrote:
-Original Message-
From: Benjamin Poirier [mailto:bpoir...@suse.com]
Sent: Thursday, May 10, 2018 12:29 AM
To: Kirsher, Jeffrey T
Cc: Keller, Jacob E ; Achim Mildenberger
; olouvig...@gmail.com;
jaya...@goubiq.com; ehabk...@redhat.com; postmoder
On 2/19/2018 22:12, Benjamin Poirier wrote:
When autoneg is off, the .check_for_link callback functions clear the
get_link_status flag and systematically return a "pseudo-error". This means
that the link is not detected as up until the next execution of the
e1000_watchdog_task() 2 seconds later.
On 1/26/2018 12:24, Pierre-Yves Kerbrat wrote:
Descriptor rings were not initialized at zero when allocated
When area contained garbage data, it caused skb_over_panic in
e1000_clean_rx_irq (if data had E1000_RXD_STAT_DD bit set)
This patch makes use of dma_zalloc_coherent to make sure the
ring i
On 1/24/2018 20:41, Ben Greear wrote:
On 01/24/2018 10:38 AM, Denys Fedoryshchenko wrote:
On 2018-01-24 20:31, Ben Greear wrote:
On 01/24/2018 08:34 AM, Neftin, Sasha wrote:
On 1/24/2018 18:11, Alexander Duyck wrote:
On Tue, Jan 23, 2018 at 3:46 PM, Ben Greear
wrote:
Hello,
Anyone have
On 1/24/2018 18:11, Alexander Duyck wrote:
On Tue, Jan 23, 2018 at 3:46 PM, Ben Greear wrote:
Hello,
Anyone have any more suggestions for making e1000e work better? This is
from a 4.9.65+ kernel,
with these additional e1000e patches applied:
e1000e: Fix error path in link detection
e1000e: F
On 20/12/2017 18:01, Pavel Machek wrote:
On Wed 2017-12-20 16:54:21, Pavel Machek wrote:
Hi!
Before ask for reverting 19110cfbb..., please, check if follow patch
of Benjamin work for you http://patchwork.ozlabs.org/patch/846825/
Pavel, before ask for revert - let's check Benjamin's patch foll
On 11/12/2017 9:26, Benjamin Poirier wrote:
e1000e_check_for_copper_link() and e1000_check_for_copper_link_ich8lan()
are the two functions that may be assigned to mac.ops.check_for_link when
phy.media_type == e1000_media_type_copper. Commit 19110cfbb34d ("e1000e:
Separate signaling for link check
On 12/18/2017 17:50, Neftin, Sasha wrote:
On 12/18/2017 13:58, Pavel Machek wrote:
On Mon 2017-12-18 13:24:40, Neftin, Sasha wrote:
On 12/18/2017 12:26, Pavel Machek wrote:
Hi!
In v4.15-rc2+, network manager can not see my ethernet card, and
manual attempts to ifconfig it up did not really
On 12/18/2017 13:58, Pavel Machek wrote:
On Mon 2017-12-18 13:24:40, Neftin, Sasha wrote:
On 12/18/2017 12:26, Pavel Machek wrote:
Hi!
In v4.15-rc2+, network manager can not see my ethernet card, and
manual attempts to ifconfig it up did not really help, either.
Card is:
02:00.0 Ethernet
On 10/11/2017 12:07, David Laight wrote:
From: Jeff Kirsher
Sent: 10 October 2017 18:22
Intel 100/200 Series Chipset platforms reduced the round-trip
latency for the LAN Controller DMA accesses, causing in some high
performance cases a buffer overrun while the I219 LAN Connected
Device is proces
On 10/11/2017 12:07, David Laight wrote:
From: Jeff Kirsher
Sent: 10 October 2017 18:22
Intel 100/200 Series Chipset platforms reduced the round-trip
latency for the LAN Controller DMA accesses, causing in some high
performance cases a buffer overrun while the I219 LAN Connected
Device is proces
On 8/26/2017 04:14, Florian Fainelli wrote:
e1000e_put_txbuf() can be called from normal reclamation path as well as
when a DMA mapping failure, so we need to differentiate these two cases
when freeing SKBs to be drop monitor friendly. e1000e_tx_hwtstamp_work()
and e1000_remove() are processing T
On 8/23/2017 18:59, Matthew Tan wrote:
Calls to udelay are not preemtable by userspace so userspace
applications experience a large (~200us) latency when running on core
0. Instead usleep_range can be used to be more friendly to userspace
since it is preemtable. This is due to
On 8/27/2017 11:32, Neftin, Sasha wrote:
On 8/27/2017 11:30, Neftin, Sasha wrote:
On 8/25/2017 18:06, Willem de Bruijn wrote:
From: Willem de Bruijn
Devices that support FLAG2_DMA_BURST have different default values
for RDTR and RADV. Apply burst mode default settings only when no
explicit
On 8/27/2017 11:30, Neftin, Sasha wrote:
On 8/25/2017 18:06, Willem de Bruijn wrote:
From: Willem de Bruijn
Devices that support FLAG2_DMA_BURST have different default values
for RDTR and RADV. Apply burst mode default settings only when no
explicit value was passed at module load.
The RDTR
On 8/25/2017 18:06, Willem de Bruijn wrote:
From: Willem de Bruijn
Devices that support FLAG2_DMA_BURST have different default values
for RDTR and RADV. Apply burst mode default settings only when no
explicit value was passed at module load.
The RDTR default is zero. If the module is loaded fo
On 7/21/2017 21:36, Benjamin Poirier wrote:
Lennart reported the following race condition:
\ e1000_watchdog_task
\ e1000e_has_link
\ hw->mac.ops.check_for_link() === e1000e_check_for_copper_link
/* link is up */
mac->get_link_status = false;
On 21/06/2017 22:52, Gustavo A. R. Silva wrote:
Hi Ethan,
Quoting Ethan Zhao :
Gustavo,
The return value of ret_val seems used to check if the access to
PHY/NVM
got its semaphore, generally speaking, it is needed for every PHY
access of this driver.
Reviewed-by: Ethan Zhao
Thank yo
On 5/31/2017 18:50, Jani Nikula wrote:
From: Chris Wilson
An error during suspend (e100e_pm_suspend),
[ 429.994338] ACPI : EC: event blocked
[ 429.994633] e1000e: EEE TX LPI TIMER: 0011
[ 430.955451] pci_pm_suspend(): e1000e_pm_suspend+0x0/0x30 [e1000e] returns -2
[ 430.955454] dpm_run
On 5/19/2017 21:34, Cong Wang wrote:
On Fri, May 19, 2017 at 12:18 AM, Konstantin Khlebnikov
wrote:
Replace disable_irq() which waits for threaded irq handlers with
disable_hardirq() which waits only for hardirq part.
Signed-off-by: Konstantin Khlebnikov
Fixes: 311191297125 ("e1000: use disab
On 4/23/2017 15:53, Neftin, Sasha wrote:
-Original Message-
From: Intel-wired-lan [mailto:intel-wired-lan-boun...@lists.osuosl.org] On
Behalf Of Benjamin Poirier
Sent: Saturday, April 22, 2017 00:20
To: Kirsher, Jeffrey T
Cc: netdev@vger.kernel.org; intel-wired-...@lists.osuosl.org
On 4/20/2017 00:15, Florian Fainelli wrote:
On 04/19/2017 01:52 AM, Neftin, Sasha wrote:
On 4/18/2017 22:05, Florian Fainelli wrote:
On 04/18/2017 12:03 PM, Eric Dumazet wrote:
On Tue, 2017-04-18 at 11:18 -0700, Florian Fainelli wrote:
Hi,
I am using NFS over a NAT with two e1000e adapters
On 4/18/2017 22:05, Florian Fainelli wrote:
On 04/18/2017 12:03 PM, Eric Dumazet wrote:
On Tue, 2017-04-18 at 11:18 -0700, Florian Fainelli wrote:
Hi,
I am using NFS over a NAT with two e1000e adapters and with eth1 being
the LAN interface and eth0 the WAN interface. The kernel is Ubuntu's
16.
On 2/26/2017 11:08, Neftin, Sasha wrote:
On 2/19/2017 14:55, Neftin, Sasha wrote:
On 2/16/2017 20:42, Bernd Faust wrote:
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
On 2/26/2017 11:08, Neftin, Sasha wrote:
On 2/19/2017 14:55, Neftin, Sasha wrote:
On 2/16/2017 20:42, Bernd Faust wrote:
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
On 2/19/2017 14:55, Neftin, Sasha wrote:
On 2/16/2017 20:42, Bernd Faust wrote:
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
On 2/20/2017 15:02, Chris Wilson wrote:
Chris Wilson, Intel Open Source Technology Centre
Chris,
Please, check patch with fewer code lines. If short patch good and works
well for you, please, submit it and we will check then on our side.
On 2/16/2017 20:42, Bernd Faust wrote:
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 up
On 2/1/2017 00:01, Philippe Reynes wrote:
Hi Sasha,
On 1/31/17, Neftin, Sasha wrote:
Philippe,
We will look into and try test this patch. I would like ask question. I
see that this thread has been started from implementation for e1000
code. Why do you decide shift implementation to e1000e
On 1/26/2017 23:19, Philippe Reynes wrote:
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/inte
Baicar, Tyler wrote:
>> On 11/17/2016 6:31 AM, Neftin, Sasha wrote:
>>> On 11/13/2016 10:34 AM, Neftin, Sasha wrote:
>>>> On 11/11/2016 12:35 AM, Baicar, Tyler wrote:
>>>>> Hello Sasha,
>>>>>
>>>>> On 11/9/2016 11:19 PM, Neftin,
From: Baicar, Tyler [mailto:tbai...@codeaurora.org] Sent: Tuesday,
November 15, 2016 11:50 PM
To: Neftin, Sasha ; Kirsher, Jeffrey T
; intel-wired-...@lists.osuosl.org;
netdev@vger.kernel.org; linux-ker...@vger.kernel.org;
ok...@codeaurora.org; ti...@codeaurora.org
Subject: Re: [Intel-wired-lan
On 11/13/2016 10:34 AM, Neftin, Sasha wrote:
> On 11/11/2016 12:35 AM, Baicar, Tyler wrote:
>> Hello Sasha,
>>
>> On 11/9/2016 11:19 PM, Neftin, Sasha wrote:
>>> On 11/9/2016 11:41 PM, Tyler Baicar wrote:
>>>> Move IRQ free code so that it will happ
On 11/13/2016 10:34 AM, Neftin, Sasha wrote:
> On 11/11/2016 12:35 AM, Baicar, Tyler wrote:
>> Hello Sasha,
>>
>> On 11/9/2016 11:19 PM, Neftin, Sasha wrote:
>>> On 11/9/2016 11:41 PM, Tyler Baicar wrote:
>>>> Move IRQ free code so that it will happ
On 11/11/2016 12:35 AM, Baicar, Tyler wrote:
> Hello Sasha,
>
> On 11/9/2016 11:19 PM, Neftin, Sasha wrote:
>> On 11/9/2016 11:41 PM, Tyler Baicar wrote:
>>> Move IRQ free code so that it will happen regardless of the
>>> __E1000_DOWN bit. Currently the e1000e dr
On 11/9/2016 11:41 PM, Tyler Baicar wrote:
> Move IRQ free code so that it will happen regardless of the
> __E1000_DOWN bit. Currently the e1000e driver only releases its IRQ
> if the __E1000_DOWN bit is cleared. This is not sufficient because
> it is possible for __E1000_DOWN to be set without rel
Since I worked with Sasha on this I will provide a bit of information from what
I understand of this bug as well.
On Tue, Sep 27, 2016 at 12:13 PM, Alex Williamson
wrote:
> On Tue, 27 Sep 2016 13:17:02 -0500
> Bjorn Helgaas wrote:
>
>> On Sun, Sep 25, 2016 at 10:02:43AM +0300
On 9/24/2016 12:05 AM, Jeff Kirsher wrote:
On Fri, 2016-09-23 at 09:01 -0500, Bjorn Helgaas wrote:
On Thu, Sep 22, 2016 at 11:39:01PM -0700, Jeff Kirsher wrote:
From: Sasha Neftin
82579 has a problem reattaching itself after the device is detached.
The bug was reported by Redhat. The suggeste
70 matches
Mail list logo
