from:"Ronciak, John"

RE: [PATCH] i40e: don't enable and init FCOE by default when do PF reset

2015-01-09 Thread Ronciak, John

Adding Vasu and Neerav

Cheers,
John

> -Original Message-
> From: Ethan Zhao [mailto:ethan.z...@oracle.com]
> Sent: Friday, January 9, 2015 8:38 AM
> To: Kirsher, Jeffrey T; Brandeburg, Jesse; Allan, Bruce W; Wyborny, Carolyn;
> Skidmore, Donald C; Rose, Gregory V; Vick, Matthew; 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;
> brian.m...@oracle.com; Ethan Zhao
> Subject: [PATCH] i40e: don't enable and init FCOE by default when do PF
> reset
> 
> While do PF reset with function i40e_reset_and_rebuild(), it will call
> i40e_init_pf_fcoe() by default if FCOE is defined, thus if the PF is resetted,
> FCOE will be enabled whatever it was - enabled or not.
> 
> Such bug might be hit when PF resumes from suspend, run diagnostic test
> with ethtool, setup VLAN etc.
> 
> Passed building with v3.19-rc3.
> 
> Signed-off-by: Ethan Zhao 
> ---
>  drivers/net/ethernet/intel/i40e/i40e_main.c | 9 ++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c
> b/drivers/net/ethernet/intel/i40e/i40e_main.c
> index a5f2660..a2572cc 100644
> --- a/drivers/net/ethernet/intel/i40e/i40e_main.c
> +++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
> @@ -6180,9 +6180,12 @@ static void i40e_reset_and_rebuild(struct i40e_pf
> *pf, bool reinit)
>   }
>  #endif /* CONFIG_I40E_DCB */
>  #ifdef I40E_FCOE
> - ret = i40e_init_pf_fcoe(pf);
> - if (ret)
> - dev_info(>pdev->dev, "init_pf_fcoe failed: %d\n", ret);
> + if (pf->flags & I40E_FLAG_FCOE_ENABLED) {
> + ret = i40e_init_pf_fcoe(pf);
> + if (ret)
> + dev_info(>pdev->dev,
> +  "init_pf_fcoe failed: %d\n", ret);
> + }
> 
>  #endif
>   /* do basic switch setup */
> --
> 1.8.3.1

--
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] i40e: don't enable and init FCOE by default when do PF reset

2015-01-09 Thread Ronciak, John

Adding Vasu and Neerav

Cheers,
John

 -Original Message-
 From: Ethan Zhao [mailto:ethan.z...@oracle.com]
 Sent: Friday, January 9, 2015 8:38 AM
 To: Kirsher, Jeffrey T; Brandeburg, Jesse; Allan, Bruce W; Wyborny, Carolyn;
 Skidmore, Donald C; Rose, Gregory V; Vick, Matthew; 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;
 brian.m...@oracle.com; Ethan Zhao
 Subject: [PATCH] i40e: don't enable and init FCOE by default when do PF
 reset
 
 While do PF reset with function i40e_reset_and_rebuild(), it will call
 i40e_init_pf_fcoe() by default if FCOE is defined, thus if the PF is resetted,
 FCOE will be enabled whatever it was - enabled or not.
 
 Such bug might be hit when PF resumes from suspend, run diagnostic test
 with ethtool, setup VLAN etc.
 
 Passed building with v3.19-rc3.
 
 Signed-off-by: Ethan Zhao ethan.z...@oracle.com
 ---
  drivers/net/ethernet/intel/i40e/i40e_main.c | 9 ++---
  1 file changed, 6 insertions(+), 3 deletions(-)
 
 diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c
 b/drivers/net/ethernet/intel/i40e/i40e_main.c
 index a5f2660..a2572cc 100644
 --- a/drivers/net/ethernet/intel/i40e/i40e_main.c
 +++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
 @@ -6180,9 +6180,12 @@ static void i40e_reset_and_rebuild(struct i40e_pf
 *pf, bool reinit)
   }
  #endif /* CONFIG_I40E_DCB */
  #ifdef I40E_FCOE
 - ret = i40e_init_pf_fcoe(pf);
 - if (ret)
 - dev_info(pf-pdev-dev, init_pf_fcoe failed: %d\n, ret);
 + if (pf-flags  I40E_FLAG_FCOE_ENABLED) {
 + ret = i40e_init_pf_fcoe(pf);
 + if (ret)
 + dev_info(pf-pdev-dev,
 +  init_pf_fcoe failed: %d\n, ret);
 + }
 
  #endif
   /* do basic switch setup */
 --
 1.8.3.1

