Re: [Intel-wired-lan] [PATCH] e1000e: Fix error handling in e1000_set_d0_lplu_state_82571

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 ---

Re: [PATCH] platform/x86: intel_pmc: Ignore GBE LTR on Tiger Lake platforms

On 3/5/2021 21:06, David E. Box wrote: Due to a HW limitation, the Latency Tolerance Reporting (LTR) value programmed in the Tiger Lake GBE controller is not large enough to allow the platform to enter Package C10, which in turn prevents the platform from achieving its low power target during

Re: Fw: [External] Re: [PATCH v4 0/4] Improve s0ix flows for systems i219LM

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

Re: Fw: [External] Re: [PATCH v4 0/4] Improve s0ix flows for systems i219LM

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 ;

Re: [PATCH v3 0/7] Improve s0ix flows for systems i219LM

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

Re: [PATCH v3 0/7] Improve s0ix flows for systems i219LM

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

Re: [PATCH v3 0/7] Improve s0ix flows for systems i219LM

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

Re: [Intel-wired-lan] [PATCH] igc: Report speed and duplex as unknown when device is runtime suspended

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

Re: [Intel-wired-lan] [PATCH v4] e1000e: Increase polling timeout on MDIC ready bit

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

Re: [Intel-wired-lan] [PATCH v4] e1000e: Increase polling timeout on MDIC ready bit

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]

Re: [Intel-wired-lan] [PATCH] igc: Do not use link uninitialized in igc_check_for_copper_link

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

Re: [Intel-wired-lan] [PATCH] igc: Do not use link uninitialized in igc_check_for_copper_link

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

Re: [Intel-wired-lan] [PATCH] e1000e: Squash an unused function warning

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(+)

Re: [PATCH] igb/igc: Don't warn on fatal read failures when the device is removed

On 8/22/2019 21:33, 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

Re: [Intel-wired-lan] MDI errors during resume from ACPI S3 (suspend to ram)

On 8/7/2019 17:55, Paul Menzel wrote: Dear Sasha, On 07.08.19 09:23, Neftin, Sasha wrote: On 8/6/2019 18:53, mario.limoncie...@dell.com wrote: -Original Message- From: Paul Menzel Sent: Tuesday, August 6, 2019 10:36 AM To: Jeff Kirsher Cc: intel-wired-...@lists.osuosl.org; Linux

Re: [Intel-wired-lan] MDI errors during resume from ACPI S3 (suspend to ram)