--
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] PCI: Intel 10G NIC ACS quirks

2014-09-29 Thread Ronciak, John

On Fri, Sep 26, 2014 at 05:07:59PM -0600, Alex Williamson wrote:
> Intel has verified there is no peer-to-peer between functions for the 
> below selection of 82598, 82599, and X520 10G NICs.  These NICs lack 
> an ACS capability, so we're not able to determine this isolation 
> without the help of quirks.  Generalize the Solarflare quirk and add 
> these.
> 
> Signed-off-by: Alex Williamson 
> Cc: John Ronciak 

> Applied to pci/virtualization for v3.18, thanks!
Acked-by: John Ronciak 

(I don't k now if this is needed at this point but since Alex asked for it, 
here it is.


Cheers,
John

-Original Message-
From: Bjorn Helgaas [mailto:bhelg...@google.com] 
Sent: Monday, September 29, 2014 12:49 PM
To: Alex Williamson
Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; Ronciak, John
Subject: Re: [PATCH] PCI: Intel 10G NIC ACS quirks

On Fri, Sep 26, 2014 at 05:07:59PM -0600, Alex Williamson wrote:
> Intel has verified there is no peer-to-peer between functions for the 
> below selection of 82598, 82599, and X520 10G NICs.  These NICs lack 
> an ACS capability, so we're not able to determine this isolation 
> without the help of quirks.  Generalize the Solarflare quirk and add 
> these.
> 
> Signed-off-by: Alex Williamson 
> Cc: John Ronciak 

Applied to pci/virtualization for v3.18, thanks!

> ---
> 
>  drivers/pci/quirks.c |   34 --
>  1 file changed, 28 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c index 
> 95239e0..b6c6500 100644
> --- a/drivers/pci/quirks.c
> +++ b/drivers/pci/quirks.c
> @@ -3635,14 +3635,16 @@ static int pci_quirk_intel_pch_acs(struct pci_dev 
> *dev, u16 acs_flags)
>   return acs_flags & ~flags ? 0 : 1;
>  }
>  
> -static int pci_quirk_solarflare_acs(struct pci_dev *dev, u16 
> acs_flags)
> +static int pci_quirk_mf_endpoint_acs(struct pci_dev *dev, u16 
> +acs_flags)
>  {
>   /*
>* SV, TB, and UF are not relevant to multifunction endpoints.
>*
> -  * Solarflare indicates that peer-to-peer between functions is not
> -  * possible, therefore RR, CR, and DT are not implemented.  Mask
> -  * these out as if they were clear in the ACS capabilities register.
> +  * Multifunction devices are only required to implement RR, CR, and DT
> +  * in their ACS capability if they support peer-to-peer transactions.
> +  * Devices matching this quirk have been verified by the vendor to not
> +  * perform peer-to-peer with other functions, allowing us to mask out
> +  * these bits as if they were unimplemented in the ACS capability.
>*/
>   acs_flags &= ~(PCI_ACS_SV | PCI_ACS_TB | PCI_ACS_RR |
>  PCI_ACS_CR | PCI_ACS_UF | PCI_ACS_DT); @@ -3661,8 
> +3663,28 
> @@ static const struct pci_dev_acs_enabled {
>   { PCI_VENDOR_ID_ATI, 0x439d, pci_quirk_amd_sb_acs },
>   { PCI_VENDOR_ID_ATI, 0x4384, pci_quirk_amd_sb_acs },
>   { PCI_VENDOR_ID_ATI, 0x4399, pci_quirk_amd_sb_acs },
> - { PCI_VENDOR_ID_SOLARFLARE, 0x0903, pci_quirk_solarflare_acs },
> - { PCI_VENDOR_ID_SOLARFLARE, 0x0923, pci_quirk_solarflare_acs },
> + { PCI_VENDOR_ID_SOLARFLARE, 0x0903, pci_quirk_mf_endpoint_acs },
> + { PCI_VENDOR_ID_SOLARFLARE, 0x0923, pci_quirk_mf_endpoint_acs },
> + { PCI_VENDOR_ID_INTEL, 0x10C6, pci_quirk_mf_endpoint_acs },
> + { PCI_VENDOR_ID_INTEL, 0x10DB, pci_quirk_mf_endpoint_acs },
> + { PCI_VENDOR_ID_INTEL, 0x10DD, pci_quirk_mf_endpoint_acs },
> + { PCI_VENDOR_ID_INTEL, 0x10E1, pci_quirk_mf_endpoint_acs },
> + { PCI_VENDOR_ID_INTEL, 0x10F1, pci_quirk_mf_endpoint_acs },
> + { PCI_VENDOR_ID_INTEL, 0x10F7, pci_quirk_mf_endpoint_acs },
> + { PCI_VENDOR_ID_INTEL, 0x10F8, pci_quirk_mf_endpoint_acs },
> + { PCI_VENDOR_ID_INTEL, 0x10F9, pci_quirk_mf_endpoint_acs },
> + { PCI_VENDOR_ID_INTEL, 0x10FA, pci_quirk_mf_endpoint_acs },
> + { PCI_VENDOR_ID_INTEL, 0x10FB, pci_quirk_mf_endpoint_acs },
> + { PCI_VENDOR_ID_INTEL, 0x10FC, pci_quirk_mf_endpoint_acs },
> + { PCI_VENDOR_ID_INTEL, 0x1507, pci_quirk_mf_endpoint_acs },
> + { PCI_VENDOR_ID_INTEL, 0x1514, pci_quirk_mf_endpoint_acs },
> + { PCI_VENDOR_ID_INTEL, 0x151C, pci_quirk_mf_endpoint_acs },
> + { PCI_VENDOR_ID_INTEL, 0x1529, pci_quirk_mf_endpoint_acs },
> + { PCI_VENDOR_ID_INTEL, 0x152A, pci_quirk_mf_endpoint_acs },
> + { PCI_VENDOR_ID_INTEL, 0x154D, pci_quirk_mf_endpoint_acs },
> + { PCI_VENDOR_ID_INTEL, 0x154F, pci_quirk_mf_endpoint_acs },
> + { PCI_VENDOR_ID_INTEL, 0x1551, pci_quirk_mf_endpoint_acs },
> + { PCI_VENDOR_ID_INTEL, 0x1558, pci_quirk_mf_endpoint_acs },
>   { PCI_VENDOR_ID_INTEL, PCI_ANY_ID, pci_quirk_intel_pch_acs },

RE: [PATCH] PCI: Intel 10G NIC ACS quirks

2014-09-29 Thread Ronciak, John

On Fri, Sep 26, 2014 at 05:07:59PM -0600, Alex Williamson wrote:
 Intel has verified there is no peer-to-peer between functions for the 
 below selection of 82598, 82599, and X520 10G NICs.  These NICs lack 
 an ACS capability, so we're not able to determine this isolation 
 without the help of quirks.  Generalize the Solarflare quirk and add 
 these.
 
 Signed-off-by: Alex Williamson alex.william...@redhat.com
 Cc: John Ronciak john.ronc...@intel.com

 Applied to pci/virtualization for v3.18, thanks!
Acked-by: John Ronciak john.ronc...@intel.com

(I don't k now if this is needed at this point but since Alex asked for it, 
here it is.


Cheers,
John

-Original Message-
From: Bjorn Helgaas [mailto:bhelg...@google.com] 
Sent: Monday, September 29, 2014 12:49 PM
To: Alex Williamson
Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; Ronciak, John
Subject: Re: [PATCH] PCI: Intel 10G NIC ACS quirks

On Fri, Sep 26, 2014 at 05:07:59PM -0600, Alex Williamson wrote:
 Intel has verified there is no peer-to-peer between functions for the 
 below selection of 82598, 82599, and X520 10G NICs.  These NICs lack 
 an ACS capability, so we're not able to determine this isolation 
 without the help of quirks.  Generalize the Solarflare quirk and add 
 these.
 
 Signed-off-by: Alex Williamson alex.william...@redhat.com
 Cc: John Ronciak john.ronc...@intel.com

Applied to pci/virtualization for v3.18, thanks!

 ---
 
  drivers/pci/quirks.c |   34 --
  1 file changed, 28 insertions(+), 6 deletions(-)
 
 diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c index 
 95239e0..b6c6500 100644
 --- a/drivers/pci/quirks.c
 +++ b/drivers/pci/quirks.c
 @@ -3635,14 +3635,16 @@ static int pci_quirk_intel_pch_acs(struct pci_dev 
 *dev, u16 acs_flags)
   return acs_flags  ~flags ? 0 : 1;
  }
  
 -static int pci_quirk_solarflare_acs(struct pci_dev *dev, u16 
 acs_flags)
 +static int pci_quirk_mf_endpoint_acs(struct pci_dev *dev, u16 
 +acs_flags)
  {
   /*
* SV, TB, and UF are not relevant to multifunction endpoints.
*
 -  * Solarflare indicates that peer-to-peer between functions is not
 -  * possible, therefore RR, CR, and DT are not implemented.  Mask
 -  * these out as if they were clear in the ACS capabilities register.
 +  * Multifunction devices are only required to implement RR, CR, and DT
 +  * in their ACS capability if they support peer-to-peer transactions.
 +  * Devices matching this quirk have been verified by the vendor to not
 +  * perform peer-to-peer with other functions, allowing us to mask out
 +  * these bits as if they were unimplemented in the ACS capability.
*/
   acs_flags = ~(PCI_ACS_SV | PCI_ACS_TB | PCI_ACS_RR |
  PCI_ACS_CR | PCI_ACS_UF | PCI_ACS_DT); @@ -3661,8 
 +3663,28 
 @@ static const struct pci_dev_acs_enabled {
   { PCI_VENDOR_ID_ATI, 0x439d, pci_quirk_amd_sb_acs },
   { PCI_VENDOR_ID_ATI, 0x4384, pci_quirk_amd_sb_acs },
   { PCI_VENDOR_ID_ATI, 0x4399, pci_quirk_amd_sb_acs },
 - { PCI_VENDOR_ID_SOLARFLARE, 0x0903, pci_quirk_solarflare_acs },
 - { PCI_VENDOR_ID_SOLARFLARE, 0x0923, pci_quirk_solarflare_acs },
 + { PCI_VENDOR_ID_SOLARFLARE, 0x0903, pci_quirk_mf_endpoint_acs },
 + { PCI_VENDOR_ID_SOLARFLARE, 0x0923, pci_quirk_mf_endpoint_acs },
 + { PCI_VENDOR_ID_INTEL, 0x10C6, pci_quirk_mf_endpoint_acs },
 + { PCI_VENDOR_ID_INTEL, 0x10DB, pci_quirk_mf_endpoint_acs },
 + { PCI_VENDOR_ID_INTEL, 0x10DD, pci_quirk_mf_endpoint_acs },
 + { PCI_VENDOR_ID_INTEL, 0x10E1, pci_quirk_mf_endpoint_acs },
 + { PCI_VENDOR_ID_INTEL, 0x10F1, pci_quirk_mf_endpoint_acs },
 + { PCI_VENDOR_ID_INTEL, 0x10F7, pci_quirk_mf_endpoint_acs },
 + { PCI_VENDOR_ID_INTEL, 0x10F8, pci_quirk_mf_endpoint_acs },
 + { PCI_VENDOR_ID_INTEL, 0x10F9, pci_quirk_mf_endpoint_acs },
 + { PCI_VENDOR_ID_INTEL, 0x10FA, pci_quirk_mf_endpoint_acs },
 + { PCI_VENDOR_ID_INTEL, 0x10FB, pci_quirk_mf_endpoint_acs },
 + { PCI_VENDOR_ID_INTEL, 0x10FC, pci_quirk_mf_endpoint_acs },
 + { PCI_VENDOR_ID_INTEL, 0x1507, pci_quirk_mf_endpoint_acs },
 + { PCI_VENDOR_ID_INTEL, 0x1514, pci_quirk_mf_endpoint_acs },
 + { PCI_VENDOR_ID_INTEL, 0x151C, pci_quirk_mf_endpoint_acs },
 + { PCI_VENDOR_ID_INTEL, 0x1529, pci_quirk_mf_endpoint_acs },
 + { PCI_VENDOR_ID_INTEL, 0x152A, pci_quirk_mf_endpoint_acs },
 + { PCI_VENDOR_ID_INTEL, 0x154D, pci_quirk_mf_endpoint_acs },
 + { PCI_VENDOR_ID_INTEL, 0x154F, pci_quirk_mf_endpoint_acs },
 + { PCI_VENDOR_ID_INTEL, 0x1551, pci_quirk_mf_endpoint_acs },
 + { PCI_VENDOR_ID_INTEL, 0x1558, pci_quirk_mf_endpoint_acs },
   { PCI_VENDOR_ID_INTEL, PCI_ANY_ID, pci_quirk_intel_pch_acs },
   { 0 }
  };
 
--
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

RE: [E1000-devel] [PATCH] e1000: remove the check: skb->len<=0

2014-05-13 Thread Ronciak, John

> -Original Message-
> From: xuyongjia...@gmail.com [mailto:xuyongjia...@gmail.com]
> Sent: Monday, May 12, 2014 10:07 PM
> To: eric.duma...@gmail.com
> Cc: e1000-de...@lists.sourceforge.net; net...@vger.kernel.org; linux-
> ker...@vger.kernel.org; Yongjian Xu
> Subject: [E1000-devel] [PATCH] e1000: remove the check: skb->len<=0
> 
> From: Yongjian Xu 
> 
> There is no case skb->len would be 0 or 'negative'.
> Remove the check.
> 
> Signed-off-by: Yongjian Xu 
> ---
>  drivers/net/ethernet/intel/e1000/e1000_main.c | 5 -
>  1 file changed, 5 deletions(-)
> 
> diff --git a/drivers/net/ethernet/intel/e1000/e1000_main.c
> b/drivers/net/ethernet/intel/e1000/e1000_main.c
> index 27058df..660971f 100644
> --- a/drivers/net/ethernet/intel/e1000/e1000_main.c
> +++ b/drivers/net/ethernet/intel/e1000/e1000_main.c
> @@ -3105,11 +3105,6 @@ static netdev_tx_t e1000_xmit_frame(struct
> sk_buff *skb,
>*/
>   tx_ring = adapter->tx_ring;
> 
> - if (unlikely(skb->len <= 0)) {
> - dev_kfree_skb_any(skb);
> - return NETDEV_TX_OK;
> - }
> -
>   /* On PCI/PCI-X HW, if packet size is less than ETH_ZLEN,
>* packets may get corrupted during padding by HW.
>* To WA this issue, pad all small packets manually.
> --
> 1.9.1
What is the exact problem that this is fixing?  Did you have a test case that 
showed a problem with it?

Cheers,
John


--
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] e1000: remove the check: skb-len=0

2014-05-13 Thread Ronciak, John

 -Original Message-
 From: xuyongjia...@gmail.com [mailto:xuyongjia...@gmail.com]
 Sent: Monday, May 12, 2014 10:07 PM
 To: eric.duma...@gmail.com
 Cc: e1000-de...@lists.sourceforge.net; net...@vger.kernel.org; linux-
 ker...@vger.kernel.org; Yongjian Xu
 Subject: [E1000-devel] [PATCH] e1000: remove the check: skb-len=0
 
 From: Yongjian Xu xuyongjia...@gmail.com
 
 There is no case skb-len would be 0 or 'negative'.
 Remove the check.
 
 Signed-off-by: Yongjian Xu xuyongjia...@gmail.com
 ---
  drivers/net/ethernet/intel/e1000/e1000_main.c | 5 -
  1 file changed, 5 deletions(-)
 
 diff --git a/drivers/net/ethernet/intel/e1000/e1000_main.c
 b/drivers/net/ethernet/intel/e1000/e1000_main.c
 index 27058df..660971f 100644
 --- a/drivers/net/ethernet/intel/e1000/e1000_main.c
 +++ b/drivers/net/ethernet/intel/e1000/e1000_main.c
 @@ -3105,11 +3105,6 @@ static netdev_tx_t e1000_xmit_frame(struct
 sk_buff *skb,
*/
   tx_ring = adapter-tx_ring;
 
 - if (unlikely(skb-len = 0)) {
 - dev_kfree_skb_any(skb);
 - return NETDEV_TX_OK;
 - }
 -
   /* On PCI/PCI-X HW, if packet size is less than ETH_ZLEN,
* packets may get corrupted during padding by HW.
* To WA this issue, pad all small packets manually.
 --
 1.9.1
What is the exact problem that this is fixing?  Did you have a test case that 
showed a problem with it?

Cheers,
John


--
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] e1000e 0000:00:19.0 eth0: Hardware Error

2014-04-10 Thread Ronciak, John

Boris,

What kind of system (platform) is this happening on?  It's a LOM correct?  Can 
you run 'lspci -vvv' and output the results?

Thanks.

Cheers,
John


> -Original Message-
> From: Borislav Petkov [mailto:b...@alien8.de]
> Sent: Thursday, April 10, 2014 5:00 AM
> To: e1000-de...@lists.sourceforge.net
> Cc: net...@vger.kernel.org; lkml
> Subject: [E1000-devel] e1000e :00:19.0 eth0: Hardware Error
> 
> Hi guys,
> 
> I started getting those sporadic
> 
> [133178.640890] e1000e :00:19.0 eth0: Hardware Error
> [133179.293148] e1000e :00:19.0: irq 45 for MSI/MSI-X
> [133179.394226] e1000e :00:19.0: irq 45 for MSI/MSI-X
> [133179.397200] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
> [133181.338258] e1000e :00:19.0 eth0: Hardware Error
> [133182.077209] pci_pm_runtime_suspend():
> e1000_runtime_suspend+0x0/0x40 [e1000e] returns -2
> 
> messages with 3.14 and I haven't had them before. After this, I do
> 
> rmmod e1000e && modprobe e1000e
> 
> and I get:
> 
> [133221.891555] e1000e :00:19.0 eth0: removed PHC [133228.181552]
> e1000e: Intel(R) PRO/1000 Network Driver - 2.3.2-k [133228.181562]
> e1000e: Copyright(c) 1999 - 2013 Intel Corporation.
> [133228.182241] e1000e :00:19.0: Interrupt Throttling Rate
> (ints/sec) set to dynamic conservative mode [133228.182332] e1000e
> :00:19.0: irq 45 for MSI/MSI-X [133229.009837] e1000e: probe of
> :00:19.0 failed with error -2
>   ^^
> 
> [133307.107217] e1000e: Intel(R) PRO/1000 Network Driver - 2.3.2-k
> [133307.107228] e1000e: Copyright(c) 1999 - 2013 Intel Corporation.
> [133307.107814] e1000e :00:19.0: Interrupt Throttling Rate
> (ints/sec) set to dynamic conservative mode [133307.107959] e1000e
> :00:19.0: irq 45 for MSI/MSI-X [133307.935921] e1000e: probe of
> :00:19.0 failed with error -2
> 
> ...
> 
> [133841.361905] e1000e: Intel(R) PRO/1000 Network Driver - 2.3.2-k
> [133841.361914] e1000e: Copyright(c) 1999 - 2013 Intel Corporation.
> [133841.362451] e1000e :00:19.0: Interrupt Throttling Rate
> (ints/sec) set to dynamic conservative mode [133841.362520] e1000e
> :00:19.0: irq 45 for MSI/MSI-X [133842.192710] e1000e: probe of
> :00:19.0 failed with error -2
> 
> each time I try and eth0 is dead. Only a reboot helps, I've come to
> find out so far.
> 
> Any ideas?
> 
> --
> Regards/Gruss,
> Boris.
> 
> Sent from a fat crate under my desk. Formatting is fine.
> --
> 
> ---
> ---
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration Continuously
> Automate Build, Test & Deployment Start a new project now. Try Jenkins
> in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees
> ___
> 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] e1000e 0000:00:19.0 eth0: Hardware Error

2014-04-10 Thread Ronciak, John

Boris,

What kind of system (platform) is this happening on?  It's a LOM correct?  Can 
you run 'lspci -vvv' and output the results?

Thanks.

Cheers,
John


 -Original Message-
 From: Borislav Petkov [mailto:b...@alien8.de]
 Sent: Thursday, April 10, 2014 5:00 AM
 To: e1000-de...@lists.sourceforge.net
 Cc: net...@vger.kernel.org; lkml
 Subject: [E1000-devel] e1000e :00:19.0 eth0: Hardware Error
 
 Hi guys,
 
 I started getting those sporadic
 
 [133178.640890] e1000e :00:19.0 eth0: Hardware Error
 [133179.293148] e1000e :00:19.0: irq 45 for MSI/MSI-X
 [133179.394226] e1000e :00:19.0: irq 45 for MSI/MSI-X
 [133179.397200] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
 [133181.338258] e1000e :00:19.0 eth0: Hardware Error
 [133182.077209] pci_pm_runtime_suspend():
 e1000_runtime_suspend+0x0/0x40 [e1000e] returns -2
 
 messages with 3.14 and I haven't had them before. After this, I do
 
 rmmod e1000e  modprobe e1000e
 
 and I get:
 
 [133221.891555] e1000e :00:19.0 eth0: removed PHC [133228.181552]
 e1000e: Intel(R) PRO/1000 Network Driver - 2.3.2-k [133228.181562]
 e1000e: Copyright(c) 1999 - 2013 Intel Corporation.
 [133228.182241] e1000e :00:19.0: Interrupt Throttling Rate
 (ints/sec) set to dynamic conservative mode [133228.182332] e1000e
 :00:19.0: irq 45 for MSI/MSI-X [133229.009837] e1000e: probe of
 :00:19.0 failed with error -2
   ^^
 
 [133307.107217] e1000e: Intel(R) PRO/1000 Network Driver - 2.3.2-k
 [133307.107228] e1000e: Copyright(c) 1999 - 2013 Intel Corporation.
 [133307.107814] e1000e :00:19.0: Interrupt Throttling Rate
 (ints/sec) set to dynamic conservative mode [133307.107959] e1000e
 :00:19.0: irq 45 for MSI/MSI-X [133307.935921] e1000e: probe of
 :00:19.0 failed with error -2
 
 ...
 
 [133841.361905] e1000e: Intel(R) PRO/1000 Network Driver - 2.3.2-k
 [133841.361914] e1000e: Copyright(c) 1999 - 2013 Intel Corporation.
 [133841.362451] e1000e :00:19.0: Interrupt Throttling Rate
 (ints/sec) set to dynamic conservative mode [133841.362520] e1000e
 :00:19.0: irq 45 for MSI/MSI-X [133842.192710] e1000e: probe of
 :00:19.0 failed with error -2
 
 each time I try and eth0 is dead. Only a reboot helps, I've come to
 find out so far.
 
 Any ideas?
 
 --
 Regards/Gruss,
 Boris.
 
 Sent from a fat crate under my desk. Formatting is fine.
 --
 
 ---
 ---
 Put Bad Developers to Shame
 Dominate Development with Jenkins Continuous Integration Continuously
 Automate Build, Test  Deployment Start a new project now. Try Jenkins
 in the cloud.
 http://p.sf.net/sfu/13600_Cloudbees
 ___
 E1000-devel mailing list
 e1000-de...@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/e1000-devel
 To learn more about Intel#174; 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: [PATCH v2 0/8] Thunderbolt workarounds

2013-07-03 Thread Ronciak, John

Apple does their own thing and do not talk to Intel about it at all. This 
includes writing special drivers and user-space components.  So we (Intel) 
don't know so we can't comment about it.  Sorry.

Cheers,
John


> -Original Message-
> From: Matthew Garrett [mailto:mj...@srcf.ucam.org]
> Sent: Wednesday, July 03, 2013 1:36 PM
> To: Ronciak, John
> Cc: Greg Kroah-Hartman; Mika Westerberg; Bjorn Helgaas; Wysocki, Rafael
> J; Jesse Barnes; Yinghai Lu; Penner, Miles J; Allan, Bruce W; Heikki
> Krogerus; Kirill A. Shutemov; linux-kernel@vger.kernel.org; linux-
> a...@vger.kernel.org; linux-...@vger.kernel.org; x...@kernel.org
> Subject: Re: [PATCH v2 0/8] Thunderbolt workarounds
> 
> On Wed, Jul 03, 2013 at 07:57:21PM +, Ronciak, John wrote:
> > Are you talking about Apple platforms specifically?
> 
> Yeah, that's the specific example.
> 
> --
> Matthew Garrett | mj...@srcf.ucam.org
--
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 0/8] Thunderbolt workarounds

2013-07-03 Thread Ronciak, John

Are you talking about Apple platforms specifically?

Cheers,
John


> -Original Message-
> From: Matthew Garrett [mailto:mj...@srcf.ucam.org]
> Sent: Wednesday, July 03, 2013 11:45 AM
> To: Greg Kroah-Hartman
> Cc: Mika Westerberg; Bjorn Helgaas; Wysocki, Rafael J; Jesse Barnes;
> Yinghai Lu; Ronciak, John; Penner, Miles J; Allan, Bruce W; Heikki
> Krogerus; Kirill A. Shutemov; linux-kernel@vger.kernel.org; linux-
> a...@vger.kernel.org; linux-...@vger.kernel.org; x...@kernel.org
> Subject: Re: [PATCH v2 0/8] Thunderbolt workarounds
> 
> On Wed, Jul 03, 2013 at 11:33:11AM -0700, Greg Kroah-Hartman wrote:
> > On Wed, Jul 03, 2013 at 07:29:00PM +0100, Matthew Garrett wrote:
> > > Are there any plans to provide native support for the Thunderbolt
> > > controller, rather than relying on system management mode?
> >
> > For what specific hardware platform?  For the ones that this patchset
> > controls, the OS doesn't have access to the Thunderbolt controller as
> > far as I can tell, it all happens through the ACPI and PCI hotplug
> > interface.
> 
> Given that there exist platforms without the SMM implementation,
> there's presumably either a controller or chipset register that
> controls whether SMIs are generated in response to Thunderbolt events.
> 
> --
> Matthew Garrett | mj...@srcf.ucam.org
--
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 0/8] Thunderbolt workarounds

2013-07-03 Thread Ronciak, John

Are you talking about Apple platforms specifically?

Cheers,
John

 -Original Message-
 From: Matthew Garrett [mailto:mj...@srcf.ucam.org]
 Sent: Wednesday, July 03, 2013 11:45 AM
 To: Greg Kroah-Hartman
 Cc: Mika Westerberg; Bjorn Helgaas; Wysocki, Rafael J; Jesse Barnes;
 Yinghai Lu; Ronciak, John; Penner, Miles J; Allan, Bruce W; Heikki
 Krogerus; Kirill A. Shutemov; linux-kernel@vger.kernel.org; linux-
 a...@vger.kernel.org; linux-...@vger.kernel.org; x...@kernel.org
 Subject: Re: [PATCH v2 0/8] Thunderbolt workarounds

 On Wed, Jul 03, 2013 at 11:33:11AM -0700, Greg Kroah-Hartman wrote:
  On Wed, Jul 03, 2013 at 07:29:00PM +0100, Matthew Garrett wrote:
   Are there any plans to provide native support for the Thunderbolt
   controller, rather than relying on system management mode?

  For what specific hardware platform?  For the ones that this patchset
  controls, the OS doesn't have access to the Thunderbolt controller as
  far as I can tell, it all happens through the ACPI and PCI hotplug
  interface.

 Given that there exist platforms without the SMM implementation,
 there's presumably either a controller or chipset register that
 controls whether SMIs are generated in response to Thunderbolt events.

 --
 Matthew Garrett | mj...@srcf.ucam.org
--
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 0/8] Thunderbolt workarounds

2013-07-03 Thread Ronciak, John

Apple does their own thing and do not talk to Intel about it at all. This 
includes writing special drivers and user-space components.  So we (Intel) 
don't know so we can't comment about it.  Sorry.

Cheers,
John


 -Original Message-
 From: Matthew Garrett [mailto:mj...@srcf.ucam.org]
 Sent: Wednesday, July 03, 2013 1:36 PM
 To: Ronciak, John
 Cc: Greg Kroah-Hartman; Mika Westerberg; Bjorn Helgaas; Wysocki, Rafael
 J; Jesse Barnes; Yinghai Lu; Penner, Miles J; Allan, Bruce W; Heikki
 Krogerus; Kirill A. Shutemov; linux-kernel@vger.kernel.org; linux-
 a...@vger.kernel.org; linux-...@vger.kernel.org; x...@kernel.org
 Subject: Re: [PATCH v2 0/8] Thunderbolt workarounds
 
 On Wed, Jul 03, 2013 at 07:57:21PM +, Ronciak, John wrote:
  Are you talking about Apple platforms specifically?
 
 Yeah, that's the specific example.
 
 --
 Matthew Garrett | mj...@srcf.ucam.org
--
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] i40e: don't enable and init FCOE by default when do PF reset

RE: [PATCH] i40e: don't enable and init FCOE by default when do PF reset

RE: [PATCH] PCI: Intel 10G NIC ACS quirks

RE: [PATCH] PCI: Intel 10G NIC ACS quirks

RE: [E1000-devel] [PATCH] e1000: remove the check: skb->len<=0

RE: [E1000-devel] [PATCH] e1000: remove the check: skb-len=0

RE: [E1000-devel] e1000e 0000:00:19.0 eth0: Hardware Error

RE: [E1000-devel] e1000e 0000:00:19.0 eth0: Hardware Error

RE: [PATCH v2 0/8] Thunderbolt workarounds

RE: [PATCH v2 0/8] Thunderbolt workarounds

RE: [PATCH v2 0/8] Thunderbolt workarounds

RE: [PATCH v2 0/8] Thunderbolt workarounds

12 matches

Site Navigation

Mail list logo

Footer information