On 8/6/2019 18:53, mario.limoncie...@dell.com wrote: -Original Message- From: Paul Menzel Sent: Tuesday, August 6, 2019 10:36 AM To: Jeff Kirsher Cc: intel-wired-...@lists.osuosl.org; Linux Kernel Mailing List; Limonciello, Mario Subject: MDI errors during resume from ACPI S3 (suspend

Re: RX CRC errors on I219-V (6) 8086:15be

On 6/26/2019 09:14, Kai Heng Feng wrote: Hi Sasha at 5:09 PM, Kai-Heng Feng wrote: Hi Jeffrey, We’ve encountered another issue, which causes multiple CRC errors and renders ethernet completely useless, here’s the network stats: I also tried ignore_ltr for this issue, seems like it

Re: [Intel-wired-lan] Opportunistic S0ix blocked by e1000e when ethernet is in use

On 6/24/2019 18:06, Kai-Heng Feng wrote: at 19:56, Neftin, Sasha wrote: On 6/24/2019 10:03, Kai-Heng Feng wrote: Hi Jeffrey, at 19:08, Kai-Heng Feng wrote: Hi Jeffrey, There are several platforms that uses e1000e can’t enter Opportunistic S0ix (PC10) when the ethernet has a link partner

Re: [Intel-wired-lan] Opportunistic S0ix blocked by e1000e when ethernet is in use

On 6/24/2019 10:03, Kai-Heng Feng wrote: Hi Jeffrey, at 19:08, Kai-Heng Feng wrote: Hi Jeffrey, There are several platforms that uses e1000e can’t enter Opportunistic S0ix (PC10) when the ethernet has a link partner. This behavior also exits in out-of-tree e1000e driver 3.4.2.1, but

Re: [PATCH] igc: remove unused igc_priv_flags_strings array

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

Re: [Intel-wired-lan] [PATCH net-next 3/4] e1000e: Fix -Wformat-truncation warnings

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':

Re: [Intel-wired-lan] [PATCH] e1000e: fix cyclic resets at link up with active tx

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

Re: [Intel-wired-lan] [PATCH] e1000e: Ignore TSYNCRXCTL when getting I219 clock attributes

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

Re: [Intel-wired-lan] [PATCH] e1000e: Ignore TSYNCRXCTL when getting I219 clock attributes

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;

Re: [Intel-wired-lan] [PATCH net-queue] e1000e: Fix check_for_link return value with autoneg off.

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.

Re: [Intel-wired-lan] [PATCH net-queue] e1000e: Fix check_for_link return value with autoneg off.

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.

Re: [Intel-wired-lan] v4.15-rc2 on thinkpad x60: ethernet stopped working

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

Re: [Intel-wired-lan] v4.15-rc2 on thinkpad x60: ethernet stopped working

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

Re: [Intel-wired-lan] [PATCH] e1000e: Fix e1000_check_for_copper_link_ich8lan return value.

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

Re: [Intel-wired-lan] [PATCH] e1000e: Fix e1000_check_for_copper_link_ich8lan return value.

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

Re: [Intel-wired-lan] v4.15-rc2 on thinkpad x60: ethernet stopped working

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

Re: [Intel-wired-lan] v4.15-rc2 on thinkpad x60: ethernet stopped working

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

Re: [Intel-wired-lan] v4.15-rc2 on thinkpad x60: ethernet stopped working

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

Re: [Intel-wired-lan] v4.15-rc2 on thinkpad x60: ethernet stopped working

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

Re: [Intel-wired-lan] [PATCH net-next v3] e1000e: Be drop monitor friendly

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

Re: [Intel-wired-lan] [PATCH net-next v3] e1000e: Be drop monitor friendly

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

Re: [Intel-wired-lan] [PATCH] e1000e: changed some expensive calls of udelay to usleep_range

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

Re: [Intel-wired-lan] [PATCH] e1000e: changed some expensive calls of udelay to usleep_range

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

Re: [Intel-wired-lan] [PATCH 4/5] e1000e: Separate signaling for link check/link up

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;

Re: [Intel-wired-lan] [PATCH 4/5] e1000e: Separate signaling for link check/link up

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;

Re: [Intel-wired-lan] [PATCH] net: intel: e1000e: add check on e1e_wphy() return value

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.

Re: [Intel-wired-lan] [PATCH] net: intel: e1000e: add check on e1e_wphy() return value

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

Re: [Intel-wired-lan] [PATCH v2 1/1] e1000e: Undo e1000e_pm_freeze if __e1000_shutdown fails

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]

Re: [Intel-wired-lan] [PATCH v2 1/1] e1000e: Undo e1000e_pm_freeze if __e1000_shutdown fails

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]

Re: [Intel-wired-lan] [BUG] 4.11.0-rc1 panic on shutdown X61s

On 3/14/2017 03:20, Brown, Aaron F wrote: 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-

Re: [Intel-wired-lan] [BUG] 4.11.0-rc1 panic on shutdown X61s

On 3/14/2017 03:20, Brown, Aaron F wrote: 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

Re: [Intel-wired-lan] [PATCH] e1000e: fix timing for 82579 Gigabit Ethernet controller

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

Re: [Intel-wired-lan] [PATCH] e1000e: fix timing for 82579 Gigabit Ethernet controller

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

Re: [Intel-wired-lan] [PATCH] e1000e: fix timing for 82579 Gigabit Ethernet controller

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

Re: [Intel-wired-lan] [PATCH] e1000e: fix timing for 82579 Gigabit Ethernet controller

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

Re: [Intel-wired-lan] [PATCH] e1000e: fix timing for 82579 Gigabit Ethernet controller

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

Re: [Intel-wired-lan] [PATCH] e1000e: fix timing for 82579 Gigabit Ethernet controller

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

Re: [Intel-wired-lan] [PATCH] e1000e: fix timing for 82579 Gigabit Ethernet controller

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

Re: [Intel-wired-lan] [PATCH] e1000e: fix timing for 82579 Gigabit Ethernet controller

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

Re: [Intel-wired-lan] [PATCH] net: intel: e1000e: use new api ethtool_{get|set}_link_ksettings

On 2/1/2017 00:01, Philippe Reynes wrote: Hi Sasha, On 1/31/17, Neftin, Sasha <sasha.nef...@intel.com> 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

Re: [Intel-wired-lan] [PATCH] net: intel: e1000e: use new api ethtool_{get|set}_link_ksettings

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

Re: [Intel-wired-lan] [PATCH] net: intel: e1000e: use new api ethtool_{get|set}_link_ksettings

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 ---

Re: [Intel-wired-lan] [PATCH] net: intel: e1000e: use new api ethtool_{get|set}_link_ksettings

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 ---

Re: [Intel-wired-lan] [PATCH v2] e1000e: free IRQ regardless of __E1000_DOWN

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

Re: [Intel-wired-lan] [PATCH v2] e1000e: free IRQ regardless of __E1000_DOWN

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

Re: [Intel-wired-lan] [PATCH v2] e1000e: free IRQ regardless of __E1000_DOWN

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

Re: [Intel-wired-lan] [PATCH v2] e1000e: free IRQ regardless of __E1000_DOWN

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

[Intel-wired-lan] [PATCH v2] e1000e: free IRQ regardless of __E1000_DOWN

> -Original Message- > From: Baicar, Tyler [mailto:tbai...@codeaurora.org] > Sent: Tuesday, November 15, 2016 11:50 PM > To: Neftin, Sasha <sasha.nef...@intel.com>; Kirsher, Jeffrey T > <jeffrey.t.kirs...@intel.com>; intel-wired-...@lists.osuosl.org; >

[Intel-wired-lan] [PATCH v2] e1000e: free IRQ regardless of __E1000_DOWN

> -Original Message- > 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; > net...@vger.kernel.org; linux-kernel@vger.kernel.org; ok...@cod

Re: [Intel-wired-lan] [PATCH v2] e1000e: free IRQ regardless of __E1000_DOWN

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

Re: [Intel-wired-lan] [PATCH v2] e1000e: free IRQ regardless of __E1000_DOWN

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

Re: [Intel-wired-lan] [PATCH v2] e1000e: free IRQ regardless of __E1000_DOWN

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 e1

Re: [Intel-wired-lan] [PATCH v2] e1000e: free IRQ regardless of __E1000_DOWN

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 e1

Re: [Intel-wired-lan] [PATCH v2] e1000e: free IRQ regardless of __E1000_DOWN

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

Re: [Intel-wired-lan] [PATCH v2] e1000e: free IRQ regardless of __E1000_DOWN

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

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"

-Original Message- From: Intel-wired-lan [mailto:intel-wired-lan-boun...@lists.osuosl.org] On Behalf Of Brown, Aaron F Sent: Wednesday, November 02, 2016 11:20 PM To: Jack Suter ; Kirsher, Jeffrey T Cc: bpoir...@suse.com; jhod...@ucdavis.edu;

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"

-Original Message- From: Intel-wired-lan [mailto:intel-wired-lan-boun...@lists.osuosl.org] On Behalf Of Brown, Aaron F Sent: Wednesday, November 02, 2016 11:20 PM To: Jack Suter ; Kirsher, Jeffrey T Cc: bpoir...@suse.com; jhod...@ucdavis.edu; intel-wired-...@lists.osuosl.org;

RE: [Intel-wired-lan] e1000e: PHY cann't be initialized correctly on some I218 controllers

Hello Denis, In case this reset help you fix initialization error of I218 you can use it locally on your system. How many system with I218 encountered with initialization error on your side? Thanks, Sasha -Original Message- From: Intel-wired-lan

RE: [Intel-wired-lan] e1000e: PHY cann't be initialized correctly on some I218 controllers

Hello Denis, In case this reset help you fix initialization error of I218 you can use it locally on your system. How many system with I218 encountered with initialization error on your side? Thanks, Sasha -Original Message- From: Intel-wired-lan