Re: [E1000-devel] bug I219 - e1000e on VLAN network - Detected Hardware Unit Hang - kernel 5.15.44

[Fujinaka, Todd]

I think this issue has been finally fixed recently after several attempts. The 
patches haven't hit the mainline kernel yet but should have been fixed in the 
intel-wired-lan kernel:
85988cbc0f22 ("e1000e: Enable GPT clock before sending message to CSME", 
2022-06-27)

There's a commit following that as well reverting one of the previous attempts 
to fix things:
46d6a94581e8 ("Revert "e1000e: Fix possible HW unit hang after an s0ix exit"", 
2022-06-27)

The intel-wired-lan kernel can be found at:
https://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue.git/

Todd Fujinaka
Software Application Engineer
Ethernet Products Group
Intel Corporation
todd.fujin...@intel.com

-Original Message-
From: Martin Kratochvíl via E1000-devel  
Sent: Friday, June 17, 2022 10:49 PM
To: e1000-de...@lists.sf.net
Subject: [E1000-devel] bug I219 - e1000e on VLAN network - Detected Hardware 
Unit Hang - kernel 5.15.44

Hello,
i try 3 pieces of Gigabyte Technology Co., Ltd. H410M H V3/H410M H V3, BIOS FC 
03/25/2022 with integrated intel ethernet card I219_V14

The problem is, that card is working only few second, than stop for few second 
and repeating infinitely.
It happen on busy network with vlan. Syslog at bottom

Problem detected on vanilla kernel 5.15.44. I could test newer kernel, but 
there is no e1000e changes yet.

Hardware:
00:1f.6 Ethernet controller: Intel Corporation Device 15fa (rev 11)
     Subsystem: Gigabyte Technology Co., Ltd Device e000
     Flags: bus master, fast devsel, latency 0, IRQ 123
     Memory at 5130 (32-bit, non-prefetchable) [size=128K]
     Capabilities: [c8] Power Management version 3
     Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
     Kernel driver in use: e1000e
     Kernel modules: e1000e


User solution to avoid this problem is disabling tx and rx checksumming on card.
#ethtool -K eth0 tx off rx off

But the problem is in the driver (e1000e) for this network card. For another 
intel card this driver works fine. Another network module  works fine too.
Is it possible, at first, make something to disable checksumming when module is 
loaded for this I219_V14?

I try download and compile latest e1000e version 3.8.7 against kernel
5.15.44 but its incompatible.


Syslog with problem when enabled checksumming on card

   100.781868] e1000e :00:1f.6 eth0: Detected Hardware Unit Hang:
  TDH  
  TDT  <28>
  next_to_use  <28>
  next_to_clean    
    buffer_info[next_to_clean]:
  time_stamp   
  next_to_watch    
  jiffies  
  next_to_watch.status <0>
    MAC Status <40080083>
    PHY Status <796d>
    PHY 1000BASE-T Status  <3800>
    PHY Extended Status    <3000>
    PCI Status <10>
[  102.765865] e1000e :00:1f.6 eth0: Detected Hardware Unit Hang:
  TDH  
  TDT  <28>
  next_to_use  <28>
  next_to_clean    
    buffer_info[next_to_clean]:
  time_stamp   
  next_to_watch    
  jiffies  
  next_to_watch.status <0>
    MAC Status <40080083>
    PHY Status <796d>
    PHY 1000BASE-T Status  <3800>
    PHY Extended Status    <3000>
    PCI Status <10>
[  104.813867] e1000e :00:1f.6 eth0: Detected Hardware Unit Hang:
  TDH  
  TDT  <28>
  next_to_use  <28>
  next_to_clean    
    buffer_info[next_to_clean]:
  time_stamp   
  next_to_watch    
  jiffies  
  next_to_watch.status <0>
    MAC Status <40080083>
    PHY Status <796d>
    PHY 1000BASE-T Status  <3800>
    PHY Extended Status    <3000>
    PCI Status <10>


-- 
*Bc. Martin Kratochvíl*
jednatel Altnet s.r.o.  facebook icon 
Logo*telefon:*
*mobil:*
*kancelář:*
*e-mail:*
*web:*
+420317471483
+420776882228
+420317471471
martin.kratoch...@altnet.cz
*www.skvely.net* 




___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
https://forums.intel.com/s/topic/0TO0P0018NbWAI/intel-ethernet

___
E1000-devel 

Re: [E1000-devel] alloc too much memory for the driver[ice-5.8.0/ice-1.6.7]

[Fujinaka, Todd]

How many queue pairs do you have allocated?

Todd Fujinaka
Software Application Engineer
Ethernet Products Group
Intel Corporation
todd.fujin...@intel.com

-Original Message-
From: yankun  
Sent: Monday, June 13, 2022 8:08 PM
To: e1000-de...@lists.sf.net
Subject: [E1000-devel] alloc too much memory for the driver[ice-5.8.0/ice-1.6.7]

Dear,


I have a Ethernet controller, with the device information ,


I had test the ice-1.5.8  and ice-1.6.7, when insmod the kernel module , the 
driver will alloc about 64GB memory.


the dmesg out:


thanks.
















--

不要浪费生命！
___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
https://forums.intel.com/s/topic/0TO0P0018NbWAI/intel-ethernet

___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
https://forums.intel.com/s/topic/0TO0P0018NbWAI/intel-ethernet

Re: [E1000-devel] alloc too much memory for the driver[ice-5.8.0/ice-1.6.7]

[Fujinaka, Todd]

Sorry I missed this earlier. I'm asking the appropriate team.

Todd Fujinaka
Software Application Engineer
Ethernet Products Group
Intel Corporation
todd.fujin...@intel.com

-Original Message-
From: yankun  
Sent: Monday, June 13, 2022 8:08 PM
To: e1000-de...@lists.sf.net
Subject: [E1000-devel] alloc too much memory for the driver[ice-5.8.0/ice-1.6.7]

Dear,


I have a Ethernet controller, with the device information ,


I had test the ice-1.5.8  and ice-1.6.7, when insmod the kernel module , the 
driver will alloc about 64GB memory.


the dmesg out:


thanks.
















--

不要浪费生命！
___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
https://forums.intel.com/s/topic/0TO0P0018NbWAI/intel-ethernet

___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
https://forums.intel.com/s/topic/0TO0P0018NbWAI/intel-ethernet

Re: [E1000-devel] VF resetting error

[Fujinaka, Todd]

I've been informed by the DPDK team that igb_uio is deprecated and no longer 
supported.  The recommendation is to move to vfio-pci.

Todd Fujinaka
Software Application Engineer
Ethernet Products Group
Intel Corporation
todd.fujin...@intel.com

-Original Message-
From: Fujinaka, Todd  
Sent: Tuesday, May 31, 2022 8:43 AM
To: kratika varshney ; e1000-de...@lists.sf.net
Subject: Re: [E1000-devel] VF resetting error

I'm not sure if the DPDK team follows this mailing list. I'd suggest going to 
dpdk.org and inquiring there. I'll forward this to my DPDK contacts as well.

Todd Fujinaka
Software Application Engineer
Ethernet Products Group
Intel Corporation
todd.fujin...@intel.com

-Original Message-
From: kratika varshney  
Sent: Sunday, May 29, 2022 10:08 PM
To: e1000-de...@lists.sf.net
Subject: [E1000-devel] VF resetting error

Hi,

I am facing a problem with DPDK-20.05 with i40e driver.

May 16 11:09:14 35209300b8bb fpa[9282]: EAL: Probing VFIO support...

May 16 11:09:16 35209300b8bb fpa[9282]: EAL: PCI device :18:06.1 on NUMA 
socket 0

May 16 11:09:16 35209300b8bb fpa[9282]: EAL:   probe driver: 8086:154c
net_i40e_vf

May 16 11:09:16 35209300b8bb kernel: [  141.053103] 026: igb_uio
:18:06.1: uio device registered with irq 443

May 16 11:09:18 35209300b8bb fpa[9282]: i40evf_reset_vf(): VF is still resetting

May 16 11:09:18 35209300b8bb fpa[9282]: i40evf_init_vf(): reset NIC failed

May 16 11:09:18 35209300b8bb fpa[9282]: i40evf_dev_init(): Init vf failed May 
16 11:09:18 35209300b8bb fpa[9282]: EAL: Requested device :18:06.1 cannot 
be used

___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
https://forums.intel.com/s/topic/0TO0P0018NbWAI/intel-ethernet


___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
https://forums.intel.com/s/topic/0TO0P0018NbWAI/intel-ethernet



___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
https://forums.intel.com/s/topic/0TO0P0018NbWAI/intel-ethernet

Re: [E1000-devel] VF resetting error

[Fujinaka, Todd]

I'm not sure if the DPDK team follows this mailing list. I'd suggest going to 
dpdk.org and inquiring there. I'll forward this to my DPDK contacts as well.

Todd Fujinaka
Software Application Engineer
Ethernet Products Group
Intel Corporation
todd.fujin...@intel.com

-Original Message-
From: kratika varshney  
Sent: Sunday, May 29, 2022 10:08 PM
To: e1000-de...@lists.sf.net
Subject: [E1000-devel] VF resetting error

Hi,

I am facing a problem with DPDK-20.05 with i40e driver.

May 16 11:09:14 35209300b8bb fpa[9282]: EAL: Probing VFIO support...

May 16 11:09:16 35209300b8bb fpa[9282]: EAL: PCI device :18:06.1 on NUMA 
socket 0

May 16 11:09:16 35209300b8bb fpa[9282]: EAL:   probe driver: 8086:154c
net_i40e_vf

May 16 11:09:16 35209300b8bb kernel: [  141.053103] 026: igb_uio
:18:06.1: uio device registered with irq 443

May 16 11:09:18 35209300b8bb fpa[9282]: i40evf_reset_vf(): VF is still resetting

May 16 11:09:18 35209300b8bb fpa[9282]: i40evf_init_vf(): reset NIC failed

May 16 11:09:18 35209300b8bb fpa[9282]: i40evf_dev_init(): Init vf failed May 
16 11:09:18 35209300b8bb fpa[9282]: EAL: Requested device :18:06.1 cannot 
be used

___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
https://forums.intel.com/s/topic/0TO0P0018NbWAI/intel-ethernet


___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
https://forums.intel.com/s/topic/0TO0P0018NbWAI/intel-ethernet

Re: [E1000-devel] [igbvf] Accessing PTP clock from a Virtual Function

[Fujinaka, Todd]

Not everything in the hardware is enabled in the software. We do not appear to 
be using the register you mention.

I have been told by those more familiar with PTP that the Time Sync registers 
are in chapter 8.16 and are only accessible through the PF.

Todd Fujinaka
Software Application Engineer
Ethernet Products Group
Intel Corporation
todd.fujin...@intel.com

-Original Message-
From: b.von_h...@wzl.rwth-aachen.de  
Sent: Thursday, May 5, 2022 5:41 AM
To: e1000-devel@lists.sourceforge.net
Subject: [E1000-devel] [igbvf] Accessing PTP clock from a Virtual Function

Hello,

I'd like to access the PTP timer of an i350T2V2 from a VF. The Datasheet (Rev. 
2.6) states in section 7.8.2.12.2 that "VMs have access to the real time clock 
register". But the only timer-related register which is mapped to a VF I could 
find is the free-running timer (VTFRTIMER at 0x1048). So I'm kind of confused.

P.S. yes I know that there is ptp_kvm module, but it uses hypercalls which I'd 
like to avoid.

Thanks a lot,

Bjarne


___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
https://forums.intel.com/s/topic/0TO0P0018NbWAI/intel-ethernet


___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
https://forums.intel.com/s/topic/0TO0P0018NbWAI/intel-ethernet

Re: [E1000-devel] tc changing mqprio parameters X710-T4L

[Fujinaka, Todd]

I had a couple more questions from the developer about your requirements.

What is needed: is speed change, TC reconfig, queue number change correct?

Would it be acceptable to see packet loss during reconfiguration with changes 
to the configuration?

Todd Fujinaka
Software Application Engineer
Ethernet Products Group
Intel Corporation
todd.fujin...@intel.com

-Original Message-
From: Fujinaka, Todd  
Sent: Tuesday, April 26, 2022 8:34 AM
To: David Hayes 
Cc: e1000-de...@lists.sf.net
Subject: Re: [E1000-devel] tc changing mqprio parameters X710-T4L

OK. I'll let you know when I get some updates from the developers.

Todd Fujinaka
Software Application Engineer
Ethernet Products Group
Intel Corporation
todd.fujin...@intel.com

-Original Message-
From: David Hayes 
Sent: Tuesday, April 26, 2022 6:47 AM
To: Fujinaka, Todd 
Cc: e1000-de...@lists.sf.net
Subject: Re: [E1000-devel] tc changing mqprio parameters X710-T4L

Hi Todd,

Thanks for this. I have confirmed that what the engineering team suggest as a 
work around does work on our equipment. 
However, for our application we do need to leave the filters on.

Thanks so much for your help.

Kind regards,

David

On Tue, Apr 26 2022 at 13:29, "Fujinaka, Todd" 
 wrote:

> I got a reply from the engineering team:
>
> A workaround is to reinitialize everything. Instead of:
>
> tc qdisc replace dev enp130s0f0 root mqprio num_tc 1 hw 1 mode channel 
> shaper bw_rlimit min_rate 0Mbit max_rate 500Mbit map 0 0 0 0 0 0 0 0 
> queues 1@0 tc qdisc change dev enp130s0f0 root mqprio num_tc 1 hw 1 
> mode channel shaper bw_rlimit min_rate 0Mbit max_rate 200Mbit map 0 0
> 0 0 0 0 0 0 queues 1@0
>
> Can you do this:
> tc qdisc replace dev enp130s0f0 root mqprio num_tc 1 hw 1 mode channel 
> shaper bw_rlimit min_rate 0Mbit max_rate 500Mbit map 0 0 0 0 0 0 0 0 
> queues 1@0 tc qdisc del dev enp130s0f0 root tc qdisc replace dev
> enp130s0f0 root mqprio num_tc 1 hw 1 mode channel shaper bw_rlimit 
> min_rate 0Mbit max_rate 200Mbit map 0 0 0 0 0 0 0 0 queues 1@0
>
> They did mention this would inactivate the filters, so if you need 
> leave them on we'll need to do some more work on our end.
>
> Todd Fujinaka
> Software Application Engineer
> Ethernet Products Group
> Intel Corporation
> todd.fujin...@intel.com
>
> -Original Message-
> From: David Hayes 
> Sent: Thursday, April 21, 2022 2:47 AM
> To: Fujinaka, Todd 
> Cc: e1000-de...@lists.sf.net
> Subject: Re: [E1000-devel] tc changing mqprio parameters X710-T4L
>
> Hi Todd,
>
> Thank you for getting back to me. It is probably easier if you file 
> the bug.
>
> A little more information in case it is useful:
>
> We have also tried this running the 5.17.1 kernel with the same 
> result.
>
> When the OS starts, the interfaces are initially given default 
> fq_codel qdiscs. We are able to replace these with the mqprio qdisc, 
> but after doing that we can make no further changes.
>
> The cards have the latest (8.60 version) firmware installed.
>
> Thanks and regards,
>
> David
>
>
> On Wed, Apr 20 2022 at 19:01, "Fujinaka, Todd" 
>  wrote:
>
>> Do you have some way to file a bug with us through your factory 
>> contact? Otherwise I will file a bug and then relay the info via 
>> email.
>>
>> Todd Fujinaka
>> Software Application Engineer
>> Ethernet Products Group
>> Intel Corporation
>> todd.fujin...@intel.com
>>
>> -Original Message-
>> From: David Hayes 
>> Sent: Wednesday, April 13, 2022 5:27 AM
>> To: e1000-de...@lists.sf.net
>> Subject: [E1000-devel] tc changing mqprio parameters X710-T4L
>>
>>
>> Hi list,
>>
>> We are using a couple of X710-T4L cards in an experimental testbed.
>> The computer with the cards is currently manjaro linux
>> 5.17rc7 kernel, and cards have been updated with the latest nvm 8.60.
>> As part of the work we wish to periodically change the shapers' 
>> max_rate parameter.
>>
>> We set up the qdisc as follows:
>>
>> # tc qdisc replace dev  root mqprio num_tc 1 hw 1 mode
>>   channel shaper bw_rlimit min_rate 0Mbit max_rate 500Mbit map 
>>   0 
>>   0
>>   0 0 0 0 0 0 queues 1@0
>>
>> This works well and we are able to confirm the 500Mbit limit 
>> experimentally.
>>
>> However, when we try to change the speed:
>>
>> # tc qdisc change dev  root mqprio num_tc 1 hw 1 mode
>>   channel shaper bw_rlimit min_rate 0Mbit max_rate 200Mbit map 
>>   0 
>>   0
>>   0 0 0 0 0 0 queues 1@0
>>
>> we get the following error message:
>>
>> Change operation is not supported by specified qdisc
>>
>> 

Re: [E1000-devel] tc changing mqprio parameters X710-T4L

[Fujinaka, Todd]

OK. I'll let you know when I get some updates from the developers.

Todd Fujinaka
Software Application Engineer
Ethernet Products Group
Intel Corporation
todd.fujin...@intel.com

-Original Message-
From: David Hayes  
Sent: Tuesday, April 26, 2022 6:47 AM
To: Fujinaka, Todd 
Cc: e1000-de...@lists.sf.net
Subject: Re: [E1000-devel] tc changing mqprio parameters X710-T4L

Hi Todd,

Thanks for this. I have confirmed that what the engineering team suggest as a 
work around does work on our equipment. 
However, for our application we do need to leave the filters on.

Thanks so much for your help.

Kind regards,

David

On Tue, Apr 26 2022 at 13:29, "Fujinaka, Todd" 
 wrote:

> I got a reply from the engineering team:
>
> A workaround is to reinitialize everything. Instead of:
>
> tc qdisc replace dev enp130s0f0 root mqprio num_tc 1 hw 1 mode channel 
> shaper bw_rlimit min_rate 0Mbit max_rate 500Mbit map 0 0 0 0 0 0 0 0 
> queues 1@0 tc qdisc change dev enp130s0f0 root mqprio num_tc 1 hw 1 
> mode channel shaper bw_rlimit min_rate 0Mbit max_rate 200Mbit map 0 0 
> 0 0 0 0 0 0 queues 1@0
>
> Can you do this:
> tc qdisc replace dev enp130s0f0 root mqprio num_tc 1 hw 1 mode channel 
> shaper bw_rlimit min_rate 0Mbit max_rate 500Mbit map 0 0 0 0 0 0 0 0 
> queues 1@0 tc qdisc del dev enp130s0f0 root tc qdisc replace dev 
> enp130s0f0 root mqprio num_tc 1 hw 1 mode channel shaper bw_rlimit 
> min_rate 0Mbit max_rate 200Mbit map 0 0 0 0 0 0 0 0 queues 1@0
>
> They did mention this would inactivate the filters, so if you need 
> leave them on we'll need to do some more work on our end.
>
> Todd Fujinaka
> Software Application Engineer
> Ethernet Products Group
> Intel Corporation
> todd.fujin...@intel.com
>
> -Original Message-
> From: David Hayes 
> Sent: Thursday, April 21, 2022 2:47 AM
> To: Fujinaka, Todd 
> Cc: e1000-de...@lists.sf.net
> Subject: Re: [E1000-devel] tc changing mqprio parameters X710-T4L
>
> Hi Todd,
>
> Thank you for getting back to me. It is probably easier if you file 
> the bug.
>
> A little more information in case it is useful:
>
> We have also tried this running the 5.17.1 kernel with the same 
> result.
>
> When the OS starts, the interfaces are initially given default 
> fq_codel qdiscs. We are able to replace these with the mqprio qdisc, 
> but after doing that we can make no further changes.
>
> The cards have the latest (8.60 version) firmware installed.
>
> Thanks and regards,
>
> David
>
>
> On Wed, Apr 20 2022 at 19:01, "Fujinaka, Todd" 
>  wrote:
>
>> Do you have some way to file a bug with us through your factory 
>> contact? Otherwise I will file a bug and then relay the info via 
>> email.
>>
>> Todd Fujinaka
>> Software Application Engineer
>> Ethernet Products Group
>> Intel Corporation
>> todd.fujin...@intel.com
>>
>> -Original Message-
>> From: David Hayes 
>> Sent: Wednesday, April 13, 2022 5:27 AM
>> To: e1000-de...@lists.sf.net
>> Subject: [E1000-devel] tc changing mqprio parameters X710-T4L
>>
>>
>> Hi list,
>>
>> We are using a couple of X710-T4L cards in an experimental testbed.
>> The computer with the cards is currently manjaro linux
>> 5.17rc7 kernel, and cards have been updated with the latest nvm 8.60.
>> As part of the work we wish to periodically change the shapers' 
>> max_rate parameter.
>>
>> We set up the qdisc as follows:
>>
>> # tc qdisc replace dev  root mqprio num_tc 1 hw 1 mode
>>   channel shaper bw_rlimit min_rate 0Mbit max_rate 500Mbit map 
>>   0 
>>   0
>>   0 0 0 0 0 0 queues 1@0
>>
>> This works well and we are able to confirm the 500Mbit limit 
>> experimentally.
>>
>> However, when we try to change the speed:
>>
>> # tc qdisc change dev  root mqprio num_tc 1 hw 1 mode
>>   channel shaper bw_rlimit min_rate 0Mbit max_rate 200Mbit map 
>>   0 
>>   0
>>   0 0 0 0 0 0 queues 1@0
>>
>> we get the following error message:
>>
>> Change operation is not supported by specified qdisc
>>
>> We are also unable use "replace" a second time.
>>
>> I know our use case is a little unusual, but it is simple. Does 
>> anyone have any ideas what the problem could be and how we can fix it 
>> or work around it?
>>
>> Many thanks,
>>
>> David
>>
>>
>>
>> ___
>> E1000-devel mailing list
>> E1000-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/e1000-devel
>> To learn more about Intel Ethernet, visit 
>> https://forums.intel.com/s/topic/0TO0P0018NbWAI/intel-ethernet




___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
https://forums.intel.com/s/topic/0TO0P0018NbWAI/intel-ethernet

Re: [E1000-devel] tc changing mqprio parameters X710-T4L

[Fujinaka, Todd]

I got a reply from the engineering team:

A workaround is to reinitialize everything. Instead of:

tc qdisc replace dev enp130s0f0 root mqprio num_tc 1 hw 1 mode channel shaper 
bw_rlimit min_rate 0Mbit max_rate 500Mbit map 0 0 0 0 0 0 0 0 queues 1@0
tc qdisc change dev enp130s0f0 root mqprio num_tc 1 hw 1 mode channel shaper 
bw_rlimit min_rate 0Mbit max_rate 200Mbit map 0 0 0 0 0 0 0 0 queues 1@0

Can you do this:
tc qdisc replace dev enp130s0f0 root mqprio num_tc 1 hw 1 mode channel shaper 
bw_rlimit min_rate 0Mbit max_rate 500Mbit map 0 0 0 0 0 0 0 0 queues 1@0
tc qdisc del dev enp130s0f0 root
tc qdisc replace dev enp130s0f0 root mqprio num_tc 1 hw 1 mode channel shaper 
bw_rlimit min_rate 0Mbit max_rate 200Mbit map 0 0 0 0 0 0 0 0 queues 1@0

They did mention this would inactivate the filters, so if you need leave them 
on we'll need to do some more work on our end.

Todd Fujinaka
Software Application Engineer
Ethernet Products Group
Intel Corporation
todd.fujin...@intel.com

-Original Message-
From: David Hayes  
Sent: Thursday, April 21, 2022 2:47 AM
To: Fujinaka, Todd 
Cc: e1000-de...@lists.sf.net
Subject: Re: [E1000-devel] tc changing mqprio parameters X710-T4L

Hi Todd,

Thank you for getting back to me. It is probably easier if you file the bug.

A little more information in case it is useful:

We have also tried this running the 5.17.1 kernel with the same result.

When the OS starts, the interfaces are initially given default fq_codel qdiscs. 
We are able to replace these with the mqprio qdisc, but after doing that we can 
make no further changes.

The cards have the latest (8.60 version) firmware installed.

Thanks and regards,

David


On Wed, Apr 20 2022 at 19:01, "Fujinaka, Todd" 
 wrote:

> Do you have some way to file a bug with us through your factory 
> contact? Otherwise I will file a bug and then relay the info via 
> email.
>
> Todd Fujinaka
> Software Application Engineer
> Ethernet Products Group
> Intel Corporation
> todd.fujin...@intel.com
>
> -Original Message-
> From: David Hayes 
> Sent: Wednesday, April 13, 2022 5:27 AM
> To: e1000-de...@lists.sf.net
> Subject: [E1000-devel] tc changing mqprio parameters X710-T4L
>
>
> Hi list,
>
> We are using a couple of X710-T4L cards in an experimental testbed. 
> The computer with the cards is currently manjaro linux
> 5.17rc7 kernel, and cards have been updated with the latest nvm 8.60. 
> As part of the work we wish to periodically change the shapers' 
> max_rate parameter.
>
> We set up the qdisc as follows:
>
> # tc qdisc replace dev  root mqprio num_tc 1 hw 1 mode
>   channel shaper bw_rlimit min_rate 0Mbit max_rate 500Mbit map 0 
>   0
>   0 0 0 0 0 0 queues 1@0
>
> This works well and we are able to confirm the 500Mbit limit 
> experimentally.
>
> However, when we try to change the speed:
>
> # tc qdisc change dev  root mqprio num_tc 1 hw 1 mode
>   channel shaper bw_rlimit min_rate 0Mbit max_rate 200Mbit map 0 
>   0
>   0 0 0 0 0 0 queues 1@0
>
> we get the following error message:
>
> Change operation is not supported by specified qdisc
>
> We are also unable use "replace" a second time.
>
> I know our use case is a little unusual, but it is simple. Does anyone 
> have any ideas what the problem could be and how we can fix it or work 
> around it?
>
> Many thanks,
>
> David
>
>
>
> ___
> E1000-devel mailing list
> E1000-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/e1000-devel
> To learn more about Intel Ethernet, visit 
> https://forums.intel.com/s/topic/0TO0P0018NbWAI/intel-ethernet


--
David Hayes
SimulaMet
https://www.simula.no/people/davidh


___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
https://forums.intel.com/s/topic/0TO0P0018NbWAI/intel-ethernet

Re: [E1000-devel] tc changing mqprio parameters X710-T4L

[Fujinaka, Todd]

Do you have some way to file a bug with us through your factory contact? 
Otherwise I will file a bug and then relay the info via email.

Todd Fujinaka
Software Application Engineer
Ethernet Products Group
Intel Corporation
todd.fujin...@intel.com

-Original Message-
From: David Hayes  
Sent: Wednesday, April 13, 2022 5:27 AM
To: e1000-de...@lists.sf.net
Subject: [E1000-devel] tc changing mqprio parameters X710-T4L


Hi list,

We are using a couple of X710-T4L cards in an experimental testbed. The 
computer with the cards is currently manjaro linux
5.17rc7 kernel, and cards have been updated with the latest nvm 8.60. As part 
of the work we wish to periodically change the shapers' max_rate parameter.

We set up the qdisc as follows:

# tc qdisc replace dev  root mqprio num_tc 1 hw 1 mode
  channel shaper bw_rlimit min_rate 0Mbit max_rate 500Mbit map 0 0
  0 0 0 0 0 0 queues 1@0

This works well and we are able to confirm the 500Mbit limit experimentally.

However, when we try to change the speed:

# tc qdisc change dev  root mqprio num_tc 1 hw 1 mode
  channel shaper bw_rlimit min_rate 0Mbit max_rate 200Mbit map 0 0
  0 0 0 0 0 0 queues 1@0

we get the following error message:

Change operation is not supported by specified qdisc

We are also unable use "replace" a second time.

I know our use case is a little unusual, but it is simple. Does anyone have any 
ideas what the problem could be and how we can fix it or work around it?

Many thanks,

David



___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
https://forums.intel.com/s/topic/0TO0P0018NbWAI/intel-ethernet


___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
https://forums.intel.com/s/topic/0TO0P0018NbWAI/intel-ethernet

Re: [E1000-devel] Issue With IXGBE

[Fujinaka, Todd]

I had to ask for help on this as I don't keep up with SoC parts, but the 
problem appears that we don't support the copper module. Until you reboot, the 
part could be confused if you plug it in.

This should all be in the readme:

Devices based on the Intel(R) Ethernet Connection X552 and Intel(R) Ethernet 
Connection X553 do not support the following features:
* Energy Efficient Ethernet (EEE)
* Intel PROSet for Windows Device Manager
* Intel ANS teams or VLANs (LBFO is supported)
* Data Center Bridging (DCB)
* IPSec Offloading
* MACSec Offloading
In addition, SFP+ devices based on the Intel(R) Ethernet Connection X552 and
Intel(R) Ethernet Connection X553 do not support the following features:
* Speed and duplex auto-negotiation.
* Wake on LAN
* 1000BASE-T SFP Modules


Todd Fujinaka
Software Application Engineer
Ethernet Products Group
Intel Corporation
todd.fujin...@intel.com

-Original Message-
From: SPRTN  
Sent: Friday, December 31, 2021 12:51 AM
To: e1000-de...@lists.sf.net
Subject: [E1000-devel] Issue With IXGBE

Support Team,

I noticed a potential issue with the IXGBE 5.13.4.

My hardware is a Supermicro A2SDI-TP8F, using it's two SFP+ ports that are 
using Intel X553 drivers. I am using the Untangle OS 16.4.1, which is based off 
of Ubuntu.

When a Copper module is plugged into the SFP+ port the ethtool command shows, 
FIBRE, however, when a Fiber/Optical Direct Attach Cable is used the ethtool 
command shows Copper Direct Attach, and no connection is ever established. Is 
it possible that there is an issue in the *.ko file?

Appreciate your time and help. If there is any more information you need me to 
send over, please let me know.

Very Respectfully,
Kostas Diotis
___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
https://forums.intel.com/s/topic/0TO0P0018NbWAI/intel-ethernet


___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
https://forums.intel.com/s/topic/0TO0P0018NbWAI/intel-ethernet

Re: [E1000-devel] i225 / igc out of tree driver

[Fujinaka, Todd]

There is only the in-kernel driver for igc and the i225.

Todd Fujinaka
Software Application Engineer
Ethernet Products Group
Intel Corporation
todd.fujin...@intel.com

-Original Message-
From: Iain Barker via E1000-devel  
Sent: Wednesday, November 24, 2021 9:40 AM
To: e1000-devel@lists.sourceforge.net
Subject: [E1000-devel] i225 / igc out of tree driver

Hi all,

We've been reliably developing products using this project's  i40e, ixgbe, igb 
etc. out-of-tree drivers.

But the igc driver used for i225 family is not present.

Does anyone know whether open source igc development is tracked someplace else ?

thanks.
Iain



Juniper Business Use Only

___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
https://forums.intel.com/s/topic/0TO0P0018NbWAI/intel-ethernet


___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
https://forums.intel.com/s/topic/0TO0P0018NbWAI/intel-ethernet

Re: [E1000-devel] igb driver hangs on Linux 5.15.4 but is fine in stock Debian 5.10.0-9-amd64 kernel

[Fujinaka, Todd]

I think dmesg (the whole thing) would be more informative. You may need to post 
those as a bug on e1000.sourceforge.net.

Are you able to bisect the kernel?

Todd Fujinaka
Software Application Engineer
Ethernet Products Group
Intel Corporation
todd.fujin...@intel.com

-Original Message-
From: Dianne Skoll via E1000-devel  
Sent: Tuesday, November 23, 2021 5:54 AM
To: e1000-devel@lists.sourceforge.net
Subject: [E1000-devel] igb driver hangs on Linux 5.15.4 but is fine in stock 
Debian 5.10.0-9-amd64 kernel

Hi,

I recently purchased a machine that has an Intel I211 Gigabit Network 
controller.  The system works fine with stock Debian 11's kernel, but when I 
upgrade to upstream Linux 5.14.4, the Ethernet hangs every few minutes.
If I bring networking down and back up again, it resumes working, but keeps 
hanging randomly.  I'm sorry I don't have much else to add to this as I'm not a 
kernel developer.

Here's the relevant excerpt from lspci:

==
43:00.0 Ethernet controller: Intel Corporation I211 Gigabit Network Connection 
(rev 03)
Subsystem: ASUSTeK Computer Inc. I211 Gigabit Network Connection
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
https://forums.intel.com/s/topic/0TO0P0018NbWAI/intel-ethernet


___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
https://forums.intel.com/s/topic/0TO0P0018NbWAI/intel-ethernet

Re: [E1000-devel] errors on link xl 710

[Fujinaka, Todd]

I don't think I'm clicking on that link. Can you summarize the issue? If you 
need to post logs, you can also go to e1000.sourceforge.net and file a bug.

Todd Fujinaka
Software Application Engineer
Ethernet Products Group
Intel Corporation
todd.fujin...@intel.com

-Original Message-
From: Jakub Osuch  
Sent: Monday, November 22, 2021 9:43 PM
To: e1000-devel@lists.sourceforge.net
Subject: [E1000-devel] errors on link xl 710

I have errors on link between nexus N3K-C3064PQ-10GX and LREC9902BF-2QSFP+.
driver: i40e
version: 2.17.4

Take a look:
shorturl.at/crCNQ

-- 
Jakub Osuch
mobile +48501203739
www.techgroup.pl
www.decotime.org
www.techdiveshop.net

___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
https://forums.intel.com/s/topic/0TO0P0018NbWAI/intel-ethernet


___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
https://forums.intel.com/s/topic/0TO0P0018NbWAI/intel-ethernet

Re: [E1000-devel] a question about rx_packets and rx_dropped

[Fujinaka, Todd]

Which part and driver (including version)?

Todd Fujinaka
Software Application Engineer
Data Center Group
Intel Corporation
todd.fujin...@intel.com

-Original Message-
From: R. Engür Pişirici via E1000-devel  
Sent: Thursday, August 19, 2021 7:18 AM
To: e1000-devel@lists.sourceforge.net
Subject: [E1000-devel] a question about rx_packets and rx_dropped


Hi,

I wonder that, if /sys/class/net/NICINTERFACE/statistics/rx_packets
includes/counts /sys/class/net/NICINTERFACE/statistics/rx_dropped ?

e.g.
Let /sys/class/net/NICINTERFACE/statistics/rx_packets is 100 and 
/sys/class/net/NICINTERFACE/statistics/rx_dropped is 10.

Which one is correct?
Total count of received packets is 110.
or
Total count of received packets is 100.

Best Regards,


___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
https://forums.intel.com/s/topic/0TO0P0018NbWAI/intel-ethernet


___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
https://forums.intel.com/s/topic/0TO0P0018NbWAI/intel-ethernet

Re: [E1000-devel] Nics goes down when OOM

[Fujinaka, Todd]

You may want to post this on intel-wired-...@osuosl.org, but I think if you 
have a Bugzilla open we should be aware of this already.

Todd Fujinaka
Software Application Engineer
Data Center Group
Intel Corporation
todd.fujin...@intel.com

-Original Message-
From: Ivan Pazos Atanes  
Sent: Tuesday, July 27, 2021 3:52 AM
To: e1000-devel@lists.sourceforge.net
Subject: [E1000-devel] Nics goes down when OOM

Hi all,

My name is Iván, I am an Openshift consultant working with a customer that is 
facing the following issue. When a pod starts to OOM network interfaces start 
to go down until the node becomes to 'Not Ready' State

This is dmesg  message:

sh-4.4# modinfo i40e
filename:
/lib/modules/4.18.0-193.51.1.el8_2.x86_64/kernel/drivers/net/ethernet/intel/i40e/i40e.ko.xz
version:2.8.20-k
license:GPL v2
description:Intel(R) Ethernet Connection XL710 Network Driver
author: Intel Corporation, 
rhelversion:8.2

[Tue Jul 27 09:36:43 2021] Memory cgroup stats for
/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-podd28f9b32_f407_44bd_a64d_cf05a10f2a5f.slice/crio-6ffbabbb06eb557c53304b0b253122a82ac4ea5d31535503f812a97dff9ac4c.scope:
cache:0KB rss:132KB rss_huge:0KB shmem:0KB mapped_file:0KB dirty:0KB 
writeback:0KB swap:0KB inactive_anon:0KB active_anon:904KB inactive_file:0KB 
ative_file:0KB unevictable:0KB
[Tue Jul 27 09:36:43 2021] [ pid ]   uid  tgid total_vm  rss
pgtables_bytes swapents oom_score_adj name
[Tue Jul 27 09:36:43 2021] [21805] 0 2180535869  651   176128
 0 -1000 conmon
[Tue Jul 27 09:36:43 2021] [21806] 0 21806   383963 5780   249856
 0 -1000 runc
[Tue Jul 27 09:36:43 2021] [21835] 0 21835 5029  85565536
 0 -1000 exe


*[Tue Jul 27 09:36:43 2021] Out of memory and no killable processes...[Tue Jul 
27 09:36:43 2021] i40e :14:00.1: Query for DCB configuration failed, err 
I40E_ERR_NOT_READY aq_err OK[Tue Jul 27 09:36:44 2021] i40e
:14:00.1: DCB init failed -63, disabled* [Tue Jul 27 09:36:44 2021] bond0: 
(slave eno2): link status definitely down, disabling slave *[Tue Jul 27 
09:36:45 2021] i40e :14:00.0: Query for DCB configuration failed, err 
I40E_ERR_NOT_READY aq_err OK* [Tue Jul 27 09:36:45 2021] i40e :14:00.0: DCB 
init failed -63, disabled [Tue Jul 27 09:36:45 2021] i40e :14:00.1 eno2: 
port 4789 already offloaded [Tue Jul 27 09:36:45 2021] i40e :14:00.1 eno2: 
port 4789 already offloaded [Tue Jul 27 09:36:45 2021] i40e :14:00.1: FW 
LLDP is enabled

*[Tue Jul 27 09:36:45 2021] bond0: (slave eno1): link status definitely down, 
disabling slave*[Tue Jul 27 09:36:45 2021] i40iw_deinit_device: state = 11 [Tue 
Jul 27 09:36:45 2021] bond0: (slave eno2): link status definitely up,
1 Mbps full duplex
[Tue Jul 27 09:36:45 2021] ib_srpt srpt_remove_one(i40iw1): nothing to do.
[Tue Jul 27 09:36:45 2021] device vethda19890a entered promiscuous mode [Tue 
Jul 27 09:36:45 2021] i40e :14:00.0 eno1: port 4789 already offloaded [Tue 
Jul 27 09:36:45 2021] i40e :14:00.0 eno1: port 4789 already offloaded [Tue 
Jul 27 09:36:45 2021] i40e :14:00.0: FW LLDP is enabled [Tue Jul 27 
09:36:45 2021] i40iw_deinit_device: state = 11 [Tue Jul 27 09:36:45 2021] 
ib_srpt srpt_remove_one(i40iw0): nothing to do.
[Tue Jul 27 09:36:45 2021] i40iw_initialize_dev: DCB is set/clear = 0 [Tue Jul 
27 09:36:45 2021] i40iw_wait_pe_ready: [1283] fm load status[x0703] [Tue Jul 27 
09:36:45 2021] i40iw_wait_pe_ready: [1288] I40E_GLPE_CPUSTATUS1 status[x0080] 
[Tue Jul 27 09:36:45 2021] i40iw_wait_pe_ready: [1291] I40E_GLPE_CPUSTATUS2 
status[x0080] [Tue Jul 27 09:36:45 2021] bond0: (slave eno1): link status 
definitely up,
1 Mbps full duplex
[Tue Jul 27 09:36:45 2021] i40iw_wait_pe_ready: [1283] fm load status[x0703] 
[Tue Jul 27 09:36:45 2021] i40iw_wait_pe_ready: [1288] I40E_GLPE_CPUSTATUS1 
status[x0080] [Tue Jul 27 09:36:45 2021] i40iw_wait_pe_ready: [1291] 
I40E_GLPE_CPUSTATUS2 status[x0080] [Tue Jul 27 09:36:45 2021] ib_srpt MAD 
registration failed for i40iw0-1.
[Tue Jul 27 09:36:45 2021] ib_srpt srpt_add_one(i40iw0) failed.
[Tue Jul 27 09:36:45 2021] i40iw_open: i40iw_open completed [Tue Jul 27 
09:36:45 2021] ib_srpt MAD registration failed for i40iw1-1.
[Tue Jul 27 09:36:45 2021] ib_srpt srpt_add_one(i40iw1) failed.
[Tue Jul 27 09:36:45 2021] i40iw_open: i40iw_open completed [Tue Jul 27 
09:36:49 2021] exe invoked oom-killer:
gfp_mask=0x6000c0(GFP_KERNEL), nodemask=(null), order=0, oom_score_adj=-1000 
[Tue Jul 27 09:36:50 2021] exe cpuset=/ mems_allowed=0-3
[Tue Jul 27 09:36:50 2021] CPU: 53 PID: 21835 Comm: exe Tainted: GW
   L   - -  - 4.18.0-193.51.1.el8_2.x86_64 #1
[Tue Jul 27 09:36:50 2021] Hardware name: HPE ProLiant XL170r Gen10/ProLiant 
XL170r Gen10, BIOS U38 10/26/2020 [Tue Jul 27 09:36:50 2021] Call Trace:

I was looking for information about the error codes and there is very little 
information on the Internet.

Maybe you 

Re: [E1000-devel] timestamp timeout with E810

[Fujinaka, Todd]

Sorry I haven't answered this more quickly. It's generated some internal 
discussion that is still ongoing. I think there is a doc somewhere that says 
you may have to increase the timeout, but that's also under discussion.

Todd Fujinaka
Software Application Engineer
Data Center Group
Intel Corporation
todd.fujin...@intel.com

-Original Message-
From: Harte, Sean  
Sent: Wednesday, July 7, 2021 4:27 AM
To: e1000-devel@lists.sourceforge.net
Subject: [E1000-devel] timestamp timeout with E810

Hi,

I am using linuxptp with an Intel E810-XXV Ethernet controller with ice driver 
version 1.5.8. Regular timeouts are occurring when retrieving the TX timestamp:

ptp4l[4756.840]: timed out while polling for tx timestamp
ptp4l[4756.840]: increasing tx_timestamp_timeout may correct this issue, but it 
is likely caused by a driver bug
ptp4l[4756.840]: port 1 (p2p1): send sync failed
ptp4l[4756.840]: port 1 (p2p1): MASTER to FAULTY on FAULT_DETECTED 
(FT_UNSPECIFIED)

Increasing the linuxptp tx_timestamp_timeout setting to 50ms (from a default of 
1ms) stops the timeouts. Is such a large delay expected with the E810/ice 
driver? I have previously being using an Intel XXV710 with i40e driver and 
never saw this error using the default timeout value of 1ms.

Regards,
Sean


___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
https://forums.intel.com/s/topic/0TO0P0018NbWAI/intel-ethernet


___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
https://forums.intel.com/s/topic/0TO0P0018NbWAI/intel-ethernet

Re: [E1000-devel] failed to read reg 0xc030

[Fujinaka, Todd]

"PCIe link lost" is catastrophic and I would suggest you talk to the hardware 
manufacturer first.

You could also go through the git log to see if there were any updates to the 
PCIE subsystem, but if we can't talk to the part there's not much we can do 
from the network driver.

Todd Fujinaka
Software Application Engineer
Data Center Group
Intel Corporation
todd.fujin...@intel.com

-Original Message-
From: Bret Towe  
Sent: Friday, July 2, 2021 6:34 AM
To: e1000-de...@lists.sf.net
Subject: [E1000-devel] failed to read reg 0xc030

Hello,
I've been seeing an issue for while, looking back at logs it started on June 1 
on kernel 5.12.8 the visible effect is the server in question every couple of 
days it will lose network connectivity typically all 4 ports stop 
communicating, this last time however it only dropped 1 the trace below if from 
that event.
this last crash was from 5.12.13
let me know what all you need to narrow down the problem

[140519.425033] igb :01:00.0 lan1: PCIe link lost [140519.425055] 
[ cut here ] [140519.425058] igb: Failed to read reg 
0xc030!
[140519.425151] WARNING: CPU: 3 PID: 802 at
drivers/net/ethernet/intel/igb/igb_main.c:747 igb_rd32.cold+0x39/0x45 [igb] 
[140519.425201] Modules linked in: rpcsec_gss_krb5 rpcrdma rdma_cm iw_cm ib_cm 
ib_core wireguard curve25519_x86_64 libchacha20poly1305
chacha_x86_64 poly1305_x86_64 libblake2s blake2s_x86_64 libcurve25519_generic 
libchacha libblake2s_generic ip6_udp_tunnel udp_tunnel amdgpu sch_cake 
gpu_sched act_mirred cls_u32 sch_ingress ifb sch_fq bridge ip6table_filter 
ip6_tables xt_nat xt_MASQUERADE iptable_nat nf_nat xt_state xt_conntrack 
nf_conntrack cfg80211
nf_defrag_ipv6 nf_defrag_ipv4 radeon libcrc32c xt_tcpudp iptable_filter rfkill 
8021q garp mrp stp llc edac_mce_amd kvm_amd snd_hda_codec_realtek 
snd_hda_codec_generic snd_hda_codec_hdmi ledtrig_audio kvm snd_hda_intel 
snd_intel_dspcfg snd_intel_sdw_acpi drm_ttm_helper snd_hda_codec ttm irqbypass 
crct10dif_pclmul drm_kms_helper snd_hda_core ghash_clmulni_intel snd_hwdep 
pcspkr k10temp fam15h_power snd_pcm cec snd_timer igb sp5100_tco ccp snd 
syscopyarea rng_core sysfillrect i2c_algo_bit sysimgblt i2c_piix4 dca 
fb_sys_fops soundcore mac_hid [140519.425405]  acpi_cpufreq nfsd auth_rpcgss 
nfs_acl lockd grace drm sunrpc fuse agpgart nfs_ssc bpf_preload ip_tables 
x_tables ext4 crc32c_generic crc16 mbcache jbd2 dm_mod crc32_pclmul 
crc32c_intel usbhid sdhci_pci aesni_intel cqhci sdhci xhci_pci crypto_simd 
mmc_core cryptd xhci_pci_renesas video [140519.425490] CPU: 3 PID: 802 Comm: 
snmpd Not tainted 5.12.13-arch1-2 #1 [140519.425499] Hardware name: CompuLab 
fitlet/fitlet, BIOS
SBCFLTR_0.08.01 06/23/2016
[140519.425504] RIP: 0010:igb_rd32.cold+0x39/0x45 [igb] [140519.425544] Code: 
48 c7 c6 8c 11 87 c0 e8 48 00 a2 ea 48 8b bb 30 ff ff ff e8 15 84 4f ea 84 c0 
74 15 89 ee 48 c7 c7 68 1e 87 c0 e8 13 7e 9d ea <0f> 0b e9 5e 33 fe ff e9 73 33 
fe ff 48 63 c6 89 f2 48 c7 c6
00 1f
[140519.425551] RSP: 0018:b519c0f57c68 EFLAGS: 00010286 [140519.425560] 
RAX:  RBX: 8f574e90 RCX:
0027
[140519.425565] RDX: 8f5996d986e8 RSI: 0001 RDI:
8f5996d986e0
[140519.425571] RBP: c030 R08:  R09:
b519c0f57a98
[140519.425576] R10: b519c0f57a90 R11: ac2cc4a8 R12:

[140519.425581] R13:  R14: 8f588b03a240 R15:
c030
[140519.425587] FS:  7f9fff6f5740() GS:8f5996d8()
knlGS:
[140519.425594] CS:  0010 DS:  ES:  CR0: 80050033 
[140519.425600] CR2: 7f979d179f10 CR3: 000108bf CR4:
000406e0
[140519.425607] Call Trace:
[140519.425624]  igb_update_stats+0x71/0x810 [igb] [140519.425662]  
igb_get_stats64+0x2a/0x80 [igb] [140519.425697]  dev_get_stats+0x5c/0xc0 
[140519.425714]  dev_seq_printf_stats+0x3e/0xe0 [140519.425731]  
dev_seq_show+0x10/0x30 [140519.425741]  seq_read_iter+0x2d5/0x4c0 
[140519.425756]  seq_read+0x127/0x170 [140519.425770]  proc_reg_read+0x55/0xa0 
[140519.425781]  vfs_read+0xa7/0x1a0 [140519.425794]  ksys_read+0x67/0xe0 
[140519.425806]  do_syscall_64+0x33/0x40 [140519.425820]  
entry_SYSCALL_64_after_hwframe+0x44/0xae
[140519.425832] RIP: 0033:0x7fab2862 [140519.425841] Code: c0 e9 b2 fe ff 
ff 50 48 8d 3d 5a 29 0a 00 e8 55
e4 01 00 0f 1f 44 00 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75
10 0f 05 <48> 3d 00 f0 ff ff 77 56 c3 0f 1f 44 00 00 48 83 ec 28 48 89
54 24
[140519.425847] RSP: 002b:7fffd36627f8 EFLAGS: 0246 ORIG_RAX:

[140519.425856] RAX: ffda RBX: 55a2aea72b30 RCX:
7fab2862
[140519.425861] RDX: 0400 RSI: 55a2aeaa3720 RDI:
0008
[140519.425866] RBP: 7fa000185300 R08: 0008 R09:

[140519.425871] R10: 1000 R11: 0246 R12:
55a2aea72b30
[140519.425876] R13: 0d68 R14: 

Re: [E1000-devel] ixgbe NULL pointer dereference on ubuntu-5.8.0-25-generic

[Fujinaka, Todd]

We are unable to reproduce. I think Ubuntu might be moving kernels around on us 
because 'apt install linux-generic-hwe-20.04-edge' gave us 5.8.0-53-generic.

I'm going to call this closed unless you're still seeing this with the latest 
kernels.

Todd Fujinaka
Software Application Engineer
Data Center Group
Intel Corporation
todd.fujin...@intel.com

-Original Message-
From: Fujinaka, Todd  
Sent: Monday, March 1, 2021 10:24 AM
To: Dmitry Kravkov 
Cc: e1000-de...@lists.sf.net
Subject: Re: [E1000-devel] ixgbe NULL pointer dereference on 
ubuntu-5.8.0-25-generic

OK, I’ll file an internal ticket.

Todd Fujinaka
Software Application Engineer
Data Center Group
Intel Corporation
todd.fujin...@intel.com

From: Dmitry Kravkov 
Sent: Monday, March 1, 2021 9:04 AM
To: Fujinaka, Todd 
Cc: e1000-de...@lists.sf.net
Subject: Re: [E1000-devel] ixgbe NULL pointer dereference on 
ubuntu-5.8.0-25-generic

Also happens in 20.04 TLS hwe-5.8.0-44-generic kernel kernel installed using 
'apt install linux-generic-hwe-20.04-edge'


On Thu, Feb 25, 2021 at 11:41 AM Dmitry Kravkov 
mailto:dmit...@qwilt.com>> wrote:
Will do so

On Wed, Feb 24, 2021 at 5:00 PM Fujinaka, Todd 
mailto:todd.fujin...@intel.com>> wrote:
We only support the LTS variants. Can you try one of those?

Todd Fujinaka
Software Application Engineer
Data Center Group
Intel Corporation
todd.fujin...@intel.com<mailto:todd.fujin...@intel.com>

From: Dmitry Kravkov mailto:dmit...@qwilt.com>>
Sent: Tuesday, February 23, 2021 11:24 PM
To: Fujinaka, Todd mailto:todd.fujin...@intel.com>>
Cc: e1000-de...@lists.sf.net<mailto:e1000-de...@lists.sf.net>
Subject: Re: [E1000-devel] ixgbe NULL pointer dereference on 
ubuntu-5.8.0-25-generic


On Wed, Feb 24, 2021 at 2:28 AM Fujinaka, Todd 
mailto:todd.fujin...@intel.com>> wrote:
What version of Ubuntu is this? It's going to take me a bit to try to find the 
kernel from the release.
Ubuntu 20.10

Todd Fujinaka
Software Application Engineer
Data Center Group
Intel Corporation
todd.fujin...@intel.com<mailto:todd.fujin...@intel.com>

-Original Message-
From: Dmitry Kravkov mailto:dmit...@qwilt.com>>
Sent: Sunday, February 21, 2021 11:43 PM
To: e1000-de...@lists.sf.net<mailto:e1000-de...@lists.sf.net>
Subject: [E1000-devel] ixgbe NULL pointer dereference on ubuntu-5.8.0-25-generic

Hi All

I'm hitting the following bug during unload inbox driver and insmod'ing 5.9.4 
(also happens with 5.10.2):

[ 1739.889642] BUG: kernel NULL pointer dereference, address:
04f0
[ 1739.897969] #PF: supervisor read access in kernel mode [ 1739.904155] #PF: 
error_code(0x) - not-present page [ 1739.910327] PGD 0 P4D 0 [ 1739.913648] 
Oops:  [#1] SMP PTI [ 1739.917985] CPU: 16 PID: 0 Comm: swapper/16 Kdump: 
loaded Tainted: G
  OE 5.8.0-25-generic #26-Ubuntu
[ 1739.929943] Hardware name:  /, BIOS 2.2.2 01/16/2014 [ 1739.936043] RIP: 
0010:eth_get_headlen+0x26/0xb0 [ 1739.941625] Code: 00 00 00 00 66 66 66 66 90 
55 48 89 e5 41 54 53 89 d3
48 83 ec 18 65 48 8b 04 25 28 00 00 00 48 89 45 e8 31 c0 83 fa 0d 76 7e <48> 8b 
bf f0 04 00 00 6a 01 49 89 f0 49 89 f4 52 48 8d 4d dc 48 c7 [ 1739.963567] RSP: 
0018:be2506798db8 EFLAGS: 00010216 [ 1739.969961] RAX:  
RBX: 05ea RCX:
0002
[ 1739.978453] RDX: 05ea RSI: 9f6fb733c0c0 RDI:

[ 1739.986957] RBP: be2506798de0 R08:  R09:
9f733306ff00
[ 1739.995423] R10: 05ea R11: 0100 R12:
9f727b2c0740
[ 1740.003871] R13: 9f724b0e6010 R14: 400a838d R15:

[ 1740.012330] FS:  () GS:9f733fa0()
knlGS:
[ 1740.021848] CS:  0010 DS:  ES:  CR0: 80050033 [ 1740.028757] 
CR2: 04f0 CR3: 0002c740a001 CR4:
000606e0
[ 1740.037209] Call Trace:
[ 1740.040425]  
[ 1740.043154]  ixgbe_process_skb_fields+0x55/0x260 [ixgbe] [ 1740.049577]  
ixgbe_poll+0x52b/0x12c0 [ixgbe] [ 1740.054809]  napi_poll+0x96/0x1b0 [ 
1740.058985]  net_rx_action+0xb8/0x1c0 [ 1740.063575]  __do_softirq+0xd0/0x2a1 
[ 1740.068055]  asm_call_irq_on_stack+0x12/0x20 [ 1740.073345]   [ 
1740.076223]  do_softirq_own_stack+0x3d/0x50 [ 1740.081402]  
irq_exit_rcu+0x95/0xd0 [ 1740.085829]  common_interrupt+0x7c/0x150 [ 
1740.090730]  asm_common_interrupt+0x1e/0x40 [ 1740.095941] RIP: 
0010:cpuidle_enter_state+0xb4/0x3f0
[ 1740.102049] Code: 65 8b 3d 3f fb c6 58 e8 4a 5d 74 ff 48 89 45 d0 66 66
66 66 90 31 ff e8 fa 68 74 ff 80 7d c7 00 0f 85 d3 01 00 00 fb 66 66 90 <66> 66 
90 45 85 e4 0f 88 df 01 00 00 49 63 d4 48 8d 04 52 48 8d 0c [ 1740.124194] RSP: 
0018:be250634fe48 EFLAGS: 0246 [ 1740.130699] RAX: 9f733fa2c6c0 
RBX: de14bfa00f00 RCX:
001f
[ 1740.139315] RDX:  RSI: 373a RDI:

[ 1740.147943] RBP: be250634fe88 R08: 01951980e894 R09:
000

Re: [E1000-devel] Request for Intel® Ethernet-Controller X550-AT ixgbe driver source code for Windows 10

[Fujinaka, Todd]

We don't release the Windows source code for our drivers. Also, this isn't the 
correct forum for this, so if you do wish to continue, please submit this 
request through your factory support team or whoever you purchased the intel 
controllers from.

Todd Fujinaka
Software Application Engineer
Data Center Group
Intel Corporation
todd.fujin...@intel.com

-Original Message-
From: Dominik Müller  
Sent: Tuesday, March 16, 2021 2:22 AM
To: e1000-de...@lists.sf.net
Subject: [E1000-devel] Request for Intel® Ethernet-Controller X550-AT ixgbe 
driver source code for Windows 10


Dear Sir or Madam,
i am looking for the source code of the Intel® Ethernet-Controller X550-AT 
ixgbe driver for the Windows10 OS.
I have got your address from @CarlosAM_INTEL see:
https://community.intel.com/t5/Embedded-Connectivity/Intel-Ethernet-Controller-X550-AT-ixgbe-driver-source-code/m-p/1263023#M24329
Thank you for your help to resolve my request.
If you will need anything from me feel free to ask.
Best regards
Dominik Müller 
Junior Software Developer 



Bitte beachten Sie unsere neuen Telefonnummern!
Please note our new telephone numbers!



Technical Software Engineering Plazotta 
Peter Plazotta 
Hopfenstr. 30 
85283 Wolnzach 
Germany 

Tel.: +49 8442 96240 45 
Fax: +49 8442 96240 99 
dominik.muel...@tsep.com 

Stay informed: 
Web Facebook LinkedIn XING 
___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
https://forums.intel.com/s/topic/0TO0P0018NbWAI/intel-ethernet

___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
https://forums.intel.com/s/topic/0TO0P0018NbWAI/intel-ethernet

Re: [E1000-devel] kcompat landmine - devm_kcalloc

[Fujinaka, Todd]

Thanks Shannon!

Todd Fujinaka
Software Application Engineer
Data Center Group
Intel Corporation
todd.fujin...@intel.com

-Original Message-
From: Shannon Nelson  
Sent: Tuesday, March 9, 2021 3:28 PM
To: e1000-devel@lists.sourceforge.net
Subject: [E1000-devel] kcompat landmine - devm_kcalloc

Hi folks,

I just spent a very long time debugging a random kernel panic that was coming 
from some sort of memory scribbling in our ionic driver, and found the culprit 
in the kcompat.h code that we've borrowed from Intel drivers.  I thought I'd 
let you know before someone else hit this. You'll probably want to check this 
in all your out-of-tree drivers.

Thanks for making this chunk of code available to the world.  Here's the world 
giving back to you.

Cheers,
sln



kcompat: add parens to devm_kcalloc macro

     The macro in kcompat for devm_kcalloc() uses its parameters in
     a multiplication in a call to devm_kzalloc(), but didn't protect
     those parameters with ()'s.  This caused havoc and several days
     debugging a random kernel panic when one parameter was essentially
     a + b: the resulting order of operations didn't allocate the
     expected amount of memory and we ended up scribbling over random
     other objects, causing great pain, chaos, and gnashing of teeth.

     Signed-off-by: Shannon Nelson 

diff --git a/platform/drivers/linux/eth/ionic/kcompat.h
b/platform/drivers/linux/eth/ionic/kcompat.h
index 12c4361d2a..a87428b4e6 100644
--- a/platform/drivers/linux/eth/ionic/kcompat.h
+++ b/platform/drivers/linux/eth/ionic/kcompat.h
@@ -5003,7 +5003,7 @@ static inline struct pci_dev *pci_upstream_bridge(struct 
pci_dev *dev)

  #if ( LINUX_VERSION_CODE > KERNEL_VERSION(2,6,20) )
  #define devm_kcalloc(dev, cnt, size, flags) \
-   devm_kzalloc(dev, cnt * size, flags)
+   devm_kzalloc(dev, (cnt) * (size), flags)
  #endif /* > 2.6.20 */

  #if (!(RHEL_RELEASE_CODE >= RHEL_RELEASE_VERSION(7,2)))



___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
https://forums.intel.com/s/topic/0TO0P0018NbWAI/intel-ethernet

___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
https://forums.intel.com/s/topic/0TO0P0018NbWAI/intel-ethernet

Re: [E1000-devel] I350 and I210 Linux issues not occurring in Windows

[Fujinaka, Todd]

This looks like we’re starting with a hardware issue and you’ll have to submit 
the issue through your factory support (whoever you bought the parts from). I’m 
just saying this if you want us to look at the design files first.

Also, you’re using unsupported distros and you’ll have to contact them for 
help. Even if it was a supported distro, you’d need to submit the issue through 
the distro first as they customize their kernels (including the drivers) and 
are responsible for their implementation.

Hope that helps.

Todd Fujinaka
Software Application Engineer
Data Center Group
Intel Corporation
todd.fujin...@intel.com

From: John Hentges 
Sent: Tuesday, March 9, 2021 2:39 PM
To: Fujinaka, Todd ; e1000-de...@lists.sf.net
Subject: Re: [E1000-devel] I350 and I210 Linux issues not occurring in Windows

Hello, and thank you for the response.

I understand and appreciate the problems with posting a question to more than 
one place.

In this case, however, @CarlosAM_INTEL refered me to this list, and shown in 
the most recent reply in the thread I linked.


Hello, @JohnHentges:

Thanks for your update.

Reviewing the readme file of the cited driver, it is stated that you should 
address your consultations of the cited driver to the email address: 
e1000-de...@lists.sf.net<mailto:e1000-de...@lists.sf.net>. You can find the 
cited document on the following website:

https://downloadmirror.intel.com/15817/eng/readme.txt

Best regards,

@CarlosAM_INTEL.

Were this not the case I would not have cross-posted as I basically have.
John Hentges
ACCES I/O Products, Inc.<http://acces.io/go.cgi?p=/contact/contact.html>  
Director of Software Engineering 
john.hent...@accesio.com<mailto:john.hent...@acces.io>  (858) 467-5582

On 3/9/2021 2:35 PM, Fujinaka, Todd wrote:

The advice is to ask in one place and stick with that. Intel Customer Support 
should be engaged in the communities.



Todd Fujinaka

Software Application Engineer

Data Center Group

Intel Corporation

todd.fujin...@intel.com<mailto:todd.fujin...@intel.com>



-Original Message-

From: John Hentges <mailto:jhent...@accesio.com>

Sent: Tuesday, March 9, 2021 11:30 AM

To: e1000-de...@lists.sf.net<mailto:e1000-de...@lists.sf.net>

Subject: [E1000-devel] I350 and I210 Linux issues not occurring in Windows



https://community.intel.com/t5/Embedded-Connectivity/I350-and-I210-IT-Detected-Tx-Unit-Hang-more-common-as-bandwidth/m-p/1262805/emcs_t



Please advise



--

John Hentges

ACCES I/O Products, Inc.

<http://acces.io/go.cgi?p=/contact/contact.html><http://acces.io/go.cgi?p=/contact/contact.html>
 Director of Software Engineering 
john.hent...@accesio.com<mailto:john.hent...@accesio.com> 
<mailto:john.hent...@acces.io><mailto:john.hent...@acces.io>

(858) 467-5582





___

E1000-devel mailing list

E1000-devel@lists.sourceforge.net<mailto:E1000-devel@lists.sourceforge.net>

https://lists.sourceforge.net/lists/listinfo/e1000-devel

To learn more about Intel Ethernet, visit 
https://forums.intel.com/s/topic/0TO0P0018NbWAI/intel-ethernet


___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
https://forums.intel.com/s/topic/0TO0P0018NbWAI/intel-ethernet

Re: [E1000-devel] ixgbe NULL pointer dereference on ubuntu-5.8.0-25-generic

[Fujinaka, Todd]

OK, I’ll file an internal ticket.

Todd Fujinaka
Software Application Engineer
Data Center Group
Intel Corporation
todd.fujin...@intel.com

From: Dmitry Kravkov 
Sent: Monday, March 1, 2021 9:04 AM
To: Fujinaka, Todd 
Cc: e1000-de...@lists.sf.net
Subject: Re: [E1000-devel] ixgbe NULL pointer dereference on 
ubuntu-5.8.0-25-generic

Also happens in 20.04 TLS hwe-5.8.0-44-generic kernel
kernel installed using 'apt install linux-generic-hwe-20.04-edge'


On Thu, Feb 25, 2021 at 11:41 AM Dmitry Kravkov 
mailto:dmit...@qwilt.com>> wrote:
Will do so

On Wed, Feb 24, 2021 at 5:00 PM Fujinaka, Todd 
mailto:todd.fujin...@intel.com>> wrote:
We only support the LTS variants. Can you try one of those?

Todd Fujinaka
Software Application Engineer
Data Center Group
Intel Corporation
todd.fujin...@intel.com<mailto:todd.fujin...@intel.com>

From: Dmitry Kravkov mailto:dmit...@qwilt.com>>
Sent: Tuesday, February 23, 2021 11:24 PM
To: Fujinaka, Todd mailto:todd.fujin...@intel.com>>
Cc: e1000-de...@lists.sf.net<mailto:e1000-de...@lists.sf.net>
Subject: Re: [E1000-devel] ixgbe NULL pointer dereference on 
ubuntu-5.8.0-25-generic


On Wed, Feb 24, 2021 at 2:28 AM Fujinaka, Todd 
mailto:todd.fujin...@intel.com>> wrote:
What version of Ubuntu is this? It's going to take me a bit to try to find the 
kernel from the release.
Ubuntu 20.10

Todd Fujinaka
Software Application Engineer
Data Center Group
Intel Corporation
todd.fujin...@intel.com<mailto:todd.fujin...@intel.com>

-Original Message-
From: Dmitry Kravkov mailto:dmit...@qwilt.com>>
Sent: Sunday, February 21, 2021 11:43 PM
To: e1000-de...@lists.sf.net<mailto:e1000-de...@lists.sf.net>
Subject: [E1000-devel] ixgbe NULL pointer dereference on ubuntu-5.8.0-25-generic

Hi All

I'm hitting the following bug during unload inbox driver and insmod'ing 5.9.4 
(also happens with 5.10.2):

[ 1739.889642] BUG: kernel NULL pointer dereference, address:
04f0
[ 1739.897969] #PF: supervisor read access in kernel mode [ 1739.904155] #PF: 
error_code(0x) - not-present page [ 1739.910327] PGD 0 P4D 0 [ 1739.913648] 
Oops:  [#1] SMP PTI [ 1739.917985] CPU: 16 PID: 0 Comm: swapper/16 Kdump: 
loaded Tainted: G
  OE 5.8.0-25-generic #26-Ubuntu
[ 1739.929943] Hardware name:  /, BIOS 2.2.2 01/16/2014 [ 1739.936043] RIP: 
0010:eth_get_headlen+0x26/0xb0 [ 1739.941625] Code: 00 00 00 00 66 66 66 66 90 
55 48 89 e5 41 54 53 89 d3
48 83 ec 18 65 48 8b 04 25 28 00 00 00 48 89 45 e8 31 c0 83 fa 0d 76 7e <48> 8b 
bf f0 04 00 00 6a 01 49 89 f0 49 89 f4 52 48 8d 4d dc 48 c7 [ 1739.963567] RSP: 
0018:be2506798db8 EFLAGS: 00010216 [ 1739.969961] RAX:  
RBX: 05ea RCX:
0002
[ 1739.978453] RDX: 05ea RSI: 9f6fb733c0c0 RDI:

[ 1739.986957] RBP: be2506798de0 R08:  R09:
9f733306ff00
[ 1739.995423] R10: 05ea R11: 0100 R12:
9f727b2c0740
[ 1740.003871] R13: 9f724b0e6010 R14: 400a838d R15:

[ 1740.012330] FS:  () GS:9f733fa0()
knlGS:
[ 1740.021848] CS:  0010 DS:  ES:  CR0: 80050033 [ 1740.028757] 
CR2: 04f0 CR3: 0002c740a001 CR4:
000606e0
[ 1740.037209] Call Trace:
[ 1740.040425]  
[ 1740.043154]  ixgbe_process_skb_fields+0x55/0x260 [ixgbe] [ 1740.049577]  
ixgbe_poll+0x52b/0x12c0 [ixgbe] [ 1740.054809]  napi_poll+0x96/0x1b0 [ 
1740.058985]  net_rx_action+0xb8/0x1c0 [ 1740.063575]  __do_softirq+0xd0/0x2a1 
[ 1740.068055]  asm_call_irq_on_stack+0x12/0x20 [ 1740.073345]   [ 
1740.076223]  do_softirq_own_stack+0x3d/0x50 [ 1740.081402]  
irq_exit_rcu+0x95/0xd0 [ 1740.085829]  common_interrupt+0x7c/0x150 [ 
1740.090730]  asm_common_interrupt+0x1e/0x40 [ 1740.095941] RIP: 
0010:cpuidle_enter_state+0xb4/0x3f0
[ 1740.102049] Code: 65 8b 3d 3f fb c6 58 e8 4a 5d 74 ff 48 89 45 d0 66 66
66 66 90 31 ff e8 fa 68 74 ff 80 7d c7 00 0f 85 d3 01 00 00 fb 66 66 90 <66> 66 
90 45 85 e4 0f 88 df 01 00 00 49 63 d4 48 8d 04 52 48 8d 0c [ 1740.124194] RSP: 
0018:be250634fe48 EFLAGS: 0246 [ 1740.130699] RAX: 9f733fa2c6c0 
RBX: de14bfa00f00 RCX:
001f
[ 1740.139315] RDX:  RSI: 373a RDI:

[ 1740.147943] RBP: be250634fe88 R08: 01951980e894 R09:
2840a000
[ 1740.156580] R10: 02b9 R11: 9f733fa2b364 R12:
0005
[ 1740.165266] R13: a856adc0 R14: 0005 R15:

[ 1740.173911]  ? cpuidle_enter_state+0xa6/0x3f0 [ 1740.179470]  
cpuidle_enter+0x2e/0x40 [ 1740.184136]  cpuidle_idle_call+0x145/0x200 [ 
1740.189359]  do_idle+0x7a/0xe0 [ 1740.193426]  cpu_startup_entry+0x20/0x30 [ 
1740.198466]  start_secondary+0xe6/0x100 [ 1740.203425]  
secondary_startup_64+0xb6/0xc0 [ 1740.208779] Modules linked in: igb_uio(OE) 
ice(OE) i40e(OE) ixgbe(OE) dell_rbu vxlan ip6_udp_tunne

Re: [E1000-devel] ixgbe NULL pointer dereference on ubuntu-5.8.0-25-generic

[Fujinaka, Todd]

We only support the LTS variants. Can you try one of those?

Todd Fujinaka
Software Application Engineer
Data Center Group
Intel Corporation
todd.fujin...@intel.com

From: Dmitry Kravkov 
Sent: Tuesday, February 23, 2021 11:24 PM
To: Fujinaka, Todd 
Cc: e1000-de...@lists.sf.net
Subject: Re: [E1000-devel] ixgbe NULL pointer dereference on 
ubuntu-5.8.0-25-generic


On Wed, Feb 24, 2021 at 2:28 AM Fujinaka, Todd 
mailto:todd.fujin...@intel.com>> wrote:
What version of Ubuntu is this? It's going to take me a bit to try to find the 
kernel from the release.
Ubuntu 20.10

Todd Fujinaka
Software Application Engineer
Data Center Group
Intel Corporation
todd.fujin...@intel.com<mailto:todd.fujin...@intel.com>

-Original Message-
From: Dmitry Kravkov mailto:dmit...@qwilt.com>>
Sent: Sunday, February 21, 2021 11:43 PM
To: e1000-de...@lists.sf.net<mailto:e1000-de...@lists.sf.net>
Subject: [E1000-devel] ixgbe NULL pointer dereference on ubuntu-5.8.0-25-generic

Hi All

I'm hitting the following bug during unload inbox driver and insmod'ing 5.9.4 
(also happens with 5.10.2):

[ 1739.889642] BUG: kernel NULL pointer dereference, address:
04f0
[ 1739.897969] #PF: supervisor read access in kernel mode [ 1739.904155] #PF: 
error_code(0x) - not-present page [ 1739.910327] PGD 0 P4D 0 [ 1739.913648] 
Oops:  [#1] SMP PTI [ 1739.917985] CPU: 16 PID: 0 Comm: swapper/16 Kdump: 
loaded Tainted: G
  OE 5.8.0-25-generic #26-Ubuntu
[ 1739.929943] Hardware name:  /, BIOS 2.2.2 01/16/2014 [ 1739.936043] RIP: 
0010:eth_get_headlen+0x26/0xb0 [ 1739.941625] Code: 00 00 00 00 66 66 66 66 90 
55 48 89 e5 41 54 53 89 d3
48 83 ec 18 65 48 8b 04 25 28 00 00 00 48 89 45 e8 31 c0 83 fa 0d 76 7e <48> 8b 
bf f0 04 00 00 6a 01 49 89 f0 49 89 f4 52 48 8d 4d dc 48 c7 [ 1739.963567] RSP: 
0018:be2506798db8 EFLAGS: 00010216 [ 1739.969961] RAX:  
RBX: 05ea RCX:
0002
[ 1739.978453] RDX: 05ea RSI: 9f6fb733c0c0 RDI:

[ 1739.986957] RBP: be2506798de0 R08:  R09:
9f733306ff00
[ 1739.995423] R10: 05ea R11: 0100 R12:
9f727b2c0740
[ 1740.003871] R13: 9f724b0e6010 R14: 400a838d R15:

[ 1740.012330] FS:  () GS:9f733fa0()
knlGS:
[ 1740.021848] CS:  0010 DS:  ES:  CR0: 80050033 [ 1740.028757] 
CR2: 04f0 CR3: 0002c740a001 CR4:
000606e0
[ 1740.037209] Call Trace:
[ 1740.040425]  
[ 1740.043154]  ixgbe_process_skb_fields+0x55/0x260 [ixgbe] [ 1740.049577]  
ixgbe_poll+0x52b/0x12c0 [ixgbe] [ 1740.054809]  napi_poll+0x96/0x1b0 [ 
1740.058985]  net_rx_action+0xb8/0x1c0 [ 1740.063575]  __do_softirq+0xd0/0x2a1 
[ 1740.068055]  asm_call_irq_on_stack+0x12/0x20 [ 1740.073345]   [ 
1740.076223]  do_softirq_own_stack+0x3d/0x50 [ 1740.081402]  
irq_exit_rcu+0x95/0xd0 [ 1740.085829]  common_interrupt+0x7c/0x150 [ 
1740.090730]  asm_common_interrupt+0x1e/0x40 [ 1740.095941] RIP: 
0010:cpuidle_enter_state+0xb4/0x3f0
[ 1740.102049] Code: 65 8b 3d 3f fb c6 58 e8 4a 5d 74 ff 48 89 45 d0 66 66
66 66 90 31 ff e8 fa 68 74 ff 80 7d c7 00 0f 85 d3 01 00 00 fb 66 66 90 <66> 66 
90 45 85 e4 0f 88 df 01 00 00 49 63 d4 48 8d 04 52 48 8d 0c [ 1740.124194] RSP: 
0018:be250634fe48 EFLAGS: 0246 [ 1740.130699] RAX: 9f733fa2c6c0 
RBX: de14bfa00f00 RCX:
001f
[ 1740.139315] RDX:  RSI: 373a RDI:

[ 1740.147943] RBP: be250634fe88 R08: 01951980e894 R09:
2840a000
[ 1740.156580] R10: 02b9 R11: 9f733fa2b364 R12:
0005
[ 1740.165266] R13: a856adc0 R14: 0005 R15:

[ 1740.173911]  ? cpuidle_enter_state+0xa6/0x3f0 [ 1740.179470]  
cpuidle_enter+0x2e/0x40 [ 1740.184136]  cpuidle_idle_call+0x145/0x200 [ 
1740.189359]  do_idle+0x7a/0xe0 [ 1740.193426]  cpu_startup_entry+0x20/0x30 [ 
1740.198466]  start_secondary+0xe6/0x100 [ 1740.203425]  
secondary_startup_64+0xb6/0xc0 [ 1740.208779] Modules linked in: igb_uio(OE) 
ice(OE) i40e(OE) ixgbe(OE) dell_rbu vxlan ip6_udp_tunnel udp_tunnel 
ip6table_filter ip6table_raw ip6_tables mpt3sas raid_class scsi_transport_sas 
mptctl mptbase xt_conntrack iptable_filter xt_tcpudp xt_CT nf_conntrack 
nf_defrag_ipv6
nf_defrag_ipv4 iptable_raw bpfilter intel_rapl_msr intel_rapl_common sb_edac 
iTCO_wdt intel_pmc_bxt iTCO_vendor_support x86_pkg_temp_thermal
mgag200 intel_powerclamp drm_kms_helper cec rc_core coretemp drm kvm_intel 
i2c_algo_bit fb_sys_fops syscopyarea kvm sysfillrect sysimgblt rapl 
intel_cstate joydev pcspkr input_leds mei_me mei ipmi_si acpi_power_meter evbug 
ipmi_devintf lpc_ich ipmi_msghandler mac_hid ip_tables x_tables dm_multipath 
crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel uas crypto_simd 
cryptd glue_helper xfrm_algo usb_storage megaraid_sas dca
tg3 wmi hid_generic usbkbd usbmo

Re: [E1000-devel] ixgbe NULL pointer dereference on ubuntu-5.8.0-25-generic

[Fujinaka, Todd]

What version of Ubuntu is this? It's going to take me a bit to try to find the 
kernel from the release.

Todd Fujinaka
Software Application Engineer
Data Center Group
Intel Corporation
todd.fujin...@intel.com

-Original Message-
From: Dmitry Kravkov  
Sent: Sunday, February 21, 2021 11:43 PM
To: e1000-de...@lists.sf.net
Subject: [E1000-devel] ixgbe NULL pointer dereference on ubuntu-5.8.0-25-generic

Hi All

I'm hitting the following bug during unload inbox driver and insmod'ing 5.9.4 
(also happens with 5.10.2):

[ 1739.889642] BUG: kernel NULL pointer dereference, address:
04f0
[ 1739.897969] #PF: supervisor read access in kernel mode [ 1739.904155] #PF: 
error_code(0x) - not-present page [ 1739.910327] PGD 0 P4D 0 [ 1739.913648] 
Oops:  [#1] SMP PTI [ 1739.917985] CPU: 16 PID: 0 Comm: swapper/16 Kdump: 
loaded Tainted: G
  OE 5.8.0-25-generic #26-Ubuntu
[ 1739.929943] Hardware name:  /, BIOS 2.2.2 01/16/2014 [ 1739.936043] RIP: 
0010:eth_get_headlen+0x26/0xb0 [ 1739.941625] Code: 00 00 00 00 66 66 66 66 90 
55 48 89 e5 41 54 53 89 d3
48 83 ec 18 65 48 8b 04 25 28 00 00 00 48 89 45 e8 31 c0 83 fa 0d 76 7e <48> 8b 
bf f0 04 00 00 6a 01 49 89 f0 49 89 f4 52 48 8d 4d dc 48 c7 [ 1739.963567] RSP: 
0018:be2506798db8 EFLAGS: 00010216 [ 1739.969961] RAX:  
RBX: 05ea RCX:
0002
[ 1739.978453] RDX: 05ea RSI: 9f6fb733c0c0 RDI:

[ 1739.986957] RBP: be2506798de0 R08:  R09:
9f733306ff00
[ 1739.995423] R10: 05ea R11: 0100 R12:
9f727b2c0740
[ 1740.003871] R13: 9f724b0e6010 R14: 400a838d R15:

[ 1740.012330] FS:  () GS:9f733fa0()
knlGS:
[ 1740.021848] CS:  0010 DS:  ES:  CR0: 80050033 [ 1740.028757] 
CR2: 04f0 CR3: 0002c740a001 CR4:
000606e0
[ 1740.037209] Call Trace:
[ 1740.040425]  
[ 1740.043154]  ixgbe_process_skb_fields+0x55/0x260 [ixgbe] [ 1740.049577]  
ixgbe_poll+0x52b/0x12c0 [ixgbe] [ 1740.054809]  napi_poll+0x96/0x1b0 [ 
1740.058985]  net_rx_action+0xb8/0x1c0 [ 1740.063575]  __do_softirq+0xd0/0x2a1 
[ 1740.068055]  asm_call_irq_on_stack+0x12/0x20 [ 1740.073345]   [ 
1740.076223]  do_softirq_own_stack+0x3d/0x50 [ 1740.081402]  
irq_exit_rcu+0x95/0xd0 [ 1740.085829]  common_interrupt+0x7c/0x150 [ 
1740.090730]  asm_common_interrupt+0x1e/0x40 [ 1740.095941] RIP: 
0010:cpuidle_enter_state+0xb4/0x3f0
[ 1740.102049] Code: 65 8b 3d 3f fb c6 58 e8 4a 5d 74 ff 48 89 45 d0 66 66
66 66 90 31 ff e8 fa 68 74 ff 80 7d c7 00 0f 85 d3 01 00 00 fb 66 66 90 <66> 66 
90 45 85 e4 0f 88 df 01 00 00 49 63 d4 48 8d 04 52 48 8d 0c [ 1740.124194] RSP: 
0018:be250634fe48 EFLAGS: 0246 [ 1740.130699] RAX: 9f733fa2c6c0 
RBX: de14bfa00f00 RCX:
001f
[ 1740.139315] RDX:  RSI: 373a RDI:

[ 1740.147943] RBP: be250634fe88 R08: 01951980e894 R09:
2840a000
[ 1740.156580] R10: 02b9 R11: 9f733fa2b364 R12:
0005
[ 1740.165266] R13: a856adc0 R14: 0005 R15:

[ 1740.173911]  ? cpuidle_enter_state+0xa6/0x3f0 [ 1740.179470]  
cpuidle_enter+0x2e/0x40 [ 1740.184136]  cpuidle_idle_call+0x145/0x200 [ 
1740.189359]  do_idle+0x7a/0xe0 [ 1740.193426]  cpu_startup_entry+0x20/0x30 [ 
1740.198466]  start_secondary+0xe6/0x100 [ 1740.203425]  
secondary_startup_64+0xb6/0xc0 [ 1740.208779] Modules linked in: igb_uio(OE) 
ice(OE) i40e(OE) ixgbe(OE) dell_rbu vxlan ip6_udp_tunnel udp_tunnel 
ip6table_filter ip6table_raw ip6_tables mpt3sas raid_class scsi_transport_sas 
mptctl mptbase xt_conntrack iptable_filter xt_tcpudp xt_CT nf_conntrack 
nf_defrag_ipv6
nf_defrag_ipv4 iptable_raw bpfilter intel_rapl_msr intel_rapl_common sb_edac 
iTCO_wdt intel_pmc_bxt iTCO_vendor_support x86_pkg_temp_thermal
mgag200 intel_powerclamp drm_kms_helper cec rc_core coretemp drm kvm_intel 
i2c_algo_bit fb_sys_fops syscopyarea kvm sysfillrect sysimgblt rapl 
intel_cstate joydev pcspkr input_leds mei_me mei ipmi_si acpi_power_meter evbug 
ipmi_devintf lpc_ich ipmi_msghandler mac_hid ip_tables x_tables dm_multipath 
crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel uas crypto_simd 
cryptd glue_helper xfrm_algo usb_storage megaraid_sas dca
tg3 wmi hid_generic usbkbd usbmouse usbhid hid btrfs blake2b_generic libcrc32c 
xor raid6_pq sunrpc dm_mirror dm_region_hash dm_log be2iscsi bnx2i cnic [ 
1740.208816]  uio cxgb4i cxgb4 cxgb3i cxgb3 mdio libcxgbi libcxgb qla4xxx 
iscsi_boot_sysfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi
autofs4 [last unloaded: igb_uio]
[ 1740.331702] CR2: 04f0


Any chance that skb->dev is set to zero in  ixgbe_set_rsc_gso_size ?

I noticed that in kernel code ixgbe_set_rsc_gso_size() calls
skb_headlen(skb) and not eth_get_headlen(skb->dev, skb->data, skb_headlen(skb));


--
Thanks,
Dmitry

Re: [E1000-devel] Fake Tx hangs with ixgbe 5.10.2

[Fujinaka, Todd]

I checked with our performance team and I think the only thing we can see is 
the possible bottleneck with your link partner. We don't do any 
interoperability testing with Netgear, and are unaware if they have any 
equipment that isn't consumer-grade.

I would suggest that you follow up with Ubuntu. They will contact us if they 
need any further help with the issue.

Todd Fujinaka
Software Application Engineer
Data Center Group
Intel Corporation
todd.fujin...@intel.com

-Original Message-
From: Pekka Pietikäinen  
Sent: Thursday, February 4, 2021 2:15 AM
To: e1000-devel@lists.sourceforge.net
Subject: [E1000-devel] Fake Tx hangs with ixgbe 5.10.2

Hi,

We were seeing a lot of Tx hangs (once a day in lab, much more in
production) with Ubuntu 18.04.5 built-in driver (5.0.0-k and 5.1.0-k), causing 
link resets etc.. Trying to isolate the problem a bit more we're now trying the 
latest out-of-tree driver. Now it's

Feb 03 22:46:19 x kernel: NETDEV WATCHDOG: enp13s0 (ixgbe): transmit queue 3 
timed out Feb 03 22:46:19 x kernel: ixgbe :0d:00.0 enp13s0: Fake Tx hang 
detected with timeout of 5 seconds Feb 04 01:56:01 x kernel: ixgbe :0d:00.0 
enp13s0: Fake Tx hang detected with timeout of 10 seconds Feb 04 15:13:21 x 
kernel: ixgbe :0d:00.0 enp13s0: Fake Tx hang detected with timeout of 20 
seconds

"Fake Tx Hang", but traffic still stops for quite a while. Setup is

ixgbe :0d:00.0: enabling device ( -> 0002) ixgbe :0d:00.0 
:0d:00.0 (uninitialized): ixgbe_check_options: 
FCoE Offload feature enabled
ixgbe :0d:00.0: Multiqueue Enabled: Rx Queue count = 8, Tx Queue count = 8 
XDP Queue count = 0 ixgbe :0d:00.0: 32.000 Gb/s available PCIe bandwidth, 
limited by 5 GT/s x8 link at :00:01.0 (capable of 63.008 Gb/s with 8 GT/s 
x8 link) ixgbe :0d:00.0 eth0: MAC: 2, PHY: 20, SFP+: 5, PBA No: E68787-011

ixgbe :0d:00.0 eth0: Enabled Features: RxQ: 8 TxQ: 8 FdirHash ixgbe 
:0d:00.0 eth0: Intel(R) 10 Gigabit Network Connection

talking via 10Gbps fibre to Netgear switch to 20 clients (1GbE over copper)

Disabling irqbalance and using set_irq_affinity (-x local) results in

/proc/interrupts

  132:   6932   1128   1977   2921 7857   7960
4392   3754  IR-PCI-MSI 520192-edge enp0s31f6
  133: 264128 280513 208862 114758 608511
839  90376 187222  IR-PCI-MSI 6815744-edge  enp13s0-TxRx-0
  134:    2844471 365014 105711    1009702 423599
688773  0 589578  IR-PCI-MSI 6815745-edge enp13s0-TxRx-1
  135:  95567 140332  43052  46623  86704 57976
135573 167195  IR-PCI-MSI 6815746-edge enp13s0-TxRx-2
  136: 318887 197761 625025 193550 101415
102114  55755 291272  IR-PCI-MSI 6815747-edge enp13s0-TxRx-3
  137: 491537 214000 158900 244269 266167 97220
25460 289919  IR-PCI-MSI 6815748-edge enp13s0-TxRx-4
  138:  65767 248812 115232 238502  80103 46189
50782  81833  IR-PCI-MSI 6815749-edge enp13s0-TxRx-5
  139: 207157 260936  48883  47421 216735 97253
92818  89079  IR-PCI-MSI 6815750-edge enp13s0-TxRx-6
  140:  21512 424646   5111 390019 441436 4728
291370 278387  IR-PCI-MSI 6815751-edge enp13s0-TxRx-7
  141:  0  0  0  3 0  0
0  0  IR-PCI-MSI 6815752-edge enp13s0

TxRx-1 on CPU0 seems a bit unbalanced, but otherwise fine?

ethtool would suggest it's not flow control related (which would explain 
things?), now experimenting with tuning interrupt moderation / ring size / 
avoiding CPU0 . Is there anything else to try?

NIC statistics:
  rx_packets: 188092169
  tx_packets: 59581798
  rx_bytes: 263463989424
  tx_bytes: 25727566814
  rx_errors: 0
  tx_errors: 0
  rx_dropped: 0
  tx_dropped: 0
  multicast: 1237
  collisions: 0
  rx_over_errors: 0
  rx_crc_errors: 0
  rx_frame_errors: 0
  rx_fifo_errors: 0
  rx_missed_errors: 0
  tx_aborted_errors: 0
  tx_carrier_errors: 0
  tx_fifo_errors: 0
  tx_heartbeat_errors: 0
  rx_pkts_nic: 188092169
  tx_pkts_nic: 59581798
  rx_bytes_nic: 264216358100
  tx_bytes_nic: 25965914840
  lsc_int: 3
  tx_busy: 0
  non_eop_descs: 0
  broadcast: 259
  rx_no_buffer_count: 0
  tx_timeout_count: 0
  tx_restart_queue: 4
  rx_length_errors: 0
  rx_long_length_errors: 0
  rx_short_length_errors: 0
  tx_flow_control_xon: 0
  rx_flow_control_xon: 0
  tx_flow_control_xoff: 0
  rx_flow_control_xoff: 0
  rx_csum_offload_errors: 0
  alloc_rx_page: 40526166
  alloc_rx_page_failed: 0
  alloc_rx_buff_failed: 0
  rx_no_dma_resources: 0
  hw_rsc_aggregated: 0
  hw_rsc_flushed: 0
  fdir_match: 188027415
  fdir_miss: 178920
  fdir_overflow: 0
  fcoe_bad_fccrc: 0
  fcoe_last_errors: 0
  rx_fcoe_dropped: 0
  

Re: [E1000-devel] IRQ affinity not working for iavf devices?

[Fujinaka, Todd]

 0  0  0  0  0 
 0  0  0  0  0  0  0
  0  0  0  0  0  0  0  
IR-IO-APIC-fasteoi   i801_smbus
  24:  0  0  0  0  0  0 
 0  0  0  0  0  0  0  0 
 0  0  0  0  0  0  0
  0  0  0  0  0  0  0   
   0  0  0  0  0  0  0  
0  0  0  0  0  0  0  0  
0  0  0  0  0  0  0 
 0  0  0  0  0  0  0
  0  0  0  0  0  0  0  
IR-PCI-MSI-edge  PCIe PME, pciehp
  25:  0  0  0  0  0  0 
 0  0  0  0  0  0  0  0 
 0  0  0  0  0  0  0
  0  0  0  0  0  0  0   
   0  0  0  0  0  0  0  
0  0  0  0  0  0  0  0  
0  0  0  0  0  0  0 
 0  0  0  0  0  0  0
  0  0  0  0  0  0  0  
IR-PCI-MSI-edge  PCIe PME
@

Todd Fujinaka
Software Application Engineer
Data Center Group
Intel Corporation
todd.fujin...@intel.com

-Original Message-
From: Chris Friesen  
Sent: Friday, January 15, 2021 12:20 PM
To: Fujinaka, Todd ; e1000-devel@lists.sourceforge.net
Subject: Re: [E1000-devel] IRQ affinity not working for iavf devices?

The irqbalance daemon is not running. At the time of the analysis, "cat 
/proc/irq//smp_affinity_list" showed "0-1,24-25" but cat /proc/interrupts 
showed the interrupt counts increasing on CPU 4.

If the interrupt affinity was modified by a userspace tool like irqbalance, I 
believe that /proc/irq//smp_affinity_list would show the updated affinity.

This is the thing that I find really weird, the mismatch between the configured 
affinity and the observed interrupt counts.

Chris

On 1/15/2021 11:03 AM, Fujinaka, Todd wrote:
> I've been reminded that there are other daemons that could be moving around 
> the CPU affinities, such as irqbalance. Make sure that daemon isn't started.
>
> Todd Fujinaka
> Software Application Engineer
> Data Center Group
> Intel Corporation
> todd.fujin...@intel.com
>
> -Original Message-
> From: Fujinaka, Todd 
> Sent: Friday, January 15, 2021 8:44 AM
> To: Chris Friesen ; 
> e1000-devel@lists.sourceforge.net
> Subject: Re: [E1000-devel] IRQ affinity not working for iavf devices?
>
> Sorry for the slow response. I'm asking around internally as I'm not that 
> familiar with iavf. I'll let you know when I hear back.
>
> Todd Fujinaka
> Software Application Engineer
> Data Center Group
> Intel Corporation
> todd.fujin...@intel.com
>
> -Original Message-
> From: Chris Friesen 
> Sent: Tuesday, January 12, 2021 3:53 PM
> To: e1000-devel@lists.sourceforge.net
> Subject: [E1000-devel] IRQ affinity not working for iavf devices?
>
> Hi,
>
> I have a CentOS 7 linux system with 48 logical CPUs and a number of 
> Intel NICs running the i40e driver.  It was booted with
> irqaffinity=0-1,24-25 in the kernel boot args, resulting in 
> /proc/irq/default_smp_affinity showing ",0303".   CPUs 2-11 are set 
> as "isolated" in the kernel boot args.
>
> The iavf driver is 3.7.61.20 and the i40e driver is 2.10.19.82
>
> The problem I'm seeing is that /proc/interrupts shows iavf interrupts on 
> other CPUs.  For example, here are some on CPU 4 where I would not expect to 
> see any interrupts given that "cat /proc/irq//smp_affinity_list" reports 
> "0-1,24-25".
>
> cat /proc/interrupts | grep -e CPU -e 941: -e 942: -e 943: -e 944: -e
> 945: -e 961: -e 962: -e 963: -e 964: -e 965:
>
>       CPU0   CPU1   CPU2   CPU3 CPU4   CPU5
> 941:  0  0  0  0 28490  0
>     IR-PCI-MSI-edge iavf-:b5:03.6:mbx
> 942:  0  0  0  0 333832
> 0  IR-PCI-MSI-edge  iavf-net1-TxRx-0
> 943:  0  0  0  0 300842
> 0  IR-PCI-MSI-edge  iavf-net1-TxRx-1
> 944:  0  0 

Re: [E1000-devel] IRQ affinity not working for iavf devices?

[Fujinaka, Todd]

I've been reminded that there are other daemons that could be moving around the 
CPU affinities, such as irqbalance. Make sure that daemon isn't started.

Todd Fujinaka
Software Application Engineer
Data Center Group
Intel Corporation
todd.fujin...@intel.com

-Original Message-
From: Fujinaka, Todd  
Sent: Friday, January 15, 2021 8:44 AM
To: Chris Friesen ; 
e1000-devel@lists.sourceforge.net
Subject: Re: [E1000-devel] IRQ affinity not working for iavf devices?

Sorry for the slow response. I'm asking around internally as I'm not that 
familiar with iavf. I'll let you know when I hear back.

Todd Fujinaka
Software Application Engineer
Data Center Group
Intel Corporation
todd.fujin...@intel.com

-Original Message-
From: Chris Friesen  
Sent: Tuesday, January 12, 2021 3:53 PM
To: e1000-devel@lists.sourceforge.net
Subject: [E1000-devel] IRQ affinity not working for iavf devices?

Hi,

I have a CentOS 7 linux system with 48 logical CPUs and a number of Intel NICs 
running the i40e driver.  It was booted with
irqaffinity=0-1,24-25 in the kernel boot args, resulting in 
/proc/irq/default_smp_affinity showing ",0303".   CPUs 2-11 are set as 
"isolated" in the kernel boot args.

The iavf driver is 3.7.61.20 and the i40e driver is 2.10.19.82

The problem I'm seeing is that /proc/interrupts shows iavf interrupts on other 
CPUs.  For example, here are some on CPU 4 where I would not expect to see any 
interrupts given that "cat /proc/irq//smp_affinity_list" reports 
"0-1,24-25".

cat /proc/interrupts | grep -e CPU -e 941: -e 942: -e 943: -e 944: -e
945: -e 961: -e 962: -e 963: -e 964: -e 965:

     CPU0   CPU1   CPU2   CPU3 CPU4   CPU5
941:  0  0  0  0 28490  0
   IR-PCI-MSI-edge iavf-:b5:03.6:mbx
942:  0  0  0  0 333832
0  IR-PCI-MSI-edge  iavf-net1-TxRx-0
943:  0  0  0  0 300842
0  IR-PCI-MSI-edge  iavf-net1-TxRx-1
944:  0  0  0  0 333845
0  IR-PCI-MSI-edge  iavf-net1-TxRx-2
945:  0  0  0  0 333822
0  IR-PCI-MSI-edge  iavf-net1-TxRx-3
961:  0  0  0  0 28492
0  IR-PCI-MSI-edge iavf-:b5:02.7:mbx
962:  0  0  0  0 435608
0  IR-PCI-MSI-edge  iavf-net1-TxRx-0
963:  0  0  0  0 394832
0  IR-PCI-MSI-edge  iavf-net1-TxRx-1
964:  0  0  0  0 398414
0  IR-PCI-MSI-edge  iavf-net1-TxRx-2
965:  0  0  0  0 192847
0  IR-PCI-MSI-edge  iavf-net1-TxRx-3

Is this expected?  It seems like the iavf and/or the i40e aren't respecting the 
configured SMP affinity for the interrupt in question.

Thanks,

Chris




___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
https://forums.intel.com/s/topic/0TO0P0018NbWAI/intel-ethernet

___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
https://forums.intel.com/s/topic/0TO0P0018NbWAI/intel-ethernet

___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
https://forums.intel.com/s/topic/0TO0P0018NbWAI/intel-ethernet

Re: [E1000-devel] IRQ affinity not working for iavf devices?

[Fujinaka, Todd]

Sorry for the slow response. I'm asking around internally as I'm not that 
familiar with iavf. I'll let you know when I hear back.

Todd Fujinaka
Software Application Engineer
Data Center Group
Intel Corporation
todd.fujin...@intel.com

-Original Message-
From: Chris Friesen  
Sent: Tuesday, January 12, 2021 3:53 PM
To: e1000-devel@lists.sourceforge.net
Subject: [E1000-devel] IRQ affinity not working for iavf devices?

Hi,

I have a CentOS 7 linux system with 48 logical CPUs and a number of Intel NICs 
running the i40e driver.  It was booted with
irqaffinity=0-1,24-25 in the kernel boot args, resulting in 
/proc/irq/default_smp_affinity showing ",0303".   CPUs 2-11 are set as 
"isolated" in the kernel boot args.

The iavf driver is 3.7.61.20 and the i40e driver is 2.10.19.82

The problem I'm seeing is that /proc/interrupts shows iavf interrupts on other 
CPUs.  For example, here are some on CPU 4 where I would not expect to see any 
interrupts given that "cat /proc/irq//smp_affinity_list" reports 
"0-1,24-25".

cat /proc/interrupts | grep -e CPU -e 941: -e 942: -e 943: -e 944: -e
945: -e 961: -e 962: -e 963: -e 964: -e 965:

     CPU0   CPU1   CPU2   CPU3 CPU4   CPU5
941:  0  0  0  0 28490  0
   IR-PCI-MSI-edge iavf-:b5:03.6:mbx
942:  0  0  0  0 333832
0  IR-PCI-MSI-edge  iavf-net1-TxRx-0
943:  0  0  0  0 300842
0  IR-PCI-MSI-edge  iavf-net1-TxRx-1
944:  0  0  0  0 333845
0  IR-PCI-MSI-edge  iavf-net1-TxRx-2
945:  0  0  0  0 333822
0  IR-PCI-MSI-edge  iavf-net1-TxRx-3
961:  0  0  0  0 28492
0  IR-PCI-MSI-edge iavf-:b5:02.7:mbx
962:  0  0  0  0 435608
0  IR-PCI-MSI-edge  iavf-net1-TxRx-0
963:  0  0  0  0 394832
0  IR-PCI-MSI-edge  iavf-net1-TxRx-1
964:  0  0  0  0 398414
0  IR-PCI-MSI-edge  iavf-net1-TxRx-2
965:  0  0  0  0 192847
0  IR-PCI-MSI-edge  iavf-net1-TxRx-3

Is this expected?  It seems like the iavf and/or the i40e aren't respecting the 
configured SMP affinity for the interrupt in question.

Thanks,

Chris




___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
https://forums.intel.com/s/topic/0TO0P0018NbWAI/intel-ethernet

___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
https://forums.intel.com/s/topic/0TO0P0018NbWAI/intel-ethernet

Re: [E1000-devel] [i40e][bug] driver crashes machine under high network pressure

[Fujinaka, Todd]

In case you didn't see it, there appears to be a new version of i40e on 
e1000.sourceforge.net. I haven't tested it yet but I've been told that it 
should fix the issue with crashing during heavy traffic.

Todd Fujinaka
Software Application Engineer
Data Center Group
Intel Corporation
todd.fujin...@intel.com

-Original Message-
From: Fujinaka, Todd  
Sent: Wednesday, December 30, 2020 11:53 AM
To: Marc 'risson' Schmitt ; 
e1000-devel@lists.sourceforge.net
Cc: c...@cri.epita.fr
Subject: Re: [E1000-devel] [i40e][bug] driver crashes machine under high 
network pressure

The fix is coming and you can ignore that message. I wish I could say more, but 
at this time I don't have any more information at this time.

Todd Fujinaka
Software Application Engineer
Data Center Group
Intel Corporation
todd.fujin...@intel.com

-Original Message-
From: Marc 'risson' Schmitt  
Sent: Wednesday, December 30, 2020 11:37 AM
To: Fujinaka, Todd ; e1000-devel@lists.sourceforge.net
Cc: c...@cri.epita.fr
Subject: Re: [E1000-devel] [i40e][bug] driver crashes machine under high 
network pressure

On 12/30/20 5:48 PM, Fujinaka, Todd wrote:
> Can you try the previous driver? I think there's known issues with the latest.

The previous driver (2.16.6) works fine. We are now using the in-tree version. 
Both of them give the following warning, which we are ignoring as the latest 
driver has issues:

i40e :43:00.0: The driver for the device detected a newer version of the 
NVM image v1.11 than expected v1.9. Please install the most recent version of 
the network driver.

Regards,

--
Marc 'risson' Schmitt
CRI - EPITA

___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
https://forums.intel.com/s/topic/0TO0P0018NbWAI/intel-ethernet


___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
https://forums.intel.com/s/topic/0TO0P0018NbWAI/intel-ethernet

Re: [E1000-devel] [i40e][bug] driver crashes machine under high network pressure

[Fujinaka, Todd]

The fix is coming and you can ignore that message. I wish I could say more, but 
at this time I don't have any more information at this time.

Todd Fujinaka
Software Application Engineer
Data Center Group
Intel Corporation
todd.fujin...@intel.com

-Original Message-
From: Marc 'risson' Schmitt  
Sent: Wednesday, December 30, 2020 11:37 AM
To: Fujinaka, Todd ; e1000-devel@lists.sourceforge.net
Cc: c...@cri.epita.fr
Subject: Re: [E1000-devel] [i40e][bug] driver crashes machine under high 
network pressure

On 12/30/20 5:48 PM, Fujinaka, Todd wrote:
> Can you try the previous driver? I think there's known issues with the latest.

The previous driver (2.16.6) works fine. We are now using the in-tree version. 
Both of them give the following warning, which we are ignoring as the latest 
driver has issues:

i40e :43:00.0: The driver for the device detected a newer version of the 
NVM image v1.11 than expected v1.9. Please install the most recent version of 
the network driver.

Regards,

--
Marc 'risson' Schmitt
CRI - EPITA

___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
https://forums.intel.com/s/topic/0TO0P0018NbWAI/intel-ethernet

Re: [E1000-devel] [i40e][bug] driver crashes machine under high network pressure

[Fujinaka, Todd]

Can you try the previous driver? I think there's known issues with the latest.

Todd Fujinaka
Software Application Engineer
Data Center Group
Intel Corporation
todd.fujin...@intel.com

-Original Message-
From: Fujinaka, Todd  
Sent: Wednesday, December 30, 2020 8:03 AM
To: Marc 'risson' Schmitt ; 
e1000-devel@lists.sourceforge.net
Cc: c...@cri.epita.fr
Subject: Re: [E1000-devel] [i40e][bug] driver crashes machine under high 
network pressure

Unfortunately the kernel crash dump tells us very little besides that you were 
running networking at the time of the dump.

I would suggest that you file a bug here and attach the full dmesg.

Be advised that we generally need to reproduce the issue to make much progress 
and I don't know if we have any AMD systems.

Todd Fujinaka
Software Application Engineer
Data Center Group
Intel Corporation
todd.fujin...@intel.com

-Original Message-
From: Marc 'risson' Schmitt  
Sent: Tuesday, December 29, 2020 5:39 PM
To: Fujinaka, Todd ; e1000-devel@lists.sourceforge.net
Cc: c...@cri.epita.fr
Subject: Re: [E1000-devel] [i40e][bug] driver crashes machine under high 
network pressure

Hi,

First, thanks for your swift response!

On 12/30/20 2:22 AM, Fujinaka, Todd wrote:
> First, sourceforge strips attachment so if you want to submit them you need 
> to open a bug and attach the files there.

I'll attach an extract of the kernel logs at the end of this email.
> Second, if the hardware is Dell, you need to submit the issue to Dell and 
> they will involve us if they need help. They want to troubleshoot problems 
> with their hardware because they need to track the issues. If it is Dell 
> hardware, don't open the bug here because we'll just have to tell you again 
> to submit the issue to Dell.
> 
> The third comment is that this looks like a possible known issue and with 
> Dell hardware you need to use the Dell-approved firmware and drivers. They 
> customize the hardware and firmware and you can't use the generic versions.

The mentioned X722-DA2 were acquired from Intel directly and installed in the 
server by us. The server was indeed acquired from Dell.
The firmware for those NICs was also upgraded by us.

Regards,

--
Marc 'risson' Schmitt
CRI - EPITA

kernel: BUG: Bad page state in process swapper/20  pfn:79d345
kernel: page:f9f9de74d140 refcount:-1 mapcount:0
mapping: index:0x0
kernel: flags: 0x57c000()
kernel: raw: 0057c000 dead0100 dead0122

kernel: raw:   

kernel: page dumped because: nonzero _refcount
kernel: Modules linked in: cfg80211 xt_conntrack xt_MASQUERADE 
nf_conntrack_netlink xfrm_user xfrm_algo nft_counter xt_addrtype nft_compat 
nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ dge aufs overlay 
dell_rbu 8021q garp mrp stp llc bonding nls_iso8859_1 dm_multipath scsi_dh_rdac 
scsi_dh_emc scsi_dh_alua ipmi_ssif amd64_edac_mod edac_mce_amd amd_energy 
joydev input_leds cdc_ether dcdbas dell_wmi_descriptor wmi_bmof efi_pstore ccp 
k10temp acpi_ipmi ipmi_si ipmi_devintf ipmi_msghandler acpi_power_meter mac_hid 
sch_fq_codel ip_tables x_tables autofs4 btrfs blake2b_generic raid1 async_pq 
async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear 
hid_generic usbhid hid crct10dif_pclmul crc32_pclmul mgag200 
ghash_clmulni_intel i2c_algo_bit aesni_intel drm_kms_help rect glue_helper 
sysimgblt fb_sys_fops nvme
kernel:  cec ahci rc_core tg3 nvme_core libahci drm i40e(OE) xhci_pci
i2c_piix4 xhci_pci_renesas wmi
kernel: CPU: 20 PID: 0 Comm: swapper/20 Tainted: GB   W  OE
5.8.0-33-generic #36-Ubuntu
kernel: Hardware name: Dell Inc. PowerEdge R6525/0GK70M, BIOS 1.4.8
05/06/2020
kernel: Call Trace:
kernel:  
kernel:  show_stack+0x52/0x58
kernel:  dump_stack+0x70/0x8d
kernel:  bad_page.cold+0x63/0x94
kernel:  check_new_page_bad+0x6d/0x80
kernel:  rmqueue_bulk.constprop.0+0x38f/0x4c0
kernel:  rmqueue_pcplist.constprop.0+0x128/0x150
kernel:  rmqueue+0x3e/0x770
kernel:  get_page_from_freelist+0x197/0x2c0
kernel:  __alloc_pages_nodemask+0x15d/0x300
kernel:  i40e_alloc_rx_buffers+0x14a/0x260 [i40e]
kernel:  i40e_napi_poll+0xda3/0x1720 [i40e]
kernel:  napi_poll+0x96/0x1b0
kernel:  net_rx_action+0xb8/0x1c0
kernel:  __do_softirq+0xd0/0x2a1
kernel:  asm_call_irq_on_stack+0x12/0x20
kernel:  
kernel:  do_softirq_own_stack+0x3d/0x50
kernel:  irq_exit_rcu+0x95/0xd0
kernel:  common_interrupt+0x7c/0x150
kernel:  asm_common_interrupt+0x1e/0x40
kernel: RIP: 0010:native_safe_halt+0xe/0x10
kernel: Code: e5 8b 74 d0 04 8b 3c d0 e8 6f b3 49 ff 5d c3 cc cc cc cc cc cc cc 
cc cc cc cc cc cc e9 07 00 00 00 0f 00 2d 66 ee 43 00 fb f4  90 e9 07 00 00 
00 0f 00 2d 56 ee 43 00 f4 c3 cc cc 0f
kernel: RSP: 0018:a8d68033fe70 EFLAGS: 0246
kernel: RAX: 94fcd3a0 RBX: 98a39ae5af00 RCX: 98a39f0ad440
kernel: RDX: 04fd7af6 RSI: 0014 RDI: 98a39f09fa80

Re: [E1000-devel] [i40e][bug] driver crashes machine under high network pressure

[Fujinaka, Todd]

Unfortunately the kernel crash dump tells us very little besides that you were 
running networking at the time of the dump.

I would suggest that you file a bug here and attach the full dmesg.

Be advised that we generally need to reproduce the issue to make much progress 
and I don't know if we have any AMD systems.

Todd Fujinaka
Software Application Engineer
Data Center Group
Intel Corporation
todd.fujin...@intel.com

-Original Message-
From: Marc 'risson' Schmitt  
Sent: Tuesday, December 29, 2020 5:39 PM
To: Fujinaka, Todd ; e1000-devel@lists.sourceforge.net
Cc: c...@cri.epita.fr
Subject: Re: [E1000-devel] [i40e][bug] driver crashes machine under high 
network pressure

Hi,

First, thanks for your swift response!

On 12/30/20 2:22 AM, Fujinaka, Todd wrote:
> First, sourceforge strips attachment so if you want to submit them you need 
> to open a bug and attach the files there.

I'll attach an extract of the kernel logs at the end of this email.
> Second, if the hardware is Dell, you need to submit the issue to Dell and 
> they will involve us if they need help. They want to troubleshoot problems 
> with their hardware because they need to track the issues. If it is Dell 
> hardware, don't open the bug here because we'll just have to tell you again 
> to submit the issue to Dell.
> 
> The third comment is that this looks like a possible known issue and with 
> Dell hardware you need to use the Dell-approved firmware and drivers. They 
> customize the hardware and firmware and you can't use the generic versions.

The mentioned X722-DA2 were acquired from Intel directly and installed in the 
server by us. The server was indeed acquired from Dell.
The firmware for those NICs was also upgraded by us.

Regards,

--
Marc 'risson' Schmitt
CRI - EPITA

kernel: BUG: Bad page state in process swapper/20  pfn:79d345
kernel: page:f9f9de74d140 refcount:-1 mapcount:0
mapping: index:0x0
kernel: flags: 0x57c000()
kernel: raw: 0057c000 dead0100 dead0122

kernel: raw:   

kernel: page dumped because: nonzero _refcount
kernel: Modules linked in: cfg80211 xt_conntrack xt_MASQUERADE 
nf_conntrack_netlink xfrm_user xfrm_algo nft_counter xt_addrtype nft_compat 
nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ dge aufs overlay 
dell_rbu 8021q garp mrp stp llc bonding nls_iso8859_1 dm_multipath scsi_dh_rdac 
scsi_dh_emc scsi_dh_alua ipmi_ssif amd64_edac_mod edac_mce_amd amd_energy 
joydev input_leds cdc_ether dcdbas dell_wmi_descriptor wmi_bmof efi_pstore ccp 
k10temp acpi_ipmi ipmi_si ipmi_devintf ipmi_msghandler acpi_power_meter mac_hid 
sch_fq_codel ip_tables x_tables autofs4 btrfs blake2b_generic raid1 async_pq 
async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear 
hid_generic usbhid hid crct10dif_pclmul crc32_pclmul mgag200 
ghash_clmulni_intel i2c_algo_bit aesni_intel drm_kms_help rect glue_helper 
sysimgblt fb_sys_fops nvme
kernel:  cec ahci rc_core tg3 nvme_core libahci drm i40e(OE) xhci_pci
i2c_piix4 xhci_pci_renesas wmi
kernel: CPU: 20 PID: 0 Comm: swapper/20 Tainted: GB   W  OE
5.8.0-33-generic #36-Ubuntu
kernel: Hardware name: Dell Inc. PowerEdge R6525/0GK70M, BIOS 1.4.8
05/06/2020
kernel: Call Trace:
kernel:  
kernel:  show_stack+0x52/0x58
kernel:  dump_stack+0x70/0x8d
kernel:  bad_page.cold+0x63/0x94
kernel:  check_new_page_bad+0x6d/0x80
kernel:  rmqueue_bulk.constprop.0+0x38f/0x4c0
kernel:  rmqueue_pcplist.constprop.0+0x128/0x150
kernel:  rmqueue+0x3e/0x770
kernel:  get_page_from_freelist+0x197/0x2c0
kernel:  __alloc_pages_nodemask+0x15d/0x300
kernel:  i40e_alloc_rx_buffers+0x14a/0x260 [i40e]
kernel:  i40e_napi_poll+0xda3/0x1720 [i40e]
kernel:  napi_poll+0x96/0x1b0
kernel:  net_rx_action+0xb8/0x1c0
kernel:  __do_softirq+0xd0/0x2a1
kernel:  asm_call_irq_on_stack+0x12/0x20
kernel:  
kernel:  do_softirq_own_stack+0x3d/0x50
kernel:  irq_exit_rcu+0x95/0xd0
kernel:  common_interrupt+0x7c/0x150
kernel:  asm_common_interrupt+0x1e/0x40
kernel: RIP: 0010:native_safe_halt+0xe/0x10
kernel: Code: e5 8b 74 d0 04 8b 3c d0 e8 6f b3 49 ff 5d c3 cc cc cc cc cc cc cc 
cc cc cc cc cc cc e9 07 00 00 00 0f 00 2d 66 ee 43 00 fb f4  90 e9 07 00 00 
00 0f 00 2d 56 ee 43 00 f4 c3 cc cc 0f
kernel: RSP: 0018:a8d68033fe70 EFLAGS: 0246
kernel: RAX: 94fcd3a0 RBX: 98a39ae5af00 RCX: 98a39f0ad440
kernel: RDX: 04fd7af6 RSI: 0014 RDI: 98a39f09fa80
kernel: RBP: a8d68033fe90 R08: 0066a171bc54 R09: 0202
kernel: R10: 0003222e R11:  R12: 0014
kernel: R13:  R14:  R15: 

___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
https://forums.intel.com

Re: [E1000-devel] [i40e][bug] driver crashes machine under high network pressure

[Fujinaka, Todd]

Sorry to hear about your problems.

First, sourceforge strips attachment so if you want to submit them you need to 
open a bug and attach the files there.

Second, if the hardware is Dell, you need to submit the issue to Dell and they 
will involve us if they need help. They want to troubleshoot problems with 
their hardware because they need to track the issues. If it is Dell hardware, 
don't open the bug here because we'll just have to tell you again to submit the 
issue to Dell.

The third comment is that this looks like a possible known issue and with Dell 
hardware you need to use the Dell-approved firmware and drivers. They customize 
the hardware and firmware and you can't use the generic versions.

Todd Fujinaka
Software Application Engineer
Data Center Group
Intel Corporation
todd.fujin...@intel.com

-Original Message-
From: Marc 'risson' Schmitt  
Sent: Tuesday, December 29, 2020 4:23 PM
To: e1000-devel@lists.sourceforge.net
Cc: c...@cri.epita.fr
Subject: [E1000-devel] [i40e][bug] driver crashes machine under high network 
pressure

Hi,

During our benchmark of a Ceph cluster, we noticed one of our machines had a 
kernel panic and needed a reboot. After checking the kernel logs (attached), it 
turns out this error came from somewhere inside the i40e driver, which is used 
for our X722-DA2 network cards. After browsing Intel's forum, we found that 
someone had a similar problem, but in Windows with their cards being in a team. 
Ours were in a LACP bond, so we decided to stress test them when not in a bond, 
and were able to reproduce the problem. It also happens when stress testing 
only one of the interfaces, and in 1Gb/s mode (the previous tests were all done 
in 10Gb/s), although it takes longer. The amount of time after which the 
machine freezes/kernel panics is proportional to the network load.
After further investigation, it seems that the number of softirqs is increasing 
by arbitrary steps (graph attached) to a point where the machine freezes. The 
fact that this bug also happens in 1Gb/s mode is leading us to believe that 
there is a memory leak in the i40e driver.
During our tests, we observed that the slab memory is constantly increasing, 
without the machine doing anything else than network operations.
The problem only happens when receiving traffic. Or at least we haven't been 
able to reproduce it when only sending traffic.
After tracing the memory allocations and deallocations made by the kernel, we 
were able to confirm that the driver leaks memory. However, this leak doesn't 
happen when ntuples are off (disabled with `ethtool --features ens1f1 ntuple 
off`).
We now plan to further analyze the memory operations made by the i40e driver 
and will report back if we find anything. In the meantime, we are opening this 
thread hoping that someone might already know of this issue and have a fix.

Some useful information:

We are running the latest version of the i40e downloaded from Intel's website 
because we had to upgrade the firmware of our network cards.
This upgrade was necessary because the cards would otherwise randomly 
disconnect and the server had to be restarted or the cables un- and re-plugged 
for the card to work again (shutting the port off and back on on the switch did 
the trick too). We did not investigate this issue any further.

The tests were ran as such: 4 iperf3 servers were listening on one node 
(hereafter called node-2), and two nodes (hereafter called node-1 and
node-3) were each running 2 iperf3 clients. As such, each interface of
node-2 was hit by two iperf3 clients, one from node-1, another from node-3. 
Note that we tried different combinations of this, with the same outputs, and 
as such we can conclude that the problem isn't due to one network card.

The included kernel logs are from the test using only one interface.
Look for the `[i40e]` pattern from the end of the file and you'll find the 
relevant stacktraces (there are many).

The bug happens when using the out-of-tree module at version 2.13.10.
It doesn't happen with the in-tree module at kernel versions 5.4.0,
5.8.2 and 5.10.2. Neither does it happen when using the out-of-tree module at 
2.12.6.

OS: Ubuntu 20.10
Kernel: 5.8.0-33-generic
i40e version: 2.13.10 - BB96E598E7BFA4F229F7E53
X722 firmware: 5.15 0x8000275d 1.2829.0
iperf: 3.7
TSO and GRO are deactivated
Server: Dell PowerEdge R6525
CPUs: 2x AMD EPYC 7352 24-Core Processor

Regards,

--
Marc 'risson' Schmitt
CRI - EPITA

___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
https://forums.intel.com/s/topic/0TO0P0018NbWAI/intel-ethernet

Re: [E1000-devel] ixgbe Linux V. 5.9.4

[Fujinaka, Todd]

We won't be accepting this patch for the following reasons:

The default has been changed but you will be able to enable those speeds using 
ethtool now.
The default of 2.5G and 5G are OFF because of interoperability issues with 
certain 10G switches that are confused by 2.5G and 5G and negotiate down to 1G.

The README is still in error and says ethtool can't change the advertisement of 
2.5G and 5G, but that should be fixed in the next version. You should be able 
to just use ethtool with the mask shown in the man page.

We did consider your case of users with 2.5G and 5G networks, but the 
throttling of 10G to 1G was seen as a much larger issue which we saw repeatedly 
in large data centers.

Thanks.

Todd Fujinaka
Software Application Engineer
Data Center Group
Intel Corporation
todd.fujin...@intel.com

-Original Message-
From: Dave Bailey  
Sent: Wednesday, November 11, 2020 4:48 PM
To: e1000-de...@lists.sf.net
Subject: [E1000-devel] ixgbe Linux V. 5.9.4

this version added support for 2.5 Gbps and 5 Gbps auto-negotiation

for adapters X550 and later. however, for switches that support

these speeds (and so advertise) but /do not/ advertise those modes

(e.g. Netgear MS-510TX), the changes don't' suffice, and the

adapter reverts to 1 Gb/s speed. I enclose a simple change to

the *ixgbe_setup_phy_link_speed_generic* function that fixes the issue.

Note that the Windows drivers support these speeds out of the box.





___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
https://forums.intel.com/s/topic/0TO0P0018NbWAI/intel-ethernet

Re: [E1000-devel] i40evf: Doing a ethtool gro off seems to be setting VLAN stripping offload

[Fujinaka, Todd]

I think you posted this in e1000-bugs as well and the issue is being addressed 
there.

Todd Fujinaka
Software Application Engineer
Data Center Group
Intel Corporation
todd.fujin...@intel.com

-Original Message-
From: Pratik M.  
Sent: Thursday, October 22, 2020 10:27 PM
To: e1000-devel@lists.sourceforge.net
Subject: [E1000-devel] i40evf: Doing a ethtool gro off seems to be setting VLAN 
stripping offload

Hi,
I am not sure if this is the correct mailer but I see an issue that seems to 
indicate a bug in i40evf behaviour or the VF-PF interaction. Kindly point me to 
the correct mechanism to report this.

Stock CentOS 7.5 VM on a VMWARE ESX 6.7U3 host w/ X710 w/ SR-IOV

I get these error messages in the VM
i40evf :0b:00.0: PF returned error -4 (I40E_ERR_CONFIG) to our request
27

27 is VIRTCHNL_OP_ENABLE_VLAN_STRIPPING.

Turns out, this was happening when I was doing ethtool -K gro off. Should that 
be the case?

The ESX host PF driver (i40en) does not seem to allow VLAN HW stripping offload 
if the vswitch is in VST (VLAN configured in vswitch). And thus the error is 
justified, but I was not trying to change the VLAN offload setting, in the 
first place.

[root@c3 ~]# ethtool -i ens192
driver: i40evf
version: 3.0.1-k
firmware-version: N/A
expansion-rom-version:
bus-info: :0b:00.0
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: no
supports-priv-flags: yes

[root@c3 ~]# modinfo i40evf
filename:
/lib/modules/3.10.0-862.el7.x86_64/kernel/drivers/net/ethernet/intel/i40evf/i40evf.ko.xz
version:3.0.1-k
license:GPL
description:Intel(R) XL710 X710 Virtual Function Network Driver
author: Intel Corporation, 
retpoline:  Y
rhelversion:7.5
srcversion: 6B2F33AFE8D8A61C2FCDCCC
alias:  pci:v8086d1889sv*sd*bc*sc*i*
alias:  pci:v8086d37CDsv*sd*bc*sc*i*
alias:  pci:v8086d1571sv*sd*bc*sc*i*
alias:  pci:v8086d154Csv*sd*bc*sc*i*
depends:
intree: Y
vermagic:   3.10.0-862.el7.x86_64 SMP mod_unload modversions
signer: CentOS Linux kernel signing key
sig_key:3A:F3:CE:8A:74:69:6E:F1:BD:0F:37:E5:52:62:7B:71:09:E3:2B:96
sig_hashalgo:   sha256

I opened bug#670 on sourceforge.

Thanks in advance
Pratik

___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
https://forums.intel.com/s/topic/0TO0P0018NbWAI/intel-ethernet


___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
https://forums.intel.com/s/topic/0TO0P0018NbWAI/intel-ethernet

Re: [E1000-devel] i40e driver - trusted VF features

[Fujinaka, Todd]

I checked around and was told that promiscuous mode and MAC manipulation are 
the features that are enabled. At this time, there aren't any other features.

Todd Fujinaka
Software Application Engineer
Data Center Group
Intel Corporation
todd.fujin...@intel.com

-Original Message-
From: Majcher Wojciech - Hurt  
Sent: Tuesday, October 6, 2020 6:21 AM
To: e1000-devel@lists.sourceforge.net
Subject: [E1000-devel] i40e driver - trusted VF features

Hello,

I am wondering if there is any information/document about what exact features 
are turned on while switching VF into trust mode? I've found docs saying only 
that trust mode allows "for example" promisc mode on VF or MAC address 
manipulation. I would like to know all the features of trusted VF in comparison 
to untrusted VF.

My i40e driver version: 2.3.2-k

Thank you in advance.

BR,
Wojciech



___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
https://forums.intel.com/s/topic/0TO0P0018NbWAI/intel-ethernet


___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
https://forums.intel.com/s/topic/0TO0P0018NbWAI/intel-ethernet

Re: [E1000-devel] ixgbe 5.8.1 dropped support for NBase-T in X550

[Fujinaka, Todd]

The ethtool fixes ended up in the driver that is set to be released "soon", 
scheduled for Q3 so that meant by the end of the month in original scheduling.

The fixes enabled the toggling of 2.5G and 5G. If you need it now, I'd suggest 
adding the code back in. The fixes should be upstream now and in the next 
standalone driver that's coming "soon".

Upstream commit is: a296d665eae1 ("ixgbe: Add ethtool support to enable 2.5 and 
5.0 Gbps support", 2020-07-01)

Todd Fujinaka
Software Application Engineer
Data Center Group
Intel Corporation
todd.fujin...@intel.com

-Original Message-
From: Philipp Wollermann  
Sent: Friday, September 11, 2020 11:45 AM
To: Fujinaka, Todd 
Cc: e1000-devel@lists.sourceforge.net
Subject: Re: [E1000-devel] ixgbe 5.8.1 dropped support for NBase-T in X550

Thank you for your quick response and detailed information, Todd. I totally 
understand where you are coming from.

Per your suggestion, I have now tried to manually enable the auto negotiation 
advertising of the NIC to include 2500baseT and 5000baseT via ethtool:

ethtool -s enp65s0f0 advertise 0x180001028

However I cannot get this to work:
- With vanilla ixgbe 5.7.1 and my patched ixgbe 5.8.1 the NIC advertise 2.5G 
and 5G by default after booting, but as soon as I touch the "ethtool -s $ifname 
advertise" setting in any way, the NIC will no longer advertise 2.5G and 5G 
speeds until a reboot and only offers 100M, 1G, 10G.
- With vanilla ixgbe 5.8.1 it does not advertise 2.5G or 5G by default after a 
boot, and I cannot get it to advertise these speeds via ethtool.

FWIW, ethtool also does not show 2.5G or 5G as supported or advertised link 
modes.

The README of ixgbe 5.8.1 indeed says:
"Devices that support AQRate (X550 and later) will include 2.5 Gbps and 5 Gbps 
in the speeds that the driver advertises during auto-negotiation, even though 
ethtool will not display 2.5 Gbps or 5 Gbps as "Supported link modes" or 
"Advertised link modes." These speeds are only available through unmodified 
auto-negotiation. You cannot use ethtool -s advertise to force auto-negotiation 
to advertise 2.5 Gbps or 5 Gbps."

I have tried with ethtool 4.19 from the latest Debian 10.5 and also the latest 
ethtool 5.8 from kernel.org.

Can you confirm that you're able to enable 2.5G and 5G advertising via ethtool?

Kind regards,
Philipp




On Fri, Sep 11, 2020 at 8:01 PM Fujinaka, Todd  wrote:
>
> The short answer is that we needed to turn it off by default because of 
> interoperability issues with switches that were pre-standards, and you can 
> turn it back on using ethtool.
>
> There were two ways we could fix this: ask the people with the switches to 
> upgrade their switch firmware, or turn off default advertisements for 2.5G 
> and 5G. The customers with the switches objected vehemently to having to 
> touch all their switches, and there were a lot of customers complaining. This 
> is the first time I've heard of anyone asking for 2.5G or 5G outside of the 
> telecom space, so we went with the option of changing the default.
>
> Check the ethtool man page for more information, but there's a bitmask of 
> speeds and modes under ethtool -s that you need to set.
>
> Todd Fujinaka
> Software Application Engineer
> Data Center Group
> Intel Corporation
> todd.fujin...@intel.com
>
> -Original Message-
> From: Philipp Wollermann 
> Sent: Thursday, September 10, 2020 1:30 PM
> To: e1000-devel@lists.sourceforge.net
> Subject: [E1000-devel] ixgbe 5.8.1 dropped support for NBase-T in X550
>
> Hi,
>
> after upgrading from ixgbe 5.7.1 to 5.8.1, my X550-T2 NICs can no longer 
> auto-negotiate a link with 2.5Gb/s or 5GB/s.
>
> I diffed the code and noticed that in src/ixgbe_phy.c the following lines 
> were removed:
>
> case ixgbe_mac_X550:
> hw->phy.speeds_supported |= IXGBE_LINK_SPEED_2_5GB_FULL;
> hw->phy.speeds_supported |= IXGBE_LINK_SPEED_5GB_FULL;
> break;
>
> Indeed, when reverting just this change, ixgbe 5.8.1 successfully brings up 
> links with 2.5Gb/s and 5 Gb/s again.
>
> As the change has not been mentioned in the release notes as an intentional 
> feature removal, I wonder if it's an accidental regression?
>
> Kind regards,
> Philipp
>
> --
> Philipp Wollermann | Software Engineer | phi...@google.com Google 
> Germany GmbH | Erika-Mann-Straße 33 | 80636 München
>
> Geschäftsführer: Paul Manicle, Halimah DeLaine Prado Registergericht 
> und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg
>
>
> ___
> E1000-devel mailing list
> E1000-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/e1000-devel
> To learn more about Intel Ethernet, visit 
> https://forums.

Re: [E1000-devel] ixgbe 5.8.1 dropped support for NBase-T in X550

[Fujinaka, Todd]

The short answer is that we needed to turn it off by default because of 
interoperability issues with switches that were pre-standards, and you can turn 
it back on using ethtool.

There were two ways we could fix this: ask the people with the switches to 
upgrade their switch firmware, or turn off default advertisements for 2.5G and 
5G. The customers with the switches objected vehemently to having to touch all 
their switches, and there were a lot of customers complaining. This is the 
first time I've heard of anyone asking for 2.5G or 5G outside of the telecom 
space, so we went with the option of changing the default.

Check the ethtool man page for more information, but there's a bitmask of 
speeds and modes under ethtool -s that you need to set.

Todd Fujinaka
Software Application Engineer
Data Center Group
Intel Corporation
todd.fujin...@intel.com

-Original Message-
From: Philipp Wollermann  
Sent: Thursday, September 10, 2020 1:30 PM
To: e1000-devel@lists.sourceforge.net
Subject: [E1000-devel] ixgbe 5.8.1 dropped support for NBase-T in X550

Hi,

after upgrading from ixgbe 5.7.1 to 5.8.1, my X550-T2 NICs can no longer 
auto-negotiate a link with 2.5Gb/s or 5GB/s.

I diffed the code and noticed that in src/ixgbe_phy.c the following lines were 
removed:

case ixgbe_mac_X550:
hw->phy.speeds_supported |= IXGBE_LINK_SPEED_2_5GB_FULL;
hw->phy.speeds_supported |= IXGBE_LINK_SPEED_5GB_FULL;
break;

Indeed, when reverting just this change, ixgbe 5.8.1 successfully brings up 
links with 2.5Gb/s and 5 Gb/s again.

As the change has not been mentioned in the release notes as an intentional 
feature removal, I wonder if it's an accidental regression?

Kind regards,
Philipp

--
Philipp Wollermann | Software Engineer | phi...@google.com Google Germany GmbH 
| Erika-Mann-Straße 33 | 80636 München

Geschäftsführer: Paul Manicle, Halimah DeLaine Prado Registergericht und 
-nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg


___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
https://forums.intel.com/s/topic/0TO0P0018NbWAI/intel-ethernet

___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
https://forums.intel.com/s/topic/0TO0P0018NbWAI/intel-ethernet

Re: [E1000-devel] ixgbe for 10 GbE SFP+ without CS4227 phy

[Fujinaka, Todd]

I'm afraid that might need the attention of some of our HW engineers and I'd 
have to play telephone, passing questions back and forth. That just gets 
frustrating.

The official support model is to use IPS & HSD.

Plus, if it's a custom design we have NDAs in place and I don't want to get 
into all that.

Todd Fujinaka
Software Application Engineer
Data Center Group
Intel Corporation
todd.fujin...@intel.com

-Original Message-
From: John H <5snkaz3...@snkmail.com> 
Sent: Thursday, June 18, 2020 4:20 PM
To: Fujinaka, Todd ; 
E1000-devel@lists.sourceforge.net; Fujinaka, Todd 
Subject: RE: [E1000-devel] ixgbe for 10 GbE SFP+ without CS4227 phy

Thanks, Todd.  I already am in discussions with the factory rep - which is half 
Portwell (COM Express board) and half us (carrier board with SFP+).  I can 
certainly provide our side of the design (COM Express connector to SFP+).

But the main question I had for this list I think (I hope) can be answered 
without any of that...

Can the ixgbe driver work without a PHY (e.g., CS4227) between the X552 and 
SFP+?

Knowing the answer to that would help the ongoing troubleshooting.

It seems like the CS4227 is just a line buffer with some features, and a design 
with short traces could work without it.  But I don't know if there is 
something it does electrically that is required or if the ixgbe driver is 
currently written such that it won't work without the PHY.

Fujinaka, Todd wrote at 16:51 + on Jun 18, 2020:
 > Sorry, not enough coffee. Beyond what we are going to be able to answer via 
 > email, mainly because of all the design details, etc.
 >
 > Todd Fujinaka
 > Software Application Engineer
 > Data Center Group
 > Intel Corporation
 > todd.fujin...@intel.com
 >
 > -Original Message-
 > From: Fujinaka, Todd   > Sent: Thursday, June 18, 
 > 2020 9:38 AM  > To: John H <5snkaz3...@snkmail.com>; 
 > E1000-devel@lists.sourceforge.net  > Subject: Re: [E1000-devel] ixgbe for 10 
 > GbE SFP+ without CS4227 phy  >  > Can you file a bug directly through your 
 > factory rep? I think this is beyond what we're going to answer via email.
 >
 > Todd Fujinaka
 > Software Application Engineer
 > Data Center Group
 > Intel Corporation
 > todd.fujin...@intel.com
 >
 > -Original Message-
 > From: John H <5snkaz3...@snkmail.com>  > Sent: Wednesday, June 17, 2020 2:39 
 > PM  > To: E1000-devel@lists.sourceforge.net  > Subject: [E1000-devel] ixgbe 
 > for 10 GbE SFP+ without CS4227 phy  >  > Can the ixgbe driver be used 
 > without a CS4227 PHY between the NIC (X552 in this case) and the SFP+?  Do 
 > you have to configure anything (driver settings, EEPROM firmware) to support 
 > that?
 >
 > I do see a CS4227 error message from the driver, but it's not clear if that 
 > is fatal:
 >
 > Jun 17 21:36:26 localhost kernel: ixgbe :04:00.0: eth10: CS4227 reset 
 > failed: -18 Jun 17 21:36:26 localhost kernel: ixgbe :04:00.0: registered 
 > PHC device on eth10 Jun 17 21:36:26 localhost kernel: ADDRCONF(NETDEV_UP): 
 > eth10: link is not ready Jun 17 21:36:26 localhost kernel: ixgbe 
 > :04:00.0: eth10: detected SFP+: 5  >  > However, I am not seeing link 
 > (NO-CARRIER).
 >
 > Here is 'ethtool -m', so it's talking to the SFP+ okay.
 >
 > $ sudo ethtool -m eth10
 > Identifier  : 0x03 (SFP)
 > Extended identifier : 0x04 (GBIC/SFP defined by 2-wire interface ID)
 > Connector   : 0x07 (LC)
 > Transceiver codes   : 0x10 0x00 0x000x00 0x00 0x00 0x00 0x00
 > :  => 10G Ethernet: 10G Base-SR
 > Encoding: 0x06 (64B/66B)
 > BR, Nominal : 10300MBd
 > Rate identifier : 0x00 (unspecified)
 > Length (SMF,km) : 0km
 > Length (SMF): 0m
 > Length (50um)   : 80m
 > Length (62.5um) : 20m
 > Length (Copper) : 0m
 > Length (OM3): 300m
 > Laser wavelength: 850nm
 > Vendor name : CISCO-INTEGRA   
 > Vendor OUI  : c8:de:51
 > Vendor PN   : SFP-10G-SR-S-IO 
 > Vendor rev  : 01  



___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
https://forums.intel.com/s/topic/0TO0P0018NbWAI/intel-ethernet

Re: [E1000-devel] ixgbe for 10 GbE SFP+ without CS4227 phy

[Fujinaka, Todd]

Sorry, not enough coffee. Beyond what we are going to be able to answer via 
email, mainly because of all the design details, etc.

Todd Fujinaka
Software Application Engineer
Data Center Group
Intel Corporation
todd.fujin...@intel.com

-Original Message-
From: Fujinaka, Todd  
Sent: Thursday, June 18, 2020 9:38 AM
To: John H <5snkaz3...@snkmail.com>; E1000-devel@lists.sourceforge.net
Subject: Re: [E1000-devel] ixgbe for 10 GbE SFP+ without CS4227 phy

Can you file a bug directly through your factory rep? I think this is beyond 
what we're going to answer via email.

Todd Fujinaka
Software Application Engineer
Data Center Group
Intel Corporation
todd.fujin...@intel.com

-Original Message-
From: John H <5snkaz3...@snkmail.com> 
Sent: Wednesday, June 17, 2020 2:39 PM
To: E1000-devel@lists.sourceforge.net
Subject: [E1000-devel] ixgbe for 10 GbE SFP+ without CS4227 phy

Can the ixgbe driver be used without a CS4227 PHY between the NIC (X552 in this 
case) and the SFP+?  Do you have to configure anything (driver settings, EEPROM 
firmware) to support that?

I do see a CS4227 error message from the driver, but it's not clear if that is 
fatal:

Jun 17 21:36:26 localhost kernel: ixgbe :04:00.0: eth10: CS4227 reset 
failed: -18 Jun 17 21:36:26 localhost kernel: ixgbe :04:00.0: registered 
PHC device on eth10 Jun 17 21:36:26 localhost kernel: ADDRCONF(NETDEV_UP): 
eth10: link is not ready Jun 17 21:36:26 localhost kernel: ixgbe :04:00.0: 
eth10: detected SFP+: 5

However, I am not seeing link (NO-CARRIER).

Here is 'ethtool -m', so it's talking to the SFP+ okay.

$ sudo ethtool -m eth10
Identifier  : 0x03 (SFP)
Extended identifier : 0x04 (GBIC/SFP defined by 2-wire interface ID)
Connector   : 0x07 (LC)
Transceiver codes   : 0x10 0x00 0x000x00 0x00 0x00 0x00 0x00
:  => 10G Ethernet: 10G Base-SR
Encoding: 0x06 (64B/66B)
BR, Nominal : 10300MBd
Rate identifier : 0x00 (unspecified)
Length (SMF,km) : 0km
Length (SMF): 0m
Length (50um)   : 80m
Length (62.5um) : 20m
Length (Copper) : 0m
Length (OM3): 300m
Laser wavelength: 850nm
Vendor name : CISCO-INTEGRA   
Vendor OUI  : c8:de:51
Vendor PN   : SFP-10G-SR-S-IO 
Vendor rev  : 01  



___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
https://forums.intel.com/s/topic/0TO0P0018NbWAI/intel-ethernet


___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
https://forums.intel.com/s/topic/0TO0P0018NbWAI/intel-ethernet


___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
https://forums.intel.com/s/topic/0TO0P0018NbWAI/intel-ethernet

Re: [E1000-devel] ixgbe for 10 GbE SFP+ without CS4227 phy

[Fujinaka, Todd]

Can you file a bug directly through your factory rep? I think this is beyond 
what we're going to answer via email.

Todd Fujinaka
Software Application Engineer
Data Center Group
Intel Corporation
todd.fujin...@intel.com

-Original Message-
From: John H <5snkaz3...@snkmail.com> 
Sent: Wednesday, June 17, 2020 2:39 PM
To: E1000-devel@lists.sourceforge.net
Subject: [E1000-devel] ixgbe for 10 GbE SFP+ without CS4227 phy

Can the ixgbe driver be used without a CS4227 PHY between the NIC (X552 in this 
case) and the SFP+?  Do you have to configure anything (driver settings, EEPROM 
firmware) to support that?

I do see a CS4227 error message from the driver, but it's not clear if that is 
fatal:

Jun 17 21:36:26 localhost kernel: ixgbe :04:00.0: eth10: CS4227 reset 
failed: -18 Jun 17 21:36:26 localhost kernel: ixgbe :04:00.0: registered 
PHC device on eth10 Jun 17 21:36:26 localhost kernel: ADDRCONF(NETDEV_UP): 
eth10: link is not ready Jun 17 21:36:26 localhost kernel: ixgbe :04:00.0: 
eth10: detected SFP+: 5

However, I am not seeing link (NO-CARRIER).

Here is 'ethtool -m', so it's talking to the SFP+ okay.

$ sudo ethtool -m eth10
Identifier  : 0x03 (SFP)
Extended identifier : 0x04 (GBIC/SFP defined by 2-wire interface ID)
Connector   : 0x07 (LC)
Transceiver codes   : 0x10 0x00 0x000x00 0x00 0x00 0x00 0x00
:  => 10G Ethernet: 10G Base-SR
Encoding: 0x06 (64B/66B)
BR, Nominal : 10300MBd
Rate identifier : 0x00 (unspecified)
Length (SMF,km) : 0km
Length (SMF): 0m
Length (50um)   : 80m
Length (62.5um) : 20m
Length (Copper) : 0m
Length (OM3): 300m
Laser wavelength: 850nm
Vendor name : CISCO-INTEGRA   
Vendor OUI  : c8:de:51
Vendor PN   : SFP-10G-SR-S-IO 
Vendor rev  : 01  



___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
https://forums.intel.com/s/topic/0TO0P0018NbWAI/intel-ethernet


___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
https://forums.intel.com/s/topic/0TO0P0018NbWAI/intel-ethernet

Re: [E1000-devel] Help Needed.

[Fujinaka, Todd]

This sounds very much like a question we are getting internally from several 
different avenues. If this is the case, please work through the internal 
support (Intel Premier Support for you).

Todd Fujinaka
Software Application Engineer
Data Center Group
Intel Corporation
todd.fujin...@intel.com

-Original Message-
From: Kiran Pamula  
Sent: Saturday, April 11, 2020 12:44 AM
To: e1000-devel@lists.sourceforge.net
Subject: [E1000-devel] Help Needed.

Hi Experts,

We are using one gig NIC 82574L with e100e driver.


Facing following problem of interface TX queue getting wedged.

Kindly provide the debug steps to debug the problem.

#ethtool -i eth0
driver: e1000e
version: 2.4.14-NAPI
firmware-version: 2.1-0
bus-info: :12:00.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags:


Here from debug logs added in the TX descriptor txr->next_to_clean parameter 
got  stuck at same. This value will change once you shut and unshut of specific 
interface.


Thanks,

Kiran

___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
https://forums.intel.com/s/topic/0TO0P0018NbWAI/intel-ethernet


___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
https://forums.intel.com/s/topic/0TO0P0018NbWAI/intel-ethernet

Re: [E1000-devel] i40e virtual MAC on VF issue

[Fujinaka, Todd]

I'll forward this on, but you didn't tell us what version of firmware you're 
running. Can you send the output of "ethtool -i "?

Todd Fujinaka
Software Application Engineer
Data Center Group
Intel Corporation
todd.fujin...@intel.com

-Original Message-
From: Christian Tramnitz  
Sent: Monday, March 2, 2020 8:11 AM
To: e1000-de...@lists.sf.net
Subject: [E1000-devel] i40e virtual MAC on VF issue

Hello,
 
we have a problem with the combination of i40e on Linux (PF) and ixlv on 
FreeBSD (VF).
On the host (bare metal, running KVM), the PF is configured with 
vf-true-promisc-support on and spoof-check disabled, trust enabled.

The actual problem I am seeing is that return packets to a virtual IP/MAC 
(running CARP on FreeBSD) does not reach the system. I.e. for a ping I see the 
echo request going out, but it there is no response. On the guest system 
FreeBSD, looking at tcpdump I can see the echo request in the dump, but not the 
reply. However, on the host system (Linux) I can see on the PF that the echo 
request is actually coming back, destined to the virtual (CARP) MAC address. 
For some reason it is not sent to the VF however. My assumption is that this 
happens due to filtering on the PF, but with above settings 
(vf-true-promisc-support on, spoof-check disabled, trust enabled) I would 
expect the VF to see the return packets.

This happens regardless of the MAC for the VF defined by the PF or not.

The Linux system has been tested with two drivers versions: 2.8.20-k and the 
latest (2.10.19.82)
 
 
Please advise.
 
 
Best regards,
   Christian Tramnitz


___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
https://forums.intel.com/s/topic/0TO0P0018NbWAI/intel-ethernet

___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
https://forums.intel.com/s/topic/0TO0P0018NbWAI/intel-ethernet

Re: [E1000-devel] X710: very slow rx speed (a few MiB/second) when using non-default VSI.

[Fujinaka, Todd]

You can try official channels but you're just going to get an official "Talk to 
Illuminos" from me.

As I said, you can try installing a supported OS to see if it's a hardware 
issue, but we have no support for Illuminos.

Todd Fujinaka
Software Application Engineer
Datacenter Engineering Group
Intel Corporation
todd.fujin...@intel.com

-Original Message-
From: Youzhong Yang  
Sent: Friday, December 13, 2019 10:11 AM
To: Fujinaka, Todd ; e1000-devel@lists.sourceforge.net
Subject: RE: X710: very slow rx speed (a few MiB/second) when using non-default 
VSI.

This mailing list seems quite quiet. Any hope my issue could get some 
attention? If it is a thing of 'Only Linux and FreeBSD are supported', is there 
any other communication channel through which this issue can be escalated? 
Thanks a lot for your understanding.

-Original Message-
From: Youzhong Yang  
Sent: Tuesday, December 3, 2019 12:21 PM
To: Fujinaka, Todd ; e1000-devel@lists.sourceforge.net
Subject: RE: X710: very slow rx speed (a few MiB/second) when using non-default 
VSI.

Hello Todd,

Thank you very much for replying so fast. I am sorry I missed your e-mail as it 
was blocked by our company e-mail filters.

I have contacted illumos dev twice but unfortunately there was no reply, it 
seems the i40e driver developer is no longer active. I am trying to figure out 
how I can fix the issue by myself, I know how to do driver development but this 
particular issue seems to be very unique, and I suspect either something is 
missing when creating the VSIs, or there might be a bug (possibly in the 
Ethernet card firmware) in the way non-default PF VSI is created.

I have researched the Linux and FreeBSD i40e driver code, none of them does the 
same kind of thing our illumos driver does. For each i40e instance, we create 
31 PF VSIs in addition to the default one initiated by the card firmware. When 
receiving data through the RX queues of the default VSI, the performance is 
very good, but when receiving data through the RX queues of the non-default 
VSI, the performance can be very poor.

The "Intel(r) Ethernet Controller X710/ XXV710/XL710 Datasheet" suggests 
there's nothing wrong by having 32 PF VSIs. Please refer to its page 20:

"VSI Support
The X710/XXV710/XL710 supports a total of 384 VSIs. VSI assignment is flexible, 
but the choice to support 384 VSIs is motivated by the following usage example:
* 256 VSIs for VFs or VMDq2
* 32 VSIs for PFs"

We purchased a bunch of XL710 cards, hoping it can deliver better performance 
than the ixgbe cards. Sadly we were hit by this performance issue, and I've 
tried troubleshooting/debugging for more than 2 months, but so far no luck.

Your kind assistance would be highly appreciated.

Sincerely,

-Youzhong Yang
The MathWorks Inc.

-----Original Message-
From: Fujinaka, Todd  
Sent: Monday, December 2, 2019 4:39 PM
To: Youzhong Yang ; e1000-devel@lists.sourceforge.net
Subject: RE: X710: very slow rx speed (a few MiB/second) when using non-default 
VSI.

I think you're going to have to ask Illumos about this. Can you reproduce this 
on a supported OS such as Red Hat Linux or FreeBSD?

Todd Fujinaka
Software Application Engineer
Datacenter Engineering Group
Intel Corporation
todd.fujin...@intel.com

-Original Message-
From: Youzhong Yang  
Sent: Monday, December 2, 2019 12:19 PM
To: e1000-devel@lists.sourceforge.net
Subject: [E1000-devel] X710: very slow rx speed (a few MiB/second) when using 
non-default VSI.

Hello everyone,

I submitted a help request on Intel website and was redirected to this mailing 
list. The request can be found here:

X710: very slow rx speed (a few MiB/second) when using non-default VSI.


I experienced very strange performance issue when sending data from a client to 
a server with X710 card. Details about the investigation can be found here:

https://github.com/youzhongyang/i40e_investigation



The server runs illumos (derived from open solaris), its i40e driver can be 
found here:

http://src.illumos.org/source/xref/illumos-gate/usr/src/uts/common/io/i40e/



So for each i40e instance, we create 32 VSIs (including the default one created 
by the firmware), each VSI is assigned 8 trq pairs. When a VIF/VNIC is created, 
the OS assigns a VSI to it, data receiving through the VNIC's IP will be done 
by the relevant VSI's 8 RX rings. However, data sending will always go through 
the default VSI's 8 TX rings.



The function for creating non-default VSI is here:

http://src.illumos.org/source/xref/illumos-gate/usr/src/uts/common/io/i40e/i40e_main.c#2111



I've upgraded the firmware version to the latest, still the same issue. Is this 
a known issue? or is there anything missing when setting up the non-default VSI?



Your help/advice would be highly appreciated.

Sincerely,
-Youzhong Yang


___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.

Re: [E1000-devel] X710: very slow rx speed (a few MiB/second) when using non-default VSI.

[Fujinaka, Todd]

I think you're going to have to ask Illumos about this. Can you reproduce this 
on a supported OS such as Red Hat Linux or FreeBSD?

Todd Fujinaka
Software Application Engineer
Datacenter Engineering Group
Intel Corporation
todd.fujin...@intel.com

-Original Message-
From: Youzhong Yang  
Sent: Monday, December 2, 2019 12:19 PM
To: e1000-devel@lists.sourceforge.net
Subject: [E1000-devel] X710: very slow rx speed (a few MiB/second) when using 
non-default VSI.

Hello everyone,

I submitted a help request on Intel website and was redirected to this mailing 
list. The request can be found here:

X710: very slow rx speed (a few MiB/second) when using non-default VSI.


I experienced very strange performance issue when sending data from a client to 
a server with X710 card. Details about the investigation can be found here:

https://github.com/youzhongyang/i40e_investigation



The server runs illumos (derived from open solaris), its i40e driver can be 
found here:

http://src.illumos.org/source/xref/illumos-gate/usr/src/uts/common/io/i40e/



So for each i40e instance, we create 32 VSIs (including the default one created 
by the firmware), each VSI is assigned 8 trq pairs. When a VIF/VNIC is created, 
the OS assigns a VSI to it, data receiving through the VNIC's IP will be done 
by the relevant VSI's 8 RX rings. However, data sending will always go through 
the default VSI's 8 TX rings.



The function for creating non-default VSI is here:

http://src.illumos.org/source/xref/illumos-gate/usr/src/uts/common/io/i40e/i40e_main.c#2111



I've upgraded the firmware version to the latest, still the same issue. Is this 
a known issue? or is there anything missing when setting up the non-default VSI?



Your help/advice would be highly appreciated.

Sincerely,
-Youzhong Yang


___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
https://forums.intel.com/s/topic/0TO0P0018NbWAI/intel-ethernet


___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
https://forums.intel.com/s/topic/0TO0P0018NbWAI/intel-ethernet

RE: [E1000-devel] SFP+ EEPROM readouts fail on X722 (ethtool -m: Invalid argument)

[Fujinaka, Todd]

Sorry about the top posting, but if I don't do it this way I can't read 
anything in Outlook (not my preferred MUA).

I think I may have been wrong about things. I'm not as familiar with the x722, 
and the NVM versions are completely different than the x710 and I was confused.

Even worse, I'm not sure if the x722 is able to read the data from the SFP/SFP+ 
EEPROM. I remembered that was a feature we requested internally but I don't 
remember what the progress was.

I'm asking around to see if I can get clarification. I haven't heard anything 
yet.

Todd Fujinaka
Software Application Engineer
Datacenter Engineering Group
Intel Corporation
todd.fujin...@intel.com


-Original Message-
From: Jakub Jankowski [mailto:sha...@toxcorp.com] 
Sent: Tuesday, August 27, 2019 4:01 PM
To: Fujinaka, Todd ; e1000-devel@lists.sourceforge.net
Cc: net...@vger.kernel.org; mhems...@open-systems.com
Subject: Re: [E1000-devel] SFP+ EEPROM readouts fail on X722 (ethtool -m: 
Invalid argument)

Hi,

On 8/27/19 7:56 PM, Fujinaka, Todd wrote:
> The hints should be:
> # ethtool -m eth10
> Cannot get module EEPROM information: Invalid argument # dmesg | tail -n 1 [  
> 445.971974] i40e :3d:00.3 eth10: Module EEPROM memory read not supported. 
> Please update the NVM image.
>
> # ethtool -i eth10
> driver: i40e
> version: 2.9.21
> firmware-version: 3.31 0x8d31 1.1767.0
>
> And the working case:
> # ethtool -i eth8
> driver: i40e
> version: 2.9.21
> firmware-version: 6.01 0x800035cf 1.1876.0
>
> If you don't see it, 6.01 > 3.31.
The reason why firmware between the two is (that much) different is because the 
non-working case is from X722 NIC, while the working one is from X710.

> The NVM update tool should be available on downloadcenter.intel.com

Thanks for the pointer to NVM updater. I'd like to offer some additional 
comments about my experience with the newest one (v4.00):

a) running ./nvmupdate64e (from X722_NVMUpdate_Linux_x64 subdir) errors out 
without really saying what's wrong:

   # ./nvmupdate64e

   Intel(R) Ethernet NVM Update Tool
   NVMUpdate version 1.30.2.11
   Copyright (C) 2013 - 2017 Intel Corporation.


   WARNING: To avoid damage to your device, do not stop the update or reboot or 
power off the system during this update.
   Inventory in progress. Please wait [+.]
   Tool execution completed with the following status: The configuration file 
could not be opened/read, or a syntax error was discovered in the file
   Press any key to exit.

after enabling logging (-l out.log) a bit more is revealed:

   # tail -n 2 out.log
   Error:   Config file line 2: Not supported config file version.
   Error:   Missing CONFIG VERSION parameter in configuration file.

but that's not entirely true, CONFIG VERSION is set in the default 
configuration file:

   # head -n 2 nvmupdate.cfg
   CURRENT FAMILY: 1.0.0
   CONFIG VERSION: 1.14.0

so why isn't this understood?
Manually editing nvmupdate.cfg and setting CONFIG VERSION: 1.11.0 seems to make 
this particular problem go away.

b) Re-doing this with downgraded config version exposes another problem:

   Config file read.
   Error:   Can't open NVM map file [Immediate_offset_2.txt]

and indeed, there is no Immediate_offset_2.txt in 
NVMUpdatePackage_WFT_WFQ_v4.00/X722_NVMUpdate_Linux_x64/
There is one, however, in
NVMUpdatePackage_WFT_WFQ_v4.00/X722_NVMUpdate_EFIx64/ subdir. 
Copying it over to the _Linux_x64 resolves this particular problem

c) Re-doing this with Immediate_offset_2.txt in place exposes third problem:

   Error:   Can't open NVM image file
[LBG_B2_Wolf_Pass_WFT_X557_P01_PHY_Auto_Detect_P23_NCSI_v3.31_800016DB.bin]

and once again - same story. It exists in 
NVMUpdatePackage_WFT_WFQ_v4.00/X722_NVMUpdate_EFIx64/ but not 
NVMUpdatePackage_WFT_WFQ_v4.00/X722_NVMUpdate_Linux_x64/ - had to copy it 
over.


Once I managed to get all these out of the way, the tool finally ran:

   Num Description   Ver. DevId S:B Status
   ===  = = == 
===
   01) Intel(R) Ethernet Server Adapter I350-T4  1.99  1521 00:024 Update not 
available
   02) Intel(R) Ethernet Connection X722 for 3.49  37D2 00:061 Update
   10GBASE-T available
   03) Intel(R) Ethernet Server Adapter I350-T4  1.99  1521 00:175 Update not 
available


The initial starting point was:

0) firmware-version: 3.31 0x8d31 1.1767.0

After first update+reboot, this was bumped to:

1) firmware-version: 3.1d 0x800016db 1.1767.0    (but ethtool -m ethX still 
doesn't work)

So I ran the tool the second time, it said 'Update available' again, but this 
time:

   Num Description   Ver. DevId S:B Status
   ===  = = == 
===
   01) Intel(R) Ethernet Server Adapter I350-T4  1.99  1521 00:024 Update not 
available
   02) Intel(R) Ethernet Connection X722

RE: [E1000-devel] SFP+ EEPROM readouts fail on X722 (ethtool -m: Invalid argument)

[Fujinaka, Todd]

The hints should be:
# ethtool -m eth10
Cannot get module EEPROM information: Invalid argument # dmesg | tail -n 1 [  
445.971974] i40e :3d:00.3 eth10: Module EEPROM memory read not supported. 
Please update the NVM image.

# ethtool -i eth10
driver: i40e
version: 2.9.21
firmware-version: 3.31 0x8d31 1.1767.0

And the working case:
# ethtool -i eth8
driver: i40e
version: 2.9.21
firmware-version: 6.01 0x800035cf 1.1876.0

If you don't see it, 6.01 > 3.31.

The NVM update tool should be available on downloadcenter.intel.com

Todd Fujinaka
Software Application Engineer
Datacenter Engineering Group
Intel Corporation
todd.fujin...@intel.com


-Original Message-
From: Jakub Jankowski [mailto:sha...@toxcorp.com] 
Sent: Tuesday, August 27, 2019 4:03 AM
To: e1000-devel@lists.sourceforge.net
Cc: net...@vger.kernel.org; sha...@toxcorp.com; mhems...@open-systems.com
Subject: [E1000-devel] SFP+ EEPROM readouts fail on X722 (ethtool -m: Invalid 
argument)

Hi,

We can't get SFP+ EEPROM readouts for X722 to work at all:

# ethtool -m eth10
Cannot get module EEPROM information: Invalid argument # dmesg | tail -n 1 [  
445.971974] i40e :3d:00.3 eth10: Module EEPROM memory read not supported. 
Please update the NVM image.
# lspci | grep 3d:00.3
3d:00.3 Ethernet controller: Intel Corporation Ethernet Connection X722 for 
10GbE SFP+ (rev 09)


We're running 4.19.65 kernel at the moment, testing using the newest 
out-of-tree Intel module

# modinfo -F version i40e
2.9.21

We also tried:
- 4.19.65 with in-tree i40e (2.3.2-k)
- stock Arch Linux (kernel 5.2.5, driver 2.8.20-k) and the results are the 
same, as shown above.

# ethtool -i eth10
driver: i40e
version: 2.9.21
firmware-version: 3.31 0x8d31 1.1767.0
expansion-rom-version:
bus-info: :3d:00.3
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: yes
# dmidecode -s baseboard-manufacturer
Intel Corporation
# dmidecode -s baseboard-product-name
S2600WFT
# dmidecode -s baseboard-version
H48104-853

# lspci -vvv
(...)
3d:00.3 Ethernet controller: Intel Corporation Ethernet Connection X722 for 
10GbE SFP+ (rev 09)
DeviceName: Intel PCH Integrated 10 Gigabit Ethernet Controller
Subsystem: Intel Corporation Ethernet Connection X722 for 10GbE SFP+
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ 
Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR-  [disabled]
Capabilities: [40] Power Management version 3
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA 
PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=1 PME-
Capabilities: [50] MSI: Enable- Count=1/1 Maskable+ 64bit+
Address:   Data: 
Masking:   Pending: 
Capabilities: [70] MSI-X: Enable+ Count=129 Masked-
Vector table: BAR=3 offset=
PBA: BAR=3 offset=1000
Capabilities: [a0] Express (v2) Endpoint, MSI 00
DevCap: MaxPayload 512 bytes, PhantFunc 0, Latency L0s <512ns, 
L1 <64us
ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset+ 
SlotPowerLimit 0.000W
DevCtl: CorrErr+ NonFatalErr+ FatalErr+ UnsupReq+
RlxdOrd+ ExtTag+ PhantFunc- AuxPwr- NoSnoop- FLReset-
MaxPayload 256 bytes, MaxReadReq 512 bytes
DevSta: CorrErr+ NonFatalErr- FatalErr- UnsupReq+ AuxPwr+ 
TransPend-
LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Exit 
Latency L0s <64ns, L1 <1us
ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp+
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s (ok), Width x1 (ok)
TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
DevCap2: Completion Timeout: Range AB, TimeoutDis+, LTR-, OBFF 
Not Supported
 AtomicOpsCap: 32bit- 64bit- 128bitCAS-
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, 
OBFF Disabled
 AtomicOpsCtl: ReqEn-
LnkSta2: Current De-emphasis Level: -6dB, 
EqualizationComplete-, EqualizationPhase1-
 EqualizationPhase2-, EqualizationPhase3-, 
LinkEqualizationRequest-
Capabilities: [e0] Vital Product Data
Product Name: Example VPD
Read-only fields:
[V0] Vendor specific:
[RV] Reserved: checksum good, 0 byte(s) reserved
End
Capabilities: [100 v2] Advanced Error Reporting
UESta:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- 
RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-

Re: [E1000-devel] Double VLAN (QinQ) results in single instead of multi queue usage with ixgbe and i40e

[Fujinaka, Todd]

As far as I know you're correct that it's not supported in the driver at this 
time. It's questionable if it's supported in the hardware as not everything in 
the datasheet has been validated completely.

The other problem I've heard is that there is no clear definition of QinQ. 
There are many different use cases, and several implementations asked for by 
different customers.

Todd Fujinaka
Software Application Engineer
Datacenter Engineering Group
Intel Corporation
todd.fujin...@intel.com

-Original Message-
From: Andreas Herz [mailto:e1000-de...@herzandreas.de] 
Sent: Wednesday, July 17, 2019 8:02 AM
To: e1000-devel@lists.sourceforge.net
Subject: [E1000-devel] Double VLAN (QinQ) results in single instead of multi 
queue usage with ixgbe and i40e

Hi,

I have some setups with Intel X710 and Intel X520 cards (10GE) which are used 
for monitoring (IDS) purpose. For improved performance I used the possibility 
that the NICs offer several RX queues which I can later use with the IDS. With 
rx-flow-hash and RSS settings I see a solid distribution of the incoming 
packets when I run 'ethtool -S $NIC' even in scenarios with *one* VLAN tag 
added. But in scenarios where I have VLAN QinQ (double vlan) it all comes down 
to one queue being used.

I read a lot and it seems that it's supported by the hardware but not by the 
drivers yet. Please correct me if I'm wrong.

I also tried different firmware and i40e/ixgbe driver versions but the problem 
still persists with the most recent versions. I played around with all the 
offloading settings, rx-flow-hash settings, RSS keys but didn't succeed.

I also was wondering why setting 'rx-flow-hash' with 'v' doesn't work, I get 
'invalid command' and not 'operation not supported' but looks like it only 
supports 'sdfn' on those NICs/drivers.

I saw some older posts like this
https://sourceforge.net/p/e1000/mailman/e1000-devel/thread/loom.20140128T201406-960%40post.gmane.org/
and patches like
https://github.com/serhepopovych/linux/commit/8ddd8e870c3d60d971dfae49c0fd89ec3e1d3ac9
where I got the assumption that it might be possible to solve this issue.

So first of all can anyone confirm my findings? And if yes is there a fix or 
just a wrong configuration on my side or is that something that needs to be 
patched? Or even worse. is this something that can't be solved with those 
hardware cards?

Thanks

Andreas



___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
http://communities.intel.com/community/wired


___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
http://communities.intel.com/community/wired

RE: [E1000-devel] [Intel-wired-lan] i40e X722 RSS problem with NAT-Traversal IPsec packets

[Fujinaka, Todd]

Just a quick update with the response I got and I'll make sure this is in our 
internal bug database.

Here's what I got back, and it looks like you guys have tried this already:

Have they tried these steps to configure RSS:

RSS Hash Flow
-

Allows you to set the hash bytes per flow type and any combination of one or
more options for Receive Side Scaling (RSS) hash byte configuration.

#ethtool -N  rx-flow-hash  

Where  is:
  tcp4  signifying TCP over IPv4
  udp4  signifying UDP over IPv4
  tcp6  signifying TCP over IPv6
  udp6  signifying UDP over IPv6
And  is one or more of:
  s Hash on the IP source address of the rx packet.
  d Hash on the IP destination address of the rx packet.
  f Hash on bytes 0 and 1 of the Layer 4 header of the rx packet.
  n Hash on bytes 2 and 3 of the Layer 4 header of the rx packet.

Also, looks like the driver needs to be updated to latest version:
>>> 1.1767.0 i40e :3d:00.0: The driver for the device detected a
>>> newer version of the NVM image than expected. Please install the
>>> most recent version of the network driver.

Out of tree: https://sourceforge.net/projects/e1000/files/i40e%20stable/

Todd Fujinaka
Software Application Engineer
Datacenter Engineering Group
Intel Corporation
todd.fujin...@intel.com


-Original Message-
From: Hisashi T Fujinaka [mailto:ht...@twofifty.com] 
Sent: Friday, June 7, 2019 1:50 PM
To: Alexander Duyck 
Cc: e1000-devel@lists.sourceforge.net; Netdev ; 
intel-wired-lan ; LKML 
; Lennart Sorensen 
Subject: Re: [E1000-devel] [Intel-wired-lan] i40e X722 RSS problem with 
NAT-Traversal IPsec packets

On Fri, 7 Jun 2019, Alexander Duyck wrote:

> On Fri, Jun 7, 2019 at 7:39 AM Lennart Sorensen 
>  wrote:
>>
>> On Wed, May 22, 2019 at 10:39:56AM -0400, Lennart Sorensen wrote:
>>> OK I applied those two patches and get this:
>>>
>>> i40e: Intel(R) Ethernet Connection XL710 Network Driver - version 
>>> 2.1.7-k
>>> i40e: Copyright (c) 2013 - 2014 Intel Corporation.
>>> i40e :3d:00.0: fw 3.10.52896 api 1.6 nvm 4.00 0x80001577 
>>> 1.1767.0 i40e :3d:00.0: The driver for the device detected a newer 
>>> version of the NVM image than expected. Please install the most recent 
>>> version of the network driver.
>>> i40e :3d:00.0: MAC address: a4:bf:01:4e:0c:87 i40e :3d:00.0: 
>>> PFQF_HREGION[7]: 0x i40e :3d:00.0: PFQF_HREGION[6]: 
>>> 0x i40e :3d:00.0: PFQF_HREGION[5]: 0x i40e 
>>> :3d:00.0: PFQF_HREGION[4]: 0x i40e :3d:00.0: 
>>> PFQF_HREGION[3]: 0x i40e :3d:00.0: PFQF_HREGION[2]: 
>>> 0x i40e :3d:00.0: PFQF_HREGION[1]: 0x i40e 
>>> :3d:00.0: PFQF_HREGION[0]: 0x i40e :3d:00.0: 
>>> flow_type: 63 input_mask:0x4000 i40e :3d:00.0: 
>>> flow_type: 46 input_mask:0x0007fff8 i40e :3d:00.0: 
>>> flow_type: 45 input_mask:0x0007fff8 i40e :3d:00.0: 
>>> flow_type: 44 input_mask:0x00078000 i40e :3d:00.0: 
>>> flow_type: 43 input_mask:0x0007fffe i40e :3d:00.0: 
>>> flow_type: 42 input_mask:0x0007fffe i40e :3d:00.0: 
>>> flow_type: 41 input_mask:0x0007fffe i40e :3d:00.0: 
>>> flow_type: 40 input_mask:0x0007fffe i40e :3d:00.0: 
>>> flow_type: 39 input_mask:0x0007fffe i40e :3d:00.0: 
>>> flow_type: 36 input_mask:0x00060600 i40e :3d:00.0: 
>>> flow_type: 35 input_mask:0x00060600 i40e :3d:00.0: 
>>> flow_type: 34 input_mask:0x000606078000 i40e :3d:00.0: 
>>> flow_type: 33 input_mask:0x00060606 i40e :3d:00.0: 
>>> flow_type: 32 input_mask:0x00060606 i40e :3d:00.0: 
>>> flow_type: 31 input_mask:0x00060606 i40e :3d:00.0: 
>>> flow_type: 30 input_mask:0x00060606 i40e :3d:00.0: 
>>> flow_type: 29 input_mask:0x00060606 i40e :3d:00.0: 
>>> flow_type: 27 input_mask:0x002c i40e :3d:00.0: 
>>> flow_type: 26 input_mask:0x002c i40e :3d:00.0: flow 
>>> type: 36 update input mask from:0x00060600, 
>>> to:0x00018018 i40e :3d:00.0: flow type: 35 update input 
>>> mask from:0x00060600, to:0x00018018 i40e 
>>> :3d:00.0: flow type: 34 update input mask 
>>> from:0x000606078000, to:0x0001801f8000 i40e :3d:00.0: 
>>> flow type: 33 update input mask from:0x00060606, 
>>> to:0x0001801e i40e :3d:00.0: flow type: 32 update input 
>>> mask from:0x00060606, to:0x0001801e i40e 
>>> :3d:00.0: flow type: 31 update input mask 
>>> from:0x00060606, to:0x0001801e i40e :3d:00.0: 
>>> flow type: 30 update input mask from:0x00060606, 
>>> to:0x0001801e i40e :3d:00.0: flow type: 29 update input 
>>> mask from:0x00060606, to:0x0001801e
>>>
>>> So seems the regions are all 0.
>>>
>>> All ipsec packets still hitting queue 0.
>>
>> So any news or more ideas to try or are we stuck hoping someone 

Re: [E1000-devel] Regarding LVMMC error of Intel igb driver

[Fujinaka, Todd]

It's hard to tell what you're doing, but I'd suggest downloading the datasheet 
and looking at the bits in the register you just referred to.

The easiest way to get the data sheet is to google for "i350 data sheet" and 
select the version on the intel web site. You may want to download the 
specification update as well.

A quick check of 0x3400  looks to show a problem in queue 1, a malicious 
driver behavior from a VLAN Insertion error. Sounds like you're doing something 
odd. 0x7400  is the same error on a different queue.

Todd Fujinaka
Software Application Engineer
Datacenter Engineering Group
Intel Corporation
todd.fujin...@intel.com


-Original Message-
From: Wyborny, Carolyn [mailto:carolyn.wybo...@intel.com] 
Sent: Thursday, April 18, 2019 9:04 AM
To: KyungWon Park 
Cc: e1000-de...@lists.sf.net
Subject: Re: [E1000-devel] Regarding LVMMC error of Intel igb driver

Hello,

I do not work on that driver anymore, but our current support can be obtained 
using the e1000-devel list I’ve copied above.

If you do not get support through this email, please let me know.

Thanks,

Carolyn

From: KyungWon Park [mailto:kw.park.per...@gmail.com]
Sent: Thursday, April 18, 2019 6:00 PM
To: Wyborny, Carolyn 
Subject: Regarding LVMMC error of Intel igb driver

Hello

I've found your e-mail address on
https://git.digitalstrom.org/bsp/linux/commit/1516f0a6492a3d1bd9fbebeac331950986ec9a9b

I was running a server in home which has Linux(ubuntu 18.04) installed with KVM.
I've passed intel igb vf to my VM through sr-iov but

"igb :82:00.1 enp130s0f1: malformed Tx packet detected and dropped, 
LVMMC:0x3400"

pops up every 2 seconds on dmesg.

I am using intel i350-T4 nic for sr-iov

I was searching on the internet what is "LVMMC" and what "0x3400" means but 
only thing I could find was the link above.
Sometimes "LVMMC:0x7400" errors pops up too.

What triggers LVMMC? I've turned off vf spoofcheck through ip utility in linux 
but seems like it doesn't work. (Still kernel warns me that VM tried to change 
MAC address which was set administratively, and reload the vf driver)

Thank you in advance.

Best.





___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
http://communities.intel.com/community/wired

___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
http://communities.intel.com/community/wired

Re: [E1000-devel] igb driver with Intel Atom Bay Trail issue

[Fujinaka, Todd]

This is going to take a bit of time to see what we need to do. The attachments 
were stripped but I think just figuring out what they had to change in the 
Realtek driver will tell us what we need to know.

Todd Fujinaka
Software Application Engineer
Datacenter Engineering Group
Intel Corporation
todd.fujin...@intel.com


-Original Message-
From: Semyon Verchenko [mailto:semverche...@factor-ts.ru] 
Sent: Monday, March 25, 2019 6:25 AM
To: hdego...@redhat.com; Kirsher, Jeffrey T ; 
e1000-de...@lists.sf.net
Subject: [E1000-devel] igb driver with Intel Atom Bay Trail issue

Dear Linux/igb maintainers,

We've encountered problem with igb driver (both one that is distributed with 
Linux kernel and one which is downloadable from intel.com). After commit 
648e921888ad ("clk: x86: Stop marking clocks as CLK_IS_CRITICAL") on machine 
with Intel(R) Atom(TM) CPU E3825 with 4 ethernet cards Intel
I211 only one of cards probed correctly, other ones fail with error -2 (error 
-5 with driver from intel.com). I've rebuilt kernel with commit 648e921888ad 
reverted and all 4 interfaces had to probe correctly. 
Problem is reproducible at least with kernel 5.0.4 and kernels 4.14.y (actually 
firstly I've encountered this on 4.14.105 while it worked fine with 4.14.67 so 
I firstly started to build intermediate versions of kernel and found that 
problem started to appear on 4.14.77, but since it's reproducible in mainline 
kernel I think I should inform mainline kernel maintainers about this). Also it 
is reproducible with igb
5.3.5.22 from intel.com. I'm attaching kernel logs (journalctl.bad is from 
stock kernel and journalctl.badfix is from stock kernel with commit 
648e921888ad reversed), lspci -vnn output (same about file names) and 
/proc/cpuinfo. The system is Arch Linux with kernel replaced to stock one (it 
is not Arch Linux-related problem as it appeared in another system with 4.14 
kernel). I think something like Hans de Goede's r8169 patches is required for 
igb (and maybe other Intel drivers), but I'm not so good with driver developing 
so it seems too hard for me.

Regards,
Semyon Verchenko


___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
http://communities.intel.com/community/wired

Re: [E1000-devel] Dell precision rack 7910 (expansion card) and dell KVM wyse 7030 communication problem

[Fujinaka, Todd]

I am unfamiliar with the products you mention and would suggest you contact 
Dell for initial support. They'll loop us in if they need our help.

Thanks.

Todd Fujinaka
Software Application Engineer
Datacenter Engineering Group
Intel Corporation
todd.fujin...@intel.com

-Original Message-
From: Mosaab Badawy [mailto:mosaab.bad...@emceg.com] 
Sent: Monday, January 21, 2019 11:46 AM
To: e1000-de...@lists.sf.net
Cc: Hussein, Sabah A /SEC 
Subject: [E1000-devel] Dell precision rack 7910 (expansion card) and dell KVM 
wyse 7030 communication problem

Dear Sir,


I have a problem with communication between workstation server and control room 
?through expansion card

server model is Dell precision rack 7910 and dell KVM wyse 7030 zero client 
with 4 ports.


I think the problem is with IP addresses, but actually i made them the same.


I don't know if you can help, it will be highly appreciated.


Best Regards,



Mosaab Sayed Badawy
Instrumentation and Control Engineer
International Operational Department
Egyptian Maintenance Company (EMC)
(002)01018923184 | (+964) 07822610256 | 
mosaab.bad...@emceg.com | 
www.emceg.com | New Cairo - city admin center, ninety 
st. zone 20






This e-mail and its attachments may contain confidential information and are 
intended solely for the use of the individual to whom it is addressed. Any 
views or opinions expressed are solely those of the author and do not necessary 
represent EMC's.
if you have received this message in error, please notify immediately the 
sender by return e-mail and delete the message in its entirety. The contents 
including any attachments should not be disclosed nor copies taken.




This email was scanned by Bitdefender

___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
http://communities.intel.com/community/wired


___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
http://communities.intel.com/community/wired

Re: [E1000-devel] How to use iqvlinux for debugging

[Fujinaka, Todd]

There are no external uses for iqvlinux. It's used for NDA tools and is GPLv2, 
so it's published, but there's nothing we support otherwise.

Todd Fujinaka
Software Application Engineer
Datacenter Engineering Group
Intel Corporation
todd.fujin...@intel.com


-Original Message-
From: Renuka Prasad N P [mailto:repra...@juniper.net] 
Sent: Tuesday, December 11, 2018 2:59 AM
To: e1000-devel@lists.sourceforge.net
Subject: [E1000-devel] How to use iqvlinux for debugging


Hi,

Please share how to use iqvlinux for debugging purpose.
I have latest version which is 1.2.0.8, please advise.

Thanks,
Renuka Prasad NP


___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
http://communities.intel.com/community/wired


___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
http://communities.intel.com/community/wired

Re: [E1000-devel] the info of txgbe

[Fujinaka, Todd]

I've never heard of it either. I decided to google for it and it looks like a 
project out of PRC by NetExpress on github.

We have no information on it.

Todd Fujinaka
Software Application Engineer
Datacenter Engineering Group
Intel Corporation
todd.fujin...@intel.com

-Original Message-
From: lizhuoyao [mailto:lizhuo...@hikdata.com] 
Sent: Friday, July 6, 2018 12:47 AM
To: e1000-devel 
Subject: [E1000-devel] the info of txgbe

hi all:
  Sorry to bother you ,just ask a txgbe dirver.

  Before today, I kown the igb,ixgb,ixgbe.But now,I meet the txgbe first.Then I 
got a little info in www.
  So any one kown where can I get the info about txgbe,and the code? Thanks!


--
Have a good day






--
Check out the vibrant tech community on one of the world's most engaging tech 
sites, Slashdot.org! http://sdm.link/slashdot 
___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
http://communities.intel.com/community/wired

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
http://communities.intel.com/community/wired

Re: [E1000-devel] 1GB auto-negotiated instead of 10GB

[Fujinaka, Todd]

If you have a fleet of servers, you should have a factory contact. Please 
submit a ticket through your FAE if these are Intel cards and you'll get better 
issue routing.

I'm guessing this might be an issue I can't handle on a public mailing list.

Todd Fujinaka
Software Application Engineer
Datacenter Engineering Group
Intel Corporation
todd.fujin...@intel.com

-Original Message-
From: Àbéjídé Àyodélé [mailto:abejideayod...@gmail.com] 
Sent: Monday, July 2, 2018 8:55 AM
To: e1000-devel@lists.sourceforge.net
Subject: [E1000-devel] 1GB auto-negotiated instead of 10GB

Hi,

We have a fleet of Dell PowerEdge R640 all with very similar configuration, 
important piece here is they run intel 10GB ethernet cards as below:

lspci | grep Ether
19:00.0 Ethernet controller: Intel Corporation Ethernet Controller 10G X550T 
(rev 01)
19:00.1 Ethernet controller: Intel Corporation Ethernet Controller 10G X550T 
(rev 01)
1a:00.0 Ethernet controller: Intel Corporation I350 Gigabit Network Connection 
(rev 01)
1a:00.1 Ethernet controller: Intel Corporation I350 Gigabit Network Connection 
(rev 01)


Only 2 of them failing to auto-negotiate correct link speed:

ethtool eno1
Settings for eno1:
Supported ports: [ TP ]
Supported link modes:   100baseT/Full
1000baseT/Full
1baseT/Full
Supported pause frame use: Symmetric
Supports auto-negotiation: Yes
Advertised link modes:  100baseT/Full
1000baseT/Full
1baseT/Full
Advertised pause frame use: Symmetric
Advertised auto-negotiation: Yes
Speed: 1000Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 0
Transceiver: internal
Auto-negotiation: on
MDI-X: Unknown
Supports Wake-on: umbg
Wake-on: g
Current message level: 0x0007 (7)
   drv probe link
Link detected: yes

ethtool eno2
Settings for eno2:
Supported ports: [ TP ]
Supported link modes:   100baseT/Full
1000baseT/Full
1baseT/Full
Supported pause frame use: Symmetric
Supports auto-negotiation: Yes
Advertised link modes:  100baseT/Full
1000baseT/Full
1baseT/Full
Advertised pause frame use: Symmetric
Advertised auto-negotiation: Yes
Speed: 1000Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 0
Transceiver: internal
Auto-negotiation: on
MDI-X: Unknown
Supports Wake-on: umbg
Wake-on: g
Current message level: 0x0007 (7)
   drv probe link
Link detected: yes



They sometimes will also loose connectivity entirely for extended period of up 
to 4 hours, here's our switch logs which usually indicates the problem

lacpd[20416]: %DAEMON-5-LACPD_TIMEOUT: xe-10/0/16: lacp current while timer 
expired current Receive State: CURRENT
/kernel: %KERN-5-KERN_LACP_INTF_STATE_CHANGE: lacp_update_state_userspace:
cifd xe-10/0/16 - ATTACHED state - acting as standby link
rpd[1866]: %DAEMON-6: Decode ifd xe-10/0/16 index 2406: ifdm_flags 0xc000
mcsnoopd[94056]: %DAEMON-6: Decode ifd xe-10/0/16 index 2406: ifdm_flags
0xc000
mcsnoopd[94056]: %DAEMON-6: krt_decode_iflogical: xe-10/0/16.0 has got color 0
lacpd[20416]: %DAEMON-5-LACPD_TIMEOUT: xe-11/0/16: lacp current while timer 
expired current Receive State: CURRENT
/kernel: %KERN-5-KERN_LACP_INTF_STATE_CHANGE: lacp_update_state_userspace:
cifd xe-11/0/16 - ATTACHED state - acting as standby link
lacpd[20416]: %DAEMON-5-LACP_INTF_DOWN: ae125: Interface marked down due to 
lacp timeout on member xe-11/0/16
rpd[1866]: %DAEMON-6: Decode ifd xe-11/0/16 index 2456: ifdm_flags 0xc000
mcsnoopd[94056]: %DAEMON-6: Decode ifd xe-11/0/16 index 2456: ifdm_flags
0xc000
mcsnoopd[94056]: %DAEMON-6: krt_decode_iflogical: xe-11/0/16.0 has got color 0
/kernel: %KERN-5-KERN_LACP_INTF_STATE_CHANGE: lacp_update_state_userspace:
cifd xe-11/0/16 - CD state - ready to carry traffic
/kernel: %KERN-5-KERN_LACP_INTF_STATE_CHANGE: lacp_update_state_userspace:
cifd xe-10/0/16 - CD state - ready to carry traffic
rpd[1866]: %DAEMON-6: Decode ifd xe-11/0/16 index 2456: ifdm_flags 0xc000
rpd[1866]: %DAEMON-6: Decode ifd xe-10/0/16 index 2406: ifdm_flags 0xc000
mcsnoopd[94056]: %DAEMON-6: Decode ifd xe-11/0/16 index 2456: ifdm_flags
0xc000
mcsnoopd[94056]: %DAEMON-6: krt_decode_iflogical: xe-11/0/16.0 has got color 0
mcsnoopd[94056]: %DAEMON-6: received iff message xe-11/0/16.0 ifl 8c6fcf0 op 2 
flag 0
mcsnoopd[94056]: %DAEMON-6: KRT Ifstate: Decode iff message -
ifl(xe-11/0/16.0) without mesh-group tlv
mcsnoopd[94056]: %DAEMON-6: Decode ifd xe-10/0/16 index 2406: ifdm_flags
0xc000
mcsnoopd[94056]: %DAEMON-6: krt_decode_iflogical: 

Re: [E1000-devel] Fwd: [BUG] igb: reconnecting of cable not always detected

[Fujinaka, Todd]

To clarify, is this on the on-board Ethernet on your Supermicro motherboards? 
Or are you using a separate PCIe network adapter? We could tell if you file a 
bug on sourceforge and then attach the full dmesg and the lspci -vvv (don't 
just paste it inline). If it is a separate card, can you tell us more 
information about it?

Todd Fujinaka
Software Application Engineer
Datacenter Engineering Group
Intel Corporation
todd.fujin...@intel.com

-Original Message-
From: Thomas Netousek [mailto:tho...@netousek.com] 
Sent: Saturday, June 9, 2018 6:51 PM
To: e1000-devel@lists.sourceforge.net
Subject: [E1000-devel] Fwd: [BUG] igb: reconnecting of cable not always detected

Hi,

forwarding as I do not know if the igb maintainers are subscribed to the lkml.

Thomas




 Forwarded Message 
Subject:[BUG] igb: reconnecting of cable not always detected
Date:   Sat, 9 Jun 2018 19:15:37 +0200
From:   Thomas Netousek 
To: linux-ker...@vger.kernel.org



I have a similar problem.
If I disconnect and reconnect the ethernet cable on a Intel Ethernet card then 
the device does not come up again.

For me this problem happens on the first pull of the LAN cable all the time.

It is reproducible on Supermicro X8, X9 and X10 dual CPU mainboards with 
onboard networking providing two PHY interfaces using Intel 82576 and
I350 chips.
It is not reproducible on a Supermicro X10SLL single mainboard with onboard 
I210 chip providing one PHY for eth0 (tested) and one I217-LM powered by the 
e1000e driver (not connected, not tested).

It is reproducible using kernel 4.9.107 and 4.17.0.
It is not reproducible using  kernels 4.1.48, 4.4.136.
So it might be related to the changes in the igb versions from 5.3.0-k
(good) to 5.4.0-k (bad).

After pulling and re-plugging the cable, with the bad driver I get:

# ip -d link show eth0
2: eth0:  mtu 1500 qdisc mq state DOWN mode 
DEFAULT group default qlen 1000
     link/ether 0c:c4:7a:69:9d:3e brd ff:ff:ff:ff:ff:ff promiscuity 0 
numtxqueues 8 numrxqueues 8 gso_max_size 65536 gso_max_segs 65535

# ethtool -i eth0
Cannot get driver information: No such device

The last lines in the dmesg output are:

[   13.127730] igb :01:00.0 eth0: igb: eth0 NIC Link is Up 1000 Mbps Full 
Duplex, Flow Control: RX/TX [   13.747735] igb :01:00.1 eth1: igb: eth1 NIC 
Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX [  147.760943] igb 
:01:00.0 eth0: igb: eth0 NIC Link is Down [  608.211864] igb :01:00.0 
eth0: PCIe link lost, device now detached

Please note that the "PCIe link lost" message arrives 8 minutes after 
re-plugging the LAN cable.

I hope that information helps pinning down this bug and fixing it.

Kind regards
Thomas




--
Check out the vibrant tech community on one of the world's most engaging tech 
sites, Slashdot.org! http://sdm.link/slashdot 
___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
http://communities.intel.com/community/wired
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
http://communities.intel.com/community/wired

Re: [E1000-devel] Interrupt coalescence issues with igb and e1000e drivers

[Fujinaka, Todd]

I let Jean know that we have an internal HPE team and he should be going 
through them for this issue.

Todd Fujinaka
Software Application Engineer
Datacenter Engineering Group
Intel Corporation
todd.fujin...@intel.com


-Original Message-
From: Jean Tourrilhes [mailto:j...@labs.hpe.com] 
Sent: Friday, April 27, 2018 4:32 PM
To: e1000-devel@lists.sourceforge.net
Subject: [E1000-devel] Interrupt coalescence issues with igb and e1000e drivers

Hi,

IMHO, Interrupt coalescence does not work as advertised with the igb 
and e1000e drivers. Interrupt coalescence seems to not use properly the 
'rx-usecs' parameter. Moreover, when running at 100 Mb/s, it seems to be scaled 
by a factor 10, resulting in huge packet latency.

The Broadcom tg3 driver has a default time window for interrupt 
coalescence of about 20 us, as per ethtool. With UDP traffic, a 1 Gb/s, I 
measure a time window of around 40 us. At 100 Mb/s, I measure a time window of 
around 60 us in the worse case, in other cases it's below 20 us.
The X710/i40e driver has a default time window of 25 us. With UDP 
traffic, I measure a time window of around 20 us, at 10 Gb/s (sorry, can't 
change speed).

Both the igb driver, the default time window for interrupt coalescence 
of about 3 us, as per ethtool (see below).
With UDP traffic, at 1 Gb/s, I measure a time window of around
40 us.
At 100 Mb/s, I measure a time window of around 200-250 us (see below).
The e1000e driver has the same behaviour as igb.

If in igb, I use ethtool to change the time window for interrupt 
coalescence to 1 us (i.e., the smallest value), it does not seem to help. With 
rx-usecs set to 1, at 100 Mb/s, I still measure around 200-250 us, and at 1 
Gb/s, 40 us. I.e., reducing the parameter does not change anything.

As igb and e1000e don't seem to be using the rx-usecs parameter 
properly, there seems to be no way to set interrupt coalescence to a sensible 
value at 100 Mb/s (let say, 20-40 us).
So, IMHO, buggy.

Setup :
-
Linux kernel : 4.9.82
igb driver : 5.3.5.18 & 5.4.0-k
firmware-version: 3.16, 0x84ff, 1.304.0
e1000e driver : 3.2.6-k
firmware-version: 5.6-10

Speed is changed with :
# ethtool -s eth6 speed 100 duplex full

Speed change was validated with ethtool and running netperf

Interrupt Coal :
--
Default settings. With the default setting, the max int-coal time 
window is supposed to be 3 usec.

# ethtool -c eth6
Coalesce parameters for eth6:
Adaptive RX: off  TX: off
stats-block-usecs: 0
sample-interval: 0
pkt-rate-low: 0
pkt-rate-high: 0

rx-usecs: 3
rx-frames: 0
rx-usecs-irq: 0
rx-frames-irq: 0

tx-usecs: 0
tx-frames: 0
tx-usecs-irq: 0
tx-frames-irq: 128

rx-usecs-low: 0
rx-frame-low: 0
tx-usecs-low: 0
tx-frame-low: 0

rx-usecs-high: 0
rx-frame-high: 0
tx-usecs-high: 0
tx-frame-high: 0

rx-usecs was changed with :
# ethtool -C eth6 rx-usecs 1

Received packet log :
---
I run a stream of UDP packet, each packet is 1000 byte, log of receive 
times is below. In the received packet time log, I can see groups of packets 
batched closely together (separated by 2 usec, indicating a speed of 4 Gb/s, 
i.e. clearly coalesced), and those groups are separated by 200-250 us.

Please find below the packet log. First column is received time from 
the kernel in nanoseconds. Second column is time difference to previous 
received packet, i.e. the gap between two received packets in nanoseconds.

 1524864423.932657212  ;  226658
 1524864423.932659491  ;  2279
 1524864423.932661023  ;  1532
 1524864423.932662308  ;  1285
 1524864423.932923593  ;  261285
 1524864423.932927914  ;  4321
 1524864423.933147424  ;  219510
 1524864423.933149500  ;  2076
 1524864423.933407932  ;  258432
 1524864423.933412290  ;  4358
 1524864423.933413758  ;  1468
 1524864423.933415107  ;  1349
 1524864423.933637323  ;  16
 1524864423.933639505  ;  2182
 1524864423.933640854  ;  1349
 1524864423.933899512  ;  258658
 1524864423.934130315  ;  230803
 1524864423.934132701  ;  2386
 1524864423.934134096  ;  1395
 1524864423.934135391  ;  1295
 1524864423.934377340  ;  241949
 1524864423.934381582  ;  4242
 1524864423.934382997  ;  1415
 1524864423.934628593  ;  245596
 1524864423.934885071  ;  256478
 1524864423.934886928  ;  1857
 1524864423.934888129  ;  1201
 1524864423.934889348  ;  1219
 1524864423.934890530  ;  1182
 1524864423.935107683  ;  217153
 1524864423.935110140  ;  2457
 1524864423.935111242  ;  1102
 1524864423.935367980  ;  256738
 1524864423.935371950  ;  3970
 1524864423.935373136  ;  1186
 1524864423.935600854  ;  227718
 1524864423.935855419  ;  254565
 1524864423.935857871  ;  2452
 1524864423.935859196  ;  1325
 1524864423.935860454  ;  1258
 1524864423.935861796  ;  1342
 1524864423.936087278  ;  225482
 1524864423.936089122  ;  1844
 1524864423.936366475  ;  277353
 

Re: [E1000-devel] e1000 driver compile

[Fujinaka, Todd]

No such thing as a generic kernel configuration in the way that you’re saying.

You’re going at this sideways, and we don’t even know what kind of laptop 
you’re running. Also, I wonder how much experience you have with Linux in 
general. So far the only version numbers you’ve provided are for an ancient 
kernel and our newer driver. Even 16.04 (which came out in April 2016) is 
running 4.13.0.

I’d say, start over. Get a newer version of Ubuntu LTS (16.04LTS or 18.04LTS if 
you can wait a week), and it should all work. If you have to, get a version 
that runs from memory (the live version) and download the bits you need for 
your old Ubuntu. Use google for help.

Todd Fujinaka
Software Application Engineer
Datacenter Engineering Group
Intel Corporation
todd.fujin...@intel.com

From: Dan Zulaica [mailto:dan.zulaica...@gmail.com]
Sent: Thursday, April 19, 2018 9:08 AM
To: Fujinaka, Todd <todd.fujin...@intel.com>
Cc: Kirsher, Jeffrey T <jeffrey.t.kirs...@intel.com>; 
e1000-devel@lists.sourceforge.net
Subject: Re: [E1000-devel] e1000 driver compile

Hi Todd,

The computer does not have any type of networking, just ‘lo’ shows up using 
‘ifconfig -a’. That is my problem trying to fix this. It definitely would be 
easier if I can use apt-get.

I have to type everything. So doing the best I can within a reasonable amount 
of time.

I need to compile for 2.6.32-24-generic #39 Ubuntu. I thought there would be a 
general way to create a generic kernel configuration.

Thanks,
Dan


On Thu, Apr 19, 2018 at 9:18 AM Fujinaka, Todd 
<todd.fujin...@intel.com<mailto:todd.fujin...@intel.com>> wrote:
Oh, and you never did tell us what version of Ubuntu you're running, either. 
Most likely it's no longer supported, but I'm not sure why you're having so 
much trouble with the drivers.

Todd Fujinaka
Software Application Engineer
Datacenter Engineering Group
Intel Corporation
todd.fujin...@intel.com<mailto:todd.fujin...@intel.com>


-----Original Message-
From: Fujinaka, Todd 
[mailto:todd.fujin...@intel.com<mailto:todd.fujin...@intel.com>]
Sent: Thursday, April 19, 2018 8:06 AM
To: Dan Zulaica <dan.zulaica...@gmail.com<mailto:dan.zulaica...@gmail.com>>; 
Kirsher, Jeffrey T 
<jeffrey.t.kirs...@intel.com<mailto:jeffrey.t.kirs...@intel.com>>
Cc: e1000-devel@lists.sourceforge.net<mailto:e1000-devel@lists.sourceforge.net>
Subject: Re: [E1000-devel] e1000 driver compile

First, you really haven't shown us any of the error messages you're getting. 
Second, you really do need the kernel headers for your version of the kernel.

When you install the kernel headers, you should've done something like "apt 
install linux-headers-`uname -r`" (everything within the quotes) and something 
similar for the extras.

Cut-and-paste the errors (remember to paste them all) and maybe even file a bug 
and attach your whole dmesg if there's a run-time issue.

Todd Fujinaka
Software Application Engineer
Datacenter Engineering Group
Intel Corporation
todd.fujin...@intel.com<mailto:todd.fujin...@intel.com>

-Original Message-
From: Dan Zulaica 
[mailto:dan.zulaica...@gmail.com<mailto:dan.zulaica...@gmail.com>]
Sent: Wednesday, April 18, 2018 11:55 PM
To: Kirsher, Jeffrey T 
<jeffrey.t.kirs...@intel.com<mailto:jeffrey.t.kirs...@intel.com>>
Cc: e1000-devel@lists.sourceforge.net<mailto:e1000-devel@lists.sourceforge.net>
Subject: Re: [E1000-devel] e1000 driver compile

Well,

There are 'invalid module format' errors trying to install the re-compile .ko 
files from '2.6.32.24'. Is there a version mis-match?
If so how do I configure for generic and can I change the version? I need 
version '2.6.32-24-generic'. If that is the problem. I guess I could try to 
force the install.

Any ideas?
Dan


On Thu, Apr 19, 2018 at 12:16 AM, Dan Zulaica 
<dan.zulaica...@gmail.com<mailto:dan.zulaica...@gmail.com>> wrote:
> Hi Jeffrey,
>
> I finally found the version.h and autoconf.h files in the
> include/linux directory. This was after creating the kernel .config
> file and re-compiling the entire kernel and modules. I will try the
> included modules and if still do not work, will compile the separate
> downloaded modules from sourceforge that you gave me earlier.
>
> Thanks for the help!
> Dan
>
>
> On Wed, Apr 18, 2018 at 2:49 PM, Kirsher, Jeffrey T
> <jeffrey.t.kirs...@intel.com<mailto:jeffrey.t.kirs...@intel.com>> wrote:
>>> -Original Message-
>>> From: Dan Zulaica 
>>> [mailto:dan.zulaica...@gmail.com<mailto:dan.zulaica...@gmail.com>]
>>> Sent: Wednesday, April 18, 2018 12:43
>>> To: Kirsher, Jeffrey T 
>>> <jeffrey.t.kirs...@intel.com<mailto:jeffrey.t.kirs...@intel.com>>
>>> Cc: 
>>> e1000-devel@lists.sourceforge.net<mailto:e1000-devel@lists.sourceforge.net>
>>> Sub

Re: [E1000-devel] e1000 driver compile

[Fujinaka, Todd]

Oh, and you never did tell us what version of Ubuntu you're running, either. 
Most likely it's no longer supported, but I'm not sure why you're having so 
much trouble with the drivers.

Todd Fujinaka
Software Application Engineer
Datacenter Engineering Group
Intel Corporation
todd.fujin...@intel.com


-Original Message-
From: Fujinaka, Todd [mailto:todd.fujin...@intel.com] 
Sent: Thursday, April 19, 2018 8:06 AM
To: Dan Zulaica <dan.zulaica...@gmail.com>; Kirsher, Jeffrey T 
<jeffrey.t.kirs...@intel.com>
Cc: e1000-devel@lists.sourceforge.net
Subject: Re: [E1000-devel] e1000 driver compile

First, you really haven't shown us any of the error messages you're getting. 
Second, you really do need the kernel headers for your version of the kernel.

When you install the kernel headers, you should've done something like "apt 
install linux-headers-`uname -r`" (everything within the quotes) and something 
similar for the extras.

Cut-and-paste the errors (remember to paste them all) and maybe even file a bug 
and attach your whole dmesg if there's a run-time issue.

Todd Fujinaka
Software Application Engineer
Datacenter Engineering Group
Intel Corporation
todd.fujin...@intel.com

-Original Message-
From: Dan Zulaica [mailto:dan.zulaica...@gmail.com]
Sent: Wednesday, April 18, 2018 11:55 PM
To: Kirsher, Jeffrey T <jeffrey.t.kirs...@intel.com>
Cc: e1000-devel@lists.sourceforge.net
Subject: Re: [E1000-devel] e1000 driver compile

Well,

There are 'invalid module format' errors trying to install the re-compile .ko 
files from '2.6.32.24'. Is there a version mis-match?
If so how do I configure for generic and can I change the version? I need 
version '2.6.32-24-generic'. If that is the problem. I guess I could try to 
force the install.

Any ideas?
Dan


On Thu, Apr 19, 2018 at 12:16 AM, Dan Zulaica <dan.zulaica...@gmail.com> wrote:
> Hi Jeffrey,
>
> I finally found the version.h and autoconf.h files in the 
> include/linux directory. This was after creating the kernel .config 
> file and re-compiling the entire kernel and modules. I will try the 
> included modules and if still do not work, will compile the separate 
> downloaded modules from sourceforge that you gave me earlier.
>
> Thanks for the help!
> Dan
>
>
> On Wed, Apr 18, 2018 at 2:49 PM, Kirsher, Jeffrey T 
> <jeffrey.t.kirs...@intel.com> wrote:
>>> -Original Message-
>>> From: Dan Zulaica [mailto:dan.zulaica...@gmail.com]
>>> Sent: Wednesday, April 18, 2018 12:43
>>> To: Kirsher, Jeffrey T <jeffrey.t.kirs...@intel.com>
>>> Cc: e1000-devel@lists.sourceforge.net
>>> Subject: Re: [E1000-devel] e1000 driver compile
>>>
>>> Great,
>>>
>>> I thought I at least had the linux headers, though no autoconf.h file.
>>> Are you saying I should download more than the headers?
>>
>> In Ubuntu (or Kubuntu), there are 2 kernel header packages that you need to 
>> install, they are linux-headers- and linux-headers-> version>-generic.  After installing both, if you still do not have a 
>> autoconf.h file, then you will need to download the entire kernel source.
>>
>> It is also recommended (by Ubuntu) to install the build-essentials package.
>>
>>>
>>> On Wed, Apr 18, 2018 at 1:39 PM, Kirsher, Jeffrey T 
>>> <jeffrey.t.kirs...@intel.com> wrote:
>>> > The Intel 1502 device id is the  82579LM Gigabit Network 
>>> > Connection,
>>> which is supported by the e1000e driver.  You can download the 
>>> e1000e driver from sourceforge.net:
>>> > https://sourceforge.net/projects/e1000/files/e1000e%20stable/
>>> >
>>> > Latest version is 3.4.0.2 and should compile just fine on your 
>>> > kernel, you
>>> just need to make sure you have the Linux kernel source installed.
>>> >
>>> > The Broadcom device is your wireless adapter.
>>> >
>>> >> -Original Message-
>>> >> From: Dan Zulaica [mailto:dan.zulaica...@gmail.com]
>>> >> Sent: Wednesday, April 18, 2018 12:29
>>> >> To: Kirsher, Jeffrey T <jeffrey.t.kirs...@intel.com>
>>> >> Cc: e1000-devel@lists.sourceforge.net
>>> >> Subject: Re: [E1000-devel] e1000 driver compile
>>> >>
>>> >> Hi,
>>> >> This is an older Dell latitude laptop. I see on Ethernet and one 
>>> >> Network controller line using lspci.
>>> >>
>>> >> 00:19.0 Ethernet controller: Intel Corporation Device 1502 
>>> >> (rev
>>> >> 04)
>>> >>
>>> >> 02:00.0 Network controller: Broadcom Corporati

Re: [E1000-devel] e1000 driver compile

[Fujinaka, Todd]

First, you really haven't shown us any of the error messages you're getting. 
Second, you really do need the kernel headers for your version of the kernel.

When you install the kernel headers, you should've done something like "apt 
install linux-headers-`uname -r`" (everything within the quotes) and something 
similar for the extras.

Cut-and-paste the errors (remember to paste them all) and maybe even file a bug 
and attach your whole dmesg if there's a run-time issue.

Todd Fujinaka
Software Application Engineer
Datacenter Engineering Group
Intel Corporation
todd.fujin...@intel.com

-Original Message-
From: Dan Zulaica [mailto:dan.zulaica...@gmail.com] 
Sent: Wednesday, April 18, 2018 11:55 PM
To: Kirsher, Jeffrey T 
Cc: e1000-devel@lists.sourceforge.net
Subject: Re: [E1000-devel] e1000 driver compile

Well,

There are 'invalid module format' errors trying to install the re-compile .ko 
files from '2.6.32.24'. Is there a version mis-match?
If so how do I configure for generic and can I change the version? I need 
version '2.6.32-24-generic'. If that is the problem. I guess I could try to 
force the install.

Any ideas?
Dan


On Thu, Apr 19, 2018 at 12:16 AM, Dan Zulaica  wrote:
> Hi Jeffrey,
>
> I finally found the version.h and autoconf.h files in the 
> include/linux directory. This was after creating the kernel .config 
> file and re-compiling the entire kernel and modules. I will try the 
> included modules and if still do not work, will compile the separate 
> downloaded modules from sourceforge that you gave me earlier.
>
> Thanks for the help!
> Dan
>
>
> On Wed, Apr 18, 2018 at 2:49 PM, Kirsher, Jeffrey T 
>  wrote:
>>> -Original Message-
>>> From: Dan Zulaica [mailto:dan.zulaica...@gmail.com]
>>> Sent: Wednesday, April 18, 2018 12:43
>>> To: Kirsher, Jeffrey T 
>>> Cc: e1000-devel@lists.sourceforge.net
>>> Subject: Re: [E1000-devel] e1000 driver compile
>>>
>>> Great,
>>>
>>> I thought I at least had the linux headers, though no autoconf.h file.
>>> Are you saying I should download more than the headers?
>>
>> In Ubuntu (or Kubuntu), there are 2 kernel header packages that you need to 
>> install, they are linux-headers- and linux-headers-> version>-generic.  After installing both, if you still do not have a 
>> autoconf.h file, then you will need to download the entire kernel source.
>>
>> It is also recommended (by Ubuntu) to install the build-essentials package.
>>
>>>
>>> On Wed, Apr 18, 2018 at 1:39 PM, Kirsher, Jeffrey T 
>>>  wrote:
>>> > The Intel 1502 device id is the  82579LM Gigabit Network 
>>> > Connection,
>>> which is supported by the e1000e driver.  You can download the 
>>> e1000e driver from sourceforge.net:
>>> > https://sourceforge.net/projects/e1000/files/e1000e%20stable/
>>> >
>>> > Latest version is 3.4.0.2 and should compile just fine on your 
>>> > kernel, you
>>> just need to make sure you have the Linux kernel source installed.
>>> >
>>> > The Broadcom device is your wireless adapter.
>>> >
>>> >> -Original Message-
>>> >> From: Dan Zulaica [mailto:dan.zulaica...@gmail.com]
>>> >> Sent: Wednesday, April 18, 2018 12:29
>>> >> To: Kirsher, Jeffrey T 
>>> >> Cc: e1000-devel@lists.sourceforge.net
>>> >> Subject: Re: [E1000-devel] e1000 driver compile
>>> >>
>>> >> Hi,
>>> >> This is an older Dell latitude laptop. I see on Ethernet and one 
>>> >> Network controller line using lspci.
>>> >>
>>> >> 00:19.0 Ethernet controller: Intel Corporation Device 1502 
>>> >> (rev
>>> >> 04)
>>> >>
>>> >> 02:00.0 Network controller: Broadcom Corporation Device 4727 
>>> >> (rev
>>> >> 01)
>>> >>
>>> >> I have tried 'modprobe e1000.ko' and also for e1000e.ko and no 
>>> >> return messages.
>>> >>
>>> >> 'ifconfig -a' only shows 'lo'.
>>> >>
>>> >> Thanks for the help,
>>> >> Dan
>>> >>
>>> >>
>>> >> On Wed, Apr 18, 2018 at 1:15 PM, Kirsher, Jeffrey T 
>>> >>  wrote:
>>> >> >> -Original Message-
>>> >> >> From: Dan Zulaica [mailto:dan.zulaica...@gmail.com]
>>> >> >> Sent: Wednesday, April 18, 2018 10:24
>>> >> >> To: e1000-devel@lists.sourceforge.net
>>> >> >> Subject: [E1000-devel] e1000 driver compile
>>> >> >>
>>> >> >> Hi,
>>> >> >>
>>> >> >> I have Kubuntu with kernel version 2.6.32-24-generic on a Dell 
>>> >> >> Latitude laptop that has Intel Pro/100 network adapter. E1000 
>>> >> >> is said to be the driver that needs to be re-compiled, however 
>>> >> >> I cannot re-compile it. Trying an E100 compile says it is no 
>>> >> >> longer supported after
>>> >> OS 2.4.
>>> >> >
>>> >> > The in-kernel driver for e1000 will be the most up-to-date driver.
>>> >> > The out-
>>> >> of-tree (OOT) driver on sourceforge will be older than what is in 
>>> >> that particular kernel.  Are you sure you need the e1000 driver?  
>>> >> You might need the e1000e 

Re: [E1000-devel] igb changelog

[Fujinaka, Todd]

There really aren't any intermediate versions available nor more changelogs.

I'd just download both and diff them, but for the most part all I've been 
updating is the compat code to allow for compilation on newer kernels. For new 
features you really should be using the in-kernel igb driver.

Todd Fujinaka
Software Application Engineer
Datacenter Engineering Group
Intel Corporation
todd.fujin...@intel.com


-Original Message-
From: Luis Valezquez [mailto:l...@netactuate.com] 
Sent: Wednesday, April 18, 2018 12:20 PM
To: e1000-devel@lists.sourceforge.net
Subject: [E1000-devel] igb changelog

Hello,

I am trying to compare differences in igb driver version 5.3.5.12 and
5.3.5.15

I don't see the intermediate versions available online - could someone point me 
in the right direction to find revision history / changelogs between all 
versions?



Best regards,

Luis
--
Check out the vibrant tech community on one of the world's most engaging tech 
sites, Slashdot.org! http://sdm.link/slashdot 
___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
http://communities.intel.com/community/wired

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
http://communities.intel.com/community/wired

Re: [E1000-devel] How to reach you from Intel internally?

[Fujinaka, Todd]

I responded to him personally, but for anyone else who is curious you can check 
older emails and see who has an Intel email address and has been responding to 
igb questions.

Basically the answer is what I want to give most people: GIYF.

Todd Fujinaka
Software Application Engineer
Datacenter Engineering Group
Intel Corporation
todd.fujin...@intel.com


-Original Message-
From: Zhang, Baoli [mailto:baoli.zh...@intel.com] 
Sent: Wednesday, April 4, 2018 1:46 AM
To: e1000-devel@lists.sourceforge.net
Subject: [E1000-devel] How to reach you from Intel internally?

HI igb development team,

This is Baoli also from intel, how to reach you internally? Thanks.

BR/Baoli
--
Check out the vibrant tech community on one of the world's most engaging tech 
sites, Slashdot.org! http://sdm.link/slashdot 
___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
http://communities.intel.com/community/wired

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
http://communities.intel.com/community/wired

Re: [E1000-devel] 1000Gb without auto-negotiation

[Fujinaka, Todd]

It's more about official support. This mailing list will not get you the best 
support if you're working on a product. It sounds like you could be working on 
a college project and if that's the case the issue could get less than optimal 
attention.

Todd Fujinaka
Software Application Engineer
Datacenter Engineering Group
Intel Corporation
todd.fujin...@intel.com


-Original Message-
From: Ran Shalit [mailto:ransha...@gmail.com] 
Sent: Tuesday, March 27, 2018 3:02 PM
To: Fujinaka, Todd <todd.fujin...@intel.com>
Cc: e1000-devel@lists.sourceforge.net
Subject: Re: [E1000-devel] 1000Gb without auto-negotiation

On Tue, Mar 27, 2018 at 11:09 PM, Fujinaka, Todd <todd.fujin...@intel.com> 
wrote:
> Is this just a science experiment or is this for an actual product?
>
> If this is for an actual product, you should use your factory contact to get 
> a customized NVM for your part or write a custom driver. Putting ethtool in 
> your init scripts sounds fragile at best.
>
> Please file an IPS through your factory contact if this is a serious effort.
>

Hello Todd,

Can you please explain why another customized NVM shall make the difference in 
boot time till ping ?
Isn't it depends on driver input/params ? Can't it be done in code ?

Thank you very much,
Ranran


> Todd Fujinaka
> Software Application Engineer
> Datacenter Engineering Group
> Intel Corporation
> todd.fujin...@intel.com
>
>
> -Original Message-
> From: Ran Shalit [mailto:ransha...@gmail.com]
> Sent: Tuesday, March 27, 2018 11:37 AM
> To: Fujinaka, Todd <todd.fujin...@intel.com>
> Cc: e1000-devel@lists.sourceforge.net
> Subject: Re: [E1000-devel] 1000Gb without auto-negotiation
>
> On Tue, Mar 27, 2018 at 8:44 PM, Fujinaka, Todd <todd.fujin...@intel.com> 
> wrote:
>> What did you try and what to you want to do?
>>
>
> I try to use ethtool (in init.d scripts) to turn auto-negotiation off and 
> force 1G. I now understand from your answer that it can't work with igb.
>
> My end goal is to reduce boot time till ping success, but I still have long 
> interval from time of igb probe till ping success.
> I tried many many methods but nothing helped too much, only if I remove 
> auto-negotiation to 100M, I got ~1.5 second less time till link is up, but we 
> probably can't use 100M, because we must work with 1Gb.
>
> I first got 3 seconds from igb init till link up (we can name it 1st 
> interval), and 3 seconds from link up till ping success(let's name it 2nd 
> interval).
>
> After initialization of ip in bootargs (ip=...) instead of using ifup in 
> init.d, and using static arp, I got ~100msec from link up till ping.
> Yet, I'm not sure what actual made it less. when removed arp it was still 
> short.
>
> 1. Why initialization of ip at start reduced the 1st interval (from init till 
> link is up) ?
>
> I also don't understand yet why it takes to much time till igb get link is up 
> (1st interval).
> It also seems that IGB disable/enable or power down itself (I see that led of 
> phy is turned off during boot) Trying to return from power down (without 
> doing anything) and from phy reset did not help, or made it non-functional at 
> all.
>
> 2. How to disable this power down\phy down issue during boot ?
>
> These are the function I catch when adding log of function call:
>
>
> [1.897306]  igb_init_module
> [1.897309] igb: Intel(R) Gigabit Ethernet Network Driver << -
> version 5.4.0-k
> [1.897310] igb: Copyright (c) 2007-2014 Intel Corporation. <<
> [1.897338]  igb_probe
> [1.897728]  igb_sw_init
> [1.908895]  igb_reset
> [1.923042]  igb_power_down_link
> [1.926740]  Starting network:
> [1.944956]  __igb_open
> [1.945005]  igb_power_up_link
> [5.043281] igb :03:00.0 eth0: igb: eth0 NIC Link is Up 1000
> Mbps Full Duplex, Flow Control: RX
> [7.966910]  ping ack success
>
> 3. Is there a way to investigate where igb waits for or spends time till link 
> is up ?
>
>
>> You can't turn off auto-negotiation on 1G (as per the 1G spec), but you can 
>> limit what you advertise.
>>
>> Todd Fujinaka
>
> Thank you very much,
> ranran
>
>> Software Application Engineer
>> Datacenter Engineering Group
>> Intel Corporation
>> todd.fujin...@intel.com
>>
>>
>> -Original Message-
>> From: Ran Shalit [mailto:ransha...@gmail.com]
>> Sent: Tuesday, March 27, 2018 12:09 AM
>> To: e1000-devel@lists.sourceforge.net
>> Subject: [E1000-devel] 1000Gb without auto-negotiation
>>
>> Hello,
>>
>>
>> I try to set igb driver without autonegotiation in 1Gb, but it does not 
>> seems to work, (with etht

Re: [E1000-devel] 1000Gb without auto-negotiation

[Fujinaka, Todd]

Is this just a science experiment or is this for an actual product?

If this is for an actual product, you should use your factory contact to get a 
customized NVM for your part or write a custom driver. Putting ethtool in your 
init scripts sounds fragile at best.

Please file an IPS through your factory contact if this is a serious effort.

Todd Fujinaka
Software Application Engineer
Datacenter Engineering Group
Intel Corporation
todd.fujin...@intel.com


-Original Message-
From: Ran Shalit [mailto:ransha...@gmail.com] 
Sent: Tuesday, March 27, 2018 11:37 AM
To: Fujinaka, Todd <todd.fujin...@intel.com>
Cc: e1000-devel@lists.sourceforge.net
Subject: Re: [E1000-devel] 1000Gb without auto-negotiation

On Tue, Mar 27, 2018 at 8:44 PM, Fujinaka, Todd <todd.fujin...@intel.com> wrote:
> What did you try and what to you want to do?
>

I try to use ethtool (in init.d scripts) to turn auto-negotiation off and force 
1G. I now understand from your answer that it can't work with igb.

My end goal is to reduce boot time till ping success, but I still have long 
interval from time of igb probe till ping success.
I tried many many methods but nothing helped too much, only if I remove 
auto-negotiation to 100M, I got ~1.5 second less time till link is up, but we 
probably can't use 100M, because we must work with 1Gb.

I first got 3 seconds from igb init till link up (we can name it 1st interval), 
and 3 seconds from link up till ping success(let's name it 2nd interval).

After initialization of ip in bootargs (ip=...) instead of using ifup in 
init.d, and using static arp, I got ~100msec from link up till ping.
Yet, I'm not sure what actual made it less. when removed arp it was still short.

1. Why initialization of ip at start reduced the 1st interval (from init till 
link is up) ?

I also don't understand yet why it takes to much time till igb get link is up 
(1st interval).
It also seems that IGB disable/enable or power down itself (I see that led of 
phy is turned off during boot) Trying to return from power down (without doing 
anything) and from phy reset did not help, or made it non-functional at all.

2. How to disable this power down\phy down issue during boot ?

These are the function I catch when adding log of function call:


[1.897306]  igb_init_module
[1.897309] igb: Intel(R) Gigabit Ethernet Network Driver << -
version 5.4.0-k
[1.897310] igb: Copyright (c) 2007-2014 Intel Corporation. <<
[1.897338]  igb_probe
[1.897728]  igb_sw_init
[1.908895]  igb_reset
[1.923042]  igb_power_down_link
[1.926740]  Starting network:
[1.944956]  __igb_open
[1.945005]  igb_power_up_link
[5.043281] igb :03:00.0 eth0: igb: eth0 NIC Link is Up 1000
Mbps Full Duplex, Flow Control: RX
[7.966910]  ping ack success

3. Is there a way to investigate where igb waits for or spends time till link 
is up ?


> You can't turn off auto-negotiation on 1G (as per the 1G spec), but you can 
> limit what you advertise.
>
> Todd Fujinaka

Thank you very much,
ranran

> Software Application Engineer
> Datacenter Engineering Group
> Intel Corporation
> todd.fujin...@intel.com
>
>
> -Original Message-
> From: Ran Shalit [mailto:ransha...@gmail.com]
> Sent: Tuesday, March 27, 2018 12:09 AM
> To: e1000-devel@lists.sourceforge.net
> Subject: [E1000-devel] 1000Gb without auto-negotiation
>
> Hello,
>
>
> I try to set igb driver without autonegotiation in 1Gb, but it does not seems 
> to work, (with ethtool or directly in driver).
>
> Isn't it supported ?
>
> Regards,
> ranran
>
> --
>  Check out the vibrant tech community on one of the world's 
> most engaging tech sites, Slashdot.org! http://sdm.link/slashdot 
> ___
> E1000-devel mailing list
> E1000-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/e1000-devel
> To learn more about Intel Ethernet, visit 
> http://communities.intel.com/community/wired
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
http://communities.intel.com/community/wired

Re: [E1000-devel] 1000Gb without auto-negotiation

[Fujinaka, Todd]

What did you try and what to you want to do?

You can't turn off autonegotiation on 1G (as per the 1G spec), but you can 
limit what you advertise.

Todd Fujinaka
Software Application Engineer
Datacenter Engineering Group
Intel Corporation
todd.fujin...@intel.com


-Original Message-
From: Ran Shalit [mailto:ransha...@gmail.com] 
Sent: Tuesday, March 27, 2018 12:09 AM
To: e1000-devel@lists.sourceforge.net
Subject: [E1000-devel] 1000Gb without auto-negotiation

Hello,


I try to set igb driver without autonegotiation in 1Gb, but it does not seems 
to work, (with ethtool or directly in driver).

Isn't it supported ?

Regards,
ranran

--
Check out the vibrant tech community on one of the world's most engaging tech 
sites, Slashdot.org! http://sdm.link/slashdot 
___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
http://communities.intel.com/community/wired

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
http://communities.intel.com/community/wired

Re: [E1000-devel] Intel i210 IT NIC card support on ARM platform

[Fujinaka, Todd]

You really need to ask the OpenAVNU guys on their mailing list.

We don't have a lot of ARM platforms here so I'd suggest asking someone outside 
of Intel.

Todd Fujinaka
Software Application Engineer
Datacenter Engineering Group
Intel Corporation
todd.fujin...@intel.com

-Original Message-
From: UR RAHMAN, RIYAZ (R.) [mailto:ri...@allgosystems.com] 
Sent: Tuesday, March 20, 2018 12:52 AM
To: e1000-devel@lists.sourceforge.net
Subject: [E1000-devel] Intel i210 IT NIC card support on ARM platform

Hi,



I am trying to work with intel i210 IT NIC interface card on ARM platform for 
AVB development using modified IGB AVB driver provided by OpenAvnu.

This card is working fine on Linux based PC with modified IGB AVB driver 
provided by OpenAvnu community. This card has PCIe x1 connecting interface.

Please find the below link for more product description.



Please find the link to modified IGB AVB driver maintained by OpenAvnu.

https://github.com/AVnu/OpenAvnu/tree/master/kmod/igb




I wanted to know whether this NIC card with IGB AVB driver compatible on ARM 
platform?

Whether this driver is architecture dependent works only on X86 arch. Basic 
ping functionality is also not working with modified driver on ARM platform.



Please find the below link of product:

https://www.amazon.in/Intel-I210-T1-PCI-Express-Ethernet-Desktop/dp/B07121WCKJ


Best Regards,

Riyaz
--
Check out the vibrant tech community on one of the world's most engaging tech 
sites, Slashdot.org! http://sdm.link/slashdot 
___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
http://communities.intel.com/community/wired

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
http://communities.intel.com/community/wired

Re: [E1000-devel] igb transmit queue timeout

[Fujinaka, Todd]

There's really not enough information here. Ideally you would send us the dmesg 
of when it fails, and a register dump before and after.

I would suggest opening on bug on sourceforge and attaching the dmesg & 
register dumps to the bug. Don't just copy them into the bug because that's 
much harder to read.

We haven't heard of many issues with the 82576 like this, so you may also want 
to ask Supermicro for help, but it also looks like your hardware is EOL.

Todd Fujinaka
Software Application Engineer
Datacenter Engineering Group
Intel Corporation
todd.fujin...@intel.com


-Original Message-
From: Kojedzinszky Richárd [mailto:kojedzinszky.rich...@euronetrt.hu] 
Sent: Wednesday, January 24, 2018 1:44 AM
To: e1000-devel@lists.sourceforge.net
Subject: [E1000-devel] igb transmit queue timeout

Dear maintainers,

We have a xen virtualization environment, with 6 nearly identical nodes, 
Supermicro X8DTU boards.

We run debian stretch on them, the xen hypervisor and linux kernel is from 
debian stretch, latest at the time of writing.

Unfortunately, we are facing an issue where randomly our igb devices stop 
working, with the error message:

NETDEV WATCHDOG: enp1s0f0 (igb): transmit queue 0 timed out

And while the driver tries to recover/reset the adapter, it does not succeed. 
Shutting down the interface and then bringing it back even does not help, a 
reboot is required to restore normal operation.

The servers are connected to our switch with two interfaces, the problem 
happens randomly on either one.

We have tried to disable msi interrupts, but that did not help.

Unfortunately, we cannot reproduce the problem, I mean it happens randomly, 
frequently, but we cannot explicitly trigger it. It did happen on nearly all 
our nodes, so I assume it is not a hardware problem.

Our kernel/xen versions:

# uname -a
Linux node-3.cloud-b.dravanet.net 4.9.0-5-amd64 #1 SMP Debian
4.9.65-3+deb9u2 (2018-01-04) x86_64 GNU/Linux # xl info
host   : x
release: 4.9.0-5-amd64
version: #1 SMP Debian 4.9.65-3+deb9u2 (2018-01-04)
machine: x86_64
nr_cpus: 8
max_cpu_id : 23
nr_nodes   : 2
cores_per_socket   : 4
threads_per_core   : 1
cpu_mhz: 3066
hw_caps: 
b7ebfbff:029ee3ff:2c100800:0001::::0100
virt_caps  : hvm hvm_directio
total_memory   : 196599
free_memory: 94364
sharing_freed_memory   : 0
sharing_used_memory: 0
outstanding_claims : 0
free_cpus  : 0
xen_major  : 4
xen_minor  : 8
xen_extra  : .3-pre
xen_version: 4.8.3-pre
xen_caps   : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 
hvm-3.0-x86_32p hvm-3.0-x86_64
xen_scheduler  : credit
xen_pagesize   : 4096
platform_params: virt_start=0x8000
xen_changeset  :
xen_commandline: placeholder dom0_mem=4096M gnttab_max_frames=256
cc_compiler: gcc (Debian 6.3.0-18) 6.3.0 20170516
cc_compile_by  : ijackson
cc_compile_domain  : chiark.greenend.org.uk
cc_compile_date: Sat Nov 25 11:30:34 UTC 2017
build_id   : 23ac95af74d2e3f84c90068ae674c34e764649e7
xend_config_format : 4

What else could we try to resolve this issue?

Thanks in advance,

Kojedzinszky Richárd
Euronet Magyarorszag Informatika Zrt.
--
Check out the vibrant tech community on one of the world's most engaging tech 
sites, Slashdot.org! http://sdm.link/slashdot 
___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
http://communities.intel.com/community/wired

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
http://communities.intel.com/community/wired

Re: [E1000-devel] Linux ixgbe driver

[Fujinaka, Todd]

I am unfamiliar with LEDE. If it's a distro, I would suggest asking the distro.

We generally just suggest:
tar xvzf ixgbe-5.3.5.tar.gz
cd ixgbe-5.3.5/src
make
make install

Please read the README in the tarball for more help.

Todd Fujinaka
Software Application Engineer
Datacenter Engineering Group
Intel Corporation
todd.fujin...@intel.com


-Original Message-
From: 朱翔 [mailto:2430336...@qq.com] 
Sent: Friday, January 19, 2018 8:22 PM
To: e1000-devel 
Subject: [E1000-devel] Linux ixgbe driver

Hello，


I want to compile and install ixgbe on LEDE X86-64 recently. after cross 
compiling, i got a directory named ipkg-x86_64 in build_dir ,there is three 
file named control, postinst and prerm under this directory. Iwant to know how 
to istall is on LEDE.  I would be grateful if I could get some help.




Thanks.
--
Check out the vibrant tech community on one of the world's most engaging tech 
sites, Slashdot.org! http://sdm.link/slashdot 
___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
http://communities.intel.com/community/wired

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
http://communities.intel.com/community/wired

Re: [E1000-devel] Linux ixgbe driver

[Fujinaka, Todd]

"modprobe dca" would be the first thing to try.

Todd Fujinaka
Software Application Engineer
Datacenter Engineering Group
Intel Corporation
todd.fujin...@intel.com


-Original Message-
From: 朱翔 [mailto:2430336...@qq.com] 
Sent: Friday, January 19, 2018 10:34 PM
To: e1000-devel 
Subject: [E1000-devel] Linux ixgbe driver

Hello，


when i excute the command ‘modprobe ixgbe’, i got the error like this：failed to 
find depencdependency dca，what should i do？


Thanks.
--
Check out the vibrant tech community on one of the world's most engaging tech 
sites, Slashdot.org! http://sdm.link/slashdot 
___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
http://communities.intel.com/community/wired

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
http://communities.intel.com/community/wired

Re: [E1000-devel] Corrupted NVM on i40e BIOS update

[Fujinaka, Todd]

You should contact your FAE, as that is the official support channel. The FAE 
and official support will have more options than we can provide on a mailing 
list.

Todd Fujinaka
Software Application Engineer
Datacenter Engineering Group
Intel Corporation
todd.fujin...@intel.com


-Original Message-
From: Rizer, Dave [mailto:dave.ri...@netapp.com] 
Sent: Friday, January 12, 2018 4:48 PM
To: e1000-de...@lists.sf.net
Subject: [E1000-devel] Corrupted NVM on i40e BIOS update

Hello,


I've got a few systems that now show a MAC address of all zeros and a 03.14 and 
03.15 address on the ports respectively.


I've had a conversation with PJ and he recommended I contact this list.  We 
dumped the permanent MAC address from the host, plus looked at the MAC address 
from a preboot environment, and verified this is the same.  It looks like the 
recent BIOS update corrupted the NVM on the NIC.  We need support on how to 
rewrite the NVM, or recover it if possible.  We do have the old MAC addresses 
that they should be, just need guidance on next steps to recover.


Regards,

Dave
--
Check out the vibrant tech community on one of the world's most engaging tech 
sites, Slashdot.org! http://sdm.link/slashdot 
___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
http://communities.intel.com/community/wired

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
http://communities.intel.com/community/wired

Re: [E1000-devel] Questions about merging commits to kernel

[Fujinaka, Todd]

All our work goes into the newer kernels. When is the question, and we're 
always submitting to mainline and do our development and test there.

As for backports, it was suggested to me that I tell you to go to the netdev 
mailing list and ask Dave Miller to submit it to stable. From there the 
individual stable tree maintainers can pull it.

Netdev has rules and is a very high volume mailing list and so I also strongly 
suggest that you do some research before you post to that list.

Todd Fujinaka
Software Application Engineer
Datacenter Engineering Group
Intel Corporation
todd.fujin...@intel.com


-Original Message-
From: Pavlos Parissis [mailto:pavlos.paris...@gmail.com] 
Sent: Thursday, January 11, 2018 2:19 PM
To: Fujinaka, Todd <todd.fujin...@intel.com>; e1000-devel@lists.sourceforge.net
Subject: Re: [E1000-devel] Questions about merging commits to kernel

On 11/01/2018 10:40 μμ, Fujinaka, Todd wrote:
> No, not the i40e driver, the maintainer of stable kernels. Start here: 
> https://www.kernel.org/doc/linux/MAINTAINERS
> 

I thought you meant the maintainer of the driver. As far as I know and learned 
by reading various kernel mailing lists the process goes like this:

The maintainer of a subsystem (netdev for instance) receives commits from 
developers working on the subsystem and he is one of the main persons to 
request inclusion of commits to stable trees. The individual developers can 
also request inclusion. If those commits don't apply cleanly on stable kernels 
then either the commiter or maintainer has to backport those commits.

I only asked the question in my effort to find out if kernel version 4.9 will 
receive fixes that has been mentioned here for i40e driver.

Thanks for getting back to me,
Pavlos

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
http://communities.intel.com/community/wired

Re: [E1000-devel] Questions about merging commits to kernel

[Fujinaka, Todd]

No, not the i40e driver, the maintainer of stable kernels. Start here: 
https://www.kernel.org/doc/linux/MAINTAINERS 

Looks like it's Greg K-H but please read the documentation before you start 
emailing him.

Todd Fujinaka
Software Application Engineer
Datacenter Engineering Group
Intel Corporation
todd.fujin...@intel.com


-Original Message-
From: Pavlos Parissis [mailto:pavlos.paris...@gmail.com] 
Sent: Thursday, January 11, 2018 1:15 PM
To: Fujinaka, Todd <todd.fujin...@intel.com>; e1000-devel@lists.sourceforge.net
Subject: Re: [E1000-devel] Questions about merging commits to kernel

On 11/01/2018 09:46 μμ, Fujinaka, Todd wrote:
> All these commits go through David Miller to Linus's tree. I'm not sure where 
> the documentation is. I'd start with kernel.org or google for it.
> 

I will do another google round, may be I am lucky this time.

> As for pullups to the stable trees, you should ask the maintainer to pull 
> patches you think are necessary.
> 

Who is the maintainer of i40e driver?

Cheers,
Pavlos
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
http://communities.intel.com/community/wired

Re: [E1000-devel] Setting MTU doesn't work in igb

[Fujinaka, Todd]

Why are you compiling igb? The one in the kernel is much more up-to-date than 
the standalone driver.

Todd Fujinaka
Software Application Engineer
Datacenter Engineering Group
Intel Corporation
todd.fujin...@intel.com


-Original Message-
From: Dmitry Ivanov [mailto:von...@gmail.com] 
Sent: Thursday, January 11, 2018 10:17 AM
To: e1000-devel@lists.sourceforge.net
Subject: [E1000-devel] Setting MTU doesn't work in igb

Hi,

I compiled igb for kernel 4.13 and noticed that setting MTU doesn't work as 
expected. I think it has been broken since introducing 
HAVE_NETDEVICE_MIN_MAX_MTU. The attached patch fixes things for me.

--
Best regards,
Dmitry Ivanov

A: Because it breaks the logical sequence of discussion
Q: Why is top posting bad?
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
http://communities.intel.com/community/wired

Re: [E1000-devel] Questions about merging commits to kernel

[Fujinaka, Todd]

All these commits go through David Miller to Linus's tree. I'm not sure where 
the documentation is. I'd start with kernel.org or google for it.

As for pullups to the stable trees, you should ask the maintainer to pull 
patches you think are necessary.

Todd Fujinaka
Software Application Engineer
Datacenter Engineering Group
Intel Corporation
todd.fujin...@intel.com

-Original Message-
From: Pavlos Parissis [mailto:pavlos.paris...@gmail.com] 
Sent: Wednesday, January 10, 2018 7:28 AM
To: e1000-devel@lists.sourceforge.net
Subject: [E1000-devel] Questions about merging commits to kernel

Hi,

I have been following this list for some time and I see a lot of commits with 
improvements and bug fixes and I would like to know if those commits are pushed 
to Linus's tree and more particular to stable trees.


What is the current policy of back porting fixes to LTS kernels?
When I look at linux-4.9 kernel for i40e dirver,  I see last commit from Mar 24
(661f5348696a39ace18fcc028513ef7527a036e3 - i40e: Do not enable NAPI on 
q_vectors that have no rings), while there have been a lot of work done since 
then on i40e driver.

Thanks in advance,
Pavlos


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
http://communities.intel.com/community/wired

Re: [E1000-devel] Instability of i40e driver on 4.9 kernel

[Fujinaka, Todd]

Sorry I missed this, but the answer I provided is still the same: you need to 
contact HPE directly about their hardware configuration of the part. They buy 
the Ethernet controller from Intel, but they have a unique configuration that 
allows them to differentiate their platform from others. You can't override 
their configurations without voiding their warranty and any support contract 
you have with them.

Todd Fujinaka
Software Application Engineer
Datacenter Engineering Group
Intel Corporation
todd.fujin...@intel.com

-Original Message-
From: Pavlos Parissis [mailto:pavlos.paris...@gmail.com] 
Sent: Friday, January 5, 2018 6:53 AM
To: Fujinaka, Todd <todd.fujin...@intel.com>; e1000-devel@lists.sourceforge.net
Subject: Re: [E1000-devel] Instability of i40e driver on 4.9 kernel

On 4 November 2017 at 13:56, Pavlos Parissis <pavlos.paris...@gmail.com> wrote:
> On 26/10/2017 11:14 μμ, Pavlos Parissis wrote:
>> On 26/10/2017 11:01 μμ, Fujinaka, Todd wrote:
>>> So let me back off that statement a little bit - the driver hands 
>>> off a lot of requests to the firmware.
>>>
>>> I've had several people look at this issue and it could be because 
>>> there's LLDP going on in the firmware that might need to be turned 
>>> off. Unfortunately, that's something that might be controlled by 
>>> HPe's configuration, and may or may not be an approved HPe 
>>> configuration. For that reason, you will have to go to HPe for confirmation 
>>> and for initial support.
>>
>> LLDP was turned off as we run lldpd daemon on our servers.
>>
>> Those servers run Bird (Internet Router daemon) for establishing BGP 
>> peering with upstream switches and we need lldp packets to arrive on 
>> the host as we use them for operation tasks. After the switch to this 
>> card, we found out that our tools stopped working and after few hours 
>> of troubleshooting we realized that lldp packets weren't arriving on the 
>> host, thus we turned off LLDP on the card by running:
>> ( for command in /sys/kernel/debug/i40e/*/command; do echo "lldp 
>> stop" > ${command}; done ) 2>/dev/null
>>
>> before the start of lldpd daemon, here is the output of lldpctl, 
>> which implies that LLDP is turned off in the firmware:
>>
>> sudo lldpctl eth0
>> -
>> --
>> LLDP neighbors:
>> ---
>> Interface:eth0, via: LLDP, RID: 2, Time: 41 days, 02:38:18
>>   Chassis:
>> ChassisID:mac 28:99:3a:50:05:e9
>> SysName:  foobar.com
>> SysDescr: Arista Networks EOS version 4.18.4F running on an Arista
>> Networks DCS-7050SX-64
>> MgmtIP:   x.x.x.x <<-- Replaced real IP
>> Capability:   Bridge, on
>> Capability:   Router, on
>>   Port:
>> PortID:   ifname Ethernet3
>> PortDescr:Not received
>> MFS:  9236
>>   VLAN: 6, pvid: yes
>> -
>> --
>>
>>
>>
>> Thanks for the update, any assistance it is very much appreciated.
>>
>> Cheers,
>> Pavlos
>>
>
>
> Do you have any update about this issue?
>
> Cheers,
> Pavlos
>


Any updates? Has anyone looked at the above problem?

Cheers,
Pavlos
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
http://communities.intel.com/community/wired

Re: [E1000-devel] BUG when unplugging I210 Ethernet controller

[Fujinaka, Todd]

I think there's a fix for this in the queue from RedHat. You can see it on the 
intel-wired-lan mailing list but I don' think it's been pulled into our tree 
yet.

Todd Fujinaka
Software Application Engineer
Datacenter Engineering Group
Intel Corporation
todd.fujin...@intel.com


-Original Message-
From: Matan Peled [mailto:chaos...@gmail.com] 
Sent: Thursday, December 14, 2017 7:36 AM
To: e1000-devel@lists.sourceforge.net
Subject: [E1000-devel] BUG when unplugging I210 Ethernet controller

Hi list,

I own a CalDigit TS3 docking station that contains among other things a
I210 Ethernet controller. This device is connected using Thunderbolt 3. I use 
the igb module to drive it.

Relevant line from lspci:
07:00.0 Ethernet controller: Intel Corporation I210 Gigabit Network Connection 
(rev 03)

The device works fine, but when unplugging the cord, I get a kernel BUG and my 
system freezes. It looks like this (sorry that I can't get a text
version):
https://i.imgur.com/87mRlMG.jpg

Manually removing the igb module (modprobe -r igb) before I disconnect the 
device works around the issue. I can then reconnect the device, insert the 
module, and it works fine.

This is a 2015 Razer Blade Stealth running Debian Unstable, kernel 4.14.2.

Thanks in advance!
 - Matan
--
Check out the vibrant tech community on one of the world's most engaging tech 
sites, Slashdot.org! http://sdm.link/slashdot 
___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
http://communities.intel.com/community/wired

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
http://communities.intel.com/community/wired

Re: [E1000-devel] Instability of i40e driver on 4.9 kernel

[Fujinaka, Todd]

So let me back off that statement a little bit - the driver hands off a lot of 
requests to the firmware.

I've had several people look at this issue and it could be because there's LLDP 
going on in the firmware that might need to be turned off. Unfortunately, 
that's something that might be controlled by HPe's configuration, and may or 
may not be an approved HPe configuration. For that reason, you will have to go 
to HPe for confirmation and for initial support.

Todd Fujinaka
Software Application Engineer
Datacenter Engineering Group
Intel Corporation
todd.fujin...@intel.com


-Original Message-
From: Pavlos Parissis [mailto:pavlos.paris...@gmail.com] 
Sent: Thursday, October 26, 2017 5:55 AM
To: Fujinaka, Todd <todd.fujin...@intel.com>; e1000-devel@lists.sourceforge.net
Subject: Re: [E1000-devel] Instability of i40e driver on 4.9 kernel

On 26/10/2017 01:29 πμ, Fujinaka, Todd wrote:
> We will be looking into the issue, but I'm just letting you know the 
> process of how to file bugs and get fixes most quickly.
> 
> Also, the X710 is our first product (of many) that has much of the 
> functionality in the firmware.
> You need to update them both and the driver just hands off requests to the 
> firmware.
> 

Good to know that.

Cheers,
Pavlos

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
http://communities.intel.com/community/wired

Re: [E1000-devel] Instability of i40e driver on 4.9 kernel

[Fujinaka, Todd]

We will be looking into the issue, but I'm just letting you know the process of 
how to file bugs and get fixes most quickly.

Also, the X710 is our first product (of many) that has much of the 
functionality in the firmware. You need to update them both and the driver just 
hands off requests to the firmware.

Todd Fujinaka
Software Application Engineer
Datacenter Engineering Group
Intel Corporation
todd.fujin...@intel.com


-Original Message-
From: Pavlos Parissis [mailto:pavlos.paris...@gmail.com] 
Sent: Wednesday, October 25, 2017 3:32 PM
To: Fujinaka, Todd <todd.fujin...@intel.com>; e1000-devel@lists.sourceforge.net
Subject: Re: [E1000-devel] Instability of i40e driver on 4.9 kernel

On 26/10/2017 12:13 πμ, Fujinaka, Todd wrote:
> This is just about the last part of your post, about the 4.9 kernel 
> and CentOS.
> 
> Are you using the stable 4.9 kernel or are you hoping patches get 
> pulled into the CentOS 4.9 kernel?

We use vanilla kernel without any patches.

> If it's the latter, you need to file a bug with Red Hat to have the 
> patches pulled into RHEL, and then CentOS should get those changes as 
> well. We have no direct control on the RHEL/CentOS kernels.
> 
> If it's the former, someone (most likely you, since you're the one who 
> needs the patches) has to identify the patches that should be pulled 
> into the stable
> 4.9 kernel and email the maintainer of the stable kernels.
> 

Is anyone planning to look at the errors messages squeaked from the driver?
May be the issue I am reporting isn't something new. I can't believe I am the 
only one who observed that sort of instability.

> I never said Intel is not monitoring the communities. I said the 
> networking group is not monitoring the communities. At the very least, 
> I am not monitoring the communities at all and only look when someone points 
> things out to me.
> 
> Also, if you're running HP hardware, you may want to file a bug with 
> HP as the firmware updates have to come from HP and this may be a firmware 
> issue.
> 

That would be the least helpful thing as they simply refuse to do anything for 
drivers that don't maintain. I have been running production servers for ~20 
years and HP support is helpful only for the stuff they develop. As far as the 
firmware version, we only install the firmware they provide, which is always 
one version behind from the one provided by Intel and if we install firmware 
from Intel then we lose support. Furthermore, HP does not care about 4.9 
kernel, they only know the kernel that is provided by CentOS. I don't think 
going down the road of contacting HP support for errors reported by a network 
driver is the best approach.

Thanks,
Pavlos

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
http://communities.intel.com/community/wired

Re: [E1000-devel] Instability of i40e driver on 4.9 kernel

[Fujinaka, Todd]

This is just about the last part of your post, about the 4.9 kernel and CentOS.

Are you using the stable 4.9 kernel or are you hoping patches get pulled into 
the CentOS 4.9 kernel? If it's the latter, you need to file a bug with Red Hat 
to have the patches pulled into RHEL, and then CentOS should get those changes 
as well. We have no direct control on the RHEL/CentOS kernels.

If it's the former, someone (most likely you, since you're the one who needs 
the patches) has to identify the patches that should be pulled into the stable 
4.9 kernel and email the maintainer of the stable kernels.

I never said Intel is not monitoring the communities. I said the networking 
group is not monitoring the communities. At the very least, I am not monitoring 
the communities at all and only look when someone points things out to me.

Also, if you're running HP hardware, you may want to file a bug with HP as the 
firmware updates have to come from HP and this may be a firmware issue.

Todd Fujinaka
Software Application Engineer
Datacenter Engineering Group
Intel Corporation
todd.fujin...@intel.com

-Original Message-
From: Pavlos Parissis [mailto:pavlos.paris...@gmail.com] 
Sent: Wednesday, October 25, 2017 2:45 PM
To: e1000-devel@lists.sourceforge.net
Subject: [E1000-devel] Instability of i40e driver on 4.9 kernel

Hi all,

I mailed to netdev and inter-wired-lan about stability issues with i40e driver 
on
4.9 kernels and Todd Fujinaka suggested to mail this ML instead about our issue.

We have been running 4.9 kernels for several months on CentOS 7.3 and for few 
weeks on CentOS 7.4, and after we replaced 10GbE copper cards(X540-AT2 with 
ixgbe
driver) with X710 10GbE SFP cards using i40e driver, we noticed sever 
instabilities on our servers.

On several servers the links were marked down and up again, without any obvious 
reasons expect a lot of errors on kernel.log:

[..snip..]
2017-10-04T15:50:46.839998+02:00kernel: i40e :04:00.1 eth0: tx_timeout 
recovery level 3, hung_queue 11

2017-10-04T15:50:50.119447+02:00kernel: i40e :04:00.0: Query for DCB 
configuration failed, err I40E_ERR_ADMIN_QUEUE_ERROR aq_err I40E_AQ_RC_EPERM

2017-10-04T15:50:50.119455+02:00kernel: i40e :04:00.0: DCB init failed -53, 
disabled

2017-10-04T15:50:50.301798+02:00kernel: i40e :04:00.0 eth1: NIC Link is Down

2017-10-04T15:50:50.423744+02:00kernel: i40e :04:00.1: Query for DCB 
configuration failed, err I40E_ERR_ADMIN_QUEUE_ERROR aq_err I40E_AQ_RC_EPERM

2017-10-04T15:50:50.423752+02:00kernel: i40e :04:00.1: DCB init failed -53, 
disabled

2017-10-04T15:50:50.600812+02:00kernel: i40e :04:00.1 eth0: NIC Link is Down

2017-10-04T15:50:50.764799+02:00kernel: i40e :04:00.1 eth0: NIC Link is Up 
10 Gbps Full Duplex, Flow Control: None

2017-10-04T15:50:53.234804+02:00kernel: i40e :04:00.0 eth1: NIC Link is Up 
10 Gbps Full Duplex, Flow Control: None

2017-10-04T15:51:17.201808+02:00kernel: i40e :04:00.1: TX driver issue 
detected, PF reset issued [..snip..]

We run Bird Internet daemon on our servers in order to establish BGP peerings 
with routers and we have also observed flapping on BGP peerings. At the same 
time we had BGP peering stabilities issues we had kernel errors:

2017-10-06T07:36:10.526657+02:00 kernel: [60720.957855] i40e :04:00.1: DCB 
init failed -53, disabled

2017-10-06T07:36:12.127091+02:00 kernel: [60722.553258] i40e :04:00.1: TX 
driver issue detected, PF reset issued

2017-10-06T07:36:12.509188+02:00 kernel: [60722.891523] i40e :04:00.1: 
Query for DCB configuration failed, err I40E_ERR_ADMIN_QUEUE_ERROR aq_err 
I40E_AQ_RC_EPERM

We decided to go back to 3.10 kernel from CentOS, but that process wasn't 
smooth as latest firmware gave us problems with speed detection. We rolled back 
to two version old and speed detection issue was resolved. We have been running 
3.10 several weeks without any problems.

Even we want certain functionality from kernel 4.9, we decided to switch back to
3.10 as stability of our systems has higher priority.

I need to mention that in all occurrences of the issue we didn't see any 
anomalies, such DDOS attacks and etc.

I have opened https://communities.intel.com/message/501682#501682 and there you 
can find all the error messages and other information.

Todd Fujinaka asked me to provide reproduction steps, but we only got the 
issues when we had real customer traffic on our servers.

Has anyone seen those errors and observed this kind of instability?

Since we noticed the issues, I have been following netdev ML and I know that 
there are a lot of improvements/patched queued up for 4.14 and I am hoping 
those patches fix our issue and most importantly are sent to linux-stable for 
inclusion in 4.9 kernel.

Cheers,
Pavlos

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

Re: [E1000-devel] i40e nested VLANs/Q-in-Q/txvlan broken

[Fujinaka, Todd]

I believe you need the latest version of the firmware and the operations are 
described in the xl710 datasheet that was just released. Google for "xl710 
datasheet" and you should find one dated September 2017.

Todd Fujinaka
Software Application Engineer
Datacenter Engineering Group
Intel Corporation
todd.fujin...@intel.com
(503) 712-4565


-Original Message-
From: Alexander Duyck [mailto:alexander.du...@gmail.com] 
Sent: Tuesday, September 19, 2017 8:43 AM
To: Stefan Bühler 
Cc: e1000-devel@lists.sourceforge.net
Subject: Re: [E1000-devel] i40e nested VLANs/Q-in-Q/txvlan broken

On Tue, Sep 19, 2017 at 2:42 AM, Stefan Bühler  
wrote:
> Hi Alex,
>
> On 09/19/2017 01:52 AM, Alexander Duyck wrote:
>> On Mon, Sep 18, 2017 at 9:45 AM, Stefan Bühler 
>>  wrote:
>>> Hi,
>>>
>>> I've got an X710 ethernet controller; and when I add nested VLANs 
>>> the "inner" tag gets lost unless I disable the txvlan feature 
>>> (`ethtool -K
>>> ens1f0 txvlan off`).
>>>
>>> This is my setup:
>>>
>>> /sbin/ip link add link ens1f0 name vlan12 type vlan protocol 802.1Q 
>>> id 12 /sbin/brctl addif intern vlan12 /sbin/ip link set dev vlan12 
>>> up /sbin/ip link add link vlan12 name vlan152 type vlan protocol 
>>> 802.1ad id 152 /sbin/brctl addif intern vlan152 /sbin/ip link set 
>>> dev vlan152 up
>>>
>>> Frames send on vlan152 will only show up in vlan12 on the other end 
>>> without the 802.1ad tag.
>>>
>>> If the hardware doesn't support this, maybe it could be emulated in 
>>> software?  Or could I get at least some big warnings somewhere?  Is 
>>> this a (publicly) known bug?
>>>
>>> I somehow doubt many people are able to track this bug down if they 
>>> hit it in the wild, but maybe not many people are using 802.1ad in 
>>> the first place...
>>>
>>> Are there any estimates how badly `txvlan` is needed for 10G?
>>>
>>> cheers,
>>> Stefan
>>>
>>> ---
>>>
>>> # uname -a
>>> Linux prowler 4.9.0-3-amd64 #1 SMP Debian 4.9.30-2+deb9u3 
>>> (2017-08-06) x86_64 GNU/Linux # lspci -s 02:00.0 -v
>>> 02:00.0 Ethernet controller: Intel Corporation Ethernet Controller X710 for 
>>> 10GbE SFP+ (rev 01)
>>> Subsystem: Intel Corporation Ethernet Converged Network Adapter 
>>> X710-4
>>> Physical Slot: 1
>>> Flags: bus master, fast devsel, latency 0, IRQ 26, NUMA node 0
>>> Memory at 9080 (64-bit, prefetchable) [size=8M]
>>> Memory at 9300 (64-bit, prefetchable) [size=32K]
>>> Expansion ROM at fb28 [disabled] [size=512K]
>>> Capabilities: [40] Power Management version 3
>>> Capabilities: [50] MSI: Enable- Count=1/1 Maskable+ 64bit+
>>> Capabilities: [70] MSI-X: Enable+ Count=129 Masked-
>>> Capabilities: [a0] Express Endpoint, MSI 00
>>> Capabilities: [e0] Vital Product Data
>>> Capabilities: [100] Advanced Error Reporting
>>> Capabilities: [140] Device Serial Number [...]
>>> Capabilities: [150] Alternative Routing-ID Interpretation (ARI)
>>> Capabilities: [160] Single Root I/O Virtualization (SR-IOV)
>>> Capabilities: [1a0] Transaction Processing Hints
>>> Capabilities: [1b0] Access Control Services
>>> Capabilities: [1d0] #19
>>> Kernel driver in use: i40e
>>> Kernel modules: i40e
>>
>> Hi Sefan,
>>
>> You might want to check and see what version of the firmware you are 
>> running by getting the firmware version via "ethtool -i" for the 
>> interface in question. My understanding is that some older firmware 
>> versions didn't handle double tagging correctly. You may find that 
>> updating the firmware will help to improve the behavior when handling 
>> Q-in-Q packets.
>
> I indeed didn't have the latest firmware, but the one before.  I 
> updated the firmware, but neither a module reload (which already 
> showed the new firmware version) nor a full reboot fixed it; I still 
> need to disable txvlan.
>
> cheers,
> Stefan
>
> ---
>
> Before:
> # ethtool -i ens1f0
> driver: i40e
> version: 1.6.16-k
> firmware-version: 5.05 0x80002919 1.1313.0
> expansion-rom-version:
> bus-info: :02:00.0
> supports-statistics: yes
> supports-test: yes
> supports-eeprom-access: yes
> supports-register-dump: yes
> supports-priv-flags: yes
>
> After:
> # ethtool -i ens1f0
> driver: i40e
> version: 1.6.16-k
> firmware-version: 6.01 0x800034af 1.1747.0
> expansion-rom-version:
> bus-info: :02:00.0
> supports-statistics: yes
> supports-test: yes
> supports-eeprom-access: yes
> supports-register-dump: yes
> supports-priv-flags: yes

So the driver version is a little old and doesn't include a fix for 802.1ad 
VLANs that we are planning to push to the upstream kernel. The plan is to push 
the fix to Dave Miller's net-next tree in the near future. You can find the fix 
in patch form online currently at:
http://patchwork.ozlabs.org/patch/804626/

You might want to try downloading the latest 

Re: [E1000-devel] Unsupported SFP+ in i40e 2.1.26, works in older versions

[Fujinaka, Todd]

This doesn't sound quite right, and if it's following the driver then there 
might be a SW bug.

Can you send us the output of "ethtool -i "? A full dmesg would be good, 
too, but attaching that to a bug on e1000.sourceforge.net would be the best 
since this list strips attachments.

Todd Fujinaka
Software Application Engineer
Datacenter Engineering Group
Intel Corporation
todd.fujin...@intel.com
(503) 712-4565


-Original Message-
From: Thorvald Natvig [mailto:thorv...@medallia.com] 
Sent: Wednesday, September 6, 2017 6:52 PM
To: e1000-de...@lists.sf.net
Subject: [E1000-devel] Unsupported SFP+ in i40e 2.1.26, works in older versions

On a EXL710QDA2G1P5 card, after upgrading the NVM to 6.01 and driver to
2.1.26 on kernel 4.10, we get "Rx/Tx is disabled on this device because an 
unsupported SFP+ module type was detected."

This is a unlocked card, and when reverting to the default kernel driver in 
4.10, or using the 2.0.30 driver, this problem goes away, but so does support 
for get_module_eeprom which was our reason for upgrading.

Is this an intentional change?

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
http://communities.intel.com/community/wired

Re: [E1000-devel] Ethernet link goes down and come up again in 6 seconds

[Fujinaka, Todd]

What is your link partner and is it powering off the port due to EEE? What is 
the part you're using? (Check using lspci.)

Todd Fujinaka
Software Application Engineer
Datacenter Engineering Group
Intel Corporation
todd.fujin...@intel.com
(503) 712-4565


-Original Message-
From: Edison, Arul (GE Healthcare) [mailto:aruljeyananth.jamesedi...@ge.com] 
Sent: Monday, August 14, 2017 3:38 AM
To: e1000-devel@lists.sourceforge.net
Subject: [E1000-devel] Ethernet link goes down and come up again in 6 seconds

Hi All,
I am using 1000e: Intel(R) PRO/1000 Network Driver - 3.2.5 in 
my system and the PCIe x1 Intel Gigabit NIC card I am using .
Network connected to eth1 is another system.
Sometime , I see the following message in Syslog file , though 
the system connected to eth1 is not down
2017-08-03 13:04:39.610 kernel: e1000e: eth1 NIC Link is Down
2017-08-03 13:04:45.294 kernel: e1000e: eth1 NIC Link is Up 1000 Mbps Full 
Duplex, Flow Control: None


Amy reason why I get this error?





--
Check out the vibrant tech community on one of the world's most engaging tech 
sites, Slashdot.org! http://sdm.link/slashdot 
___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
http://communities.intel.com/community/wired

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
http://communities.intel.com/community/wired

Re: [E1000-devel] Possible bug in the i40evf driver

[Fujinaka, Todd]

Our developer still thinks the race condition would be elsewhere.

In both i40evf_reset_task and i40evf_open, i40evf_configure is being called and 
i40evf_configure calls i40evf_set_rx_mode.
Then in 40evf_set_rx_mode, there is the while loop to check 
__I40EVF_IN_CRITICAL_TASK. 

while (test_and_set_bit(__I40EVF_IN_CRITICAL_TASK, 
>crit_section))
   dev_err(>pdev->dev, "Failed to get lock in 
%s\n", __func__);

i40evf_up_complete is being called after the call of i40evf_configure. 

Todd Fujinaka
Software Application Engineer
Datacenter Engineering Group
Intel Corporation
todd.fujin...@intel.com
(503) 712-4565


-Original Message-
From: Codrut Grosu [mailto:cogr...@ixiacom.com] 
Sent: Thursday, August 3, 2017 7:12 AM
To: Alexander Duyck 
Cc: e1000-devel@lists.sourceforge.net; Tudor Cornea 
Subject: Re: [E1000-devel] Possible bug in the i40evf driver

  Hi Alex,

  I apologize for my mistake and for being unclear. I meant "ndo_stop".

  You are right that they should be called with the RTNL lock held. And we were 
doing that. What is probably wrong is that we were not calling
clear_bit(__LINK_STATE_START, >state); This only happens if we 
call dev_close.
If this bit is not cleared, netif_running will return true in the reset task. 
Then napi_disable will be called again. So it's not about the RTNL lock but 
about the __LINK_STATE_START bit.

  I agree that calling ndo_stop directly is probably wrong. And so far this is 
the only way we can make the driver hang.

 I still think that reset and open could race. As I said I can't reproduce 
this. But the second call to netif_running and napi_enable in the reset task is 
not protected by __I40EVF_IN_CRITICAL_TASK. And the call in i40evf_open to 
i40evf_up_complete is not protected either.

  Best wishes,
Codrut 

-Original Message-
From: Alexander Duyck [mailto:alexander.du...@gmail.com]
Sent: Thursday, August 03, 2017 4:08 AM
To: Codrut Grosu 
Cc: e1000-devel@lists.sourceforge.net
Subject: Re: [E1000-devel] Possible bug in the i40evf driver

On Tue, Aug 1, 2017 at 8:29 AM, Codrut Grosu  wrote:
>Hi,
>
>   We believe there might be a bug in the i40evf driver.
>
>   We think that there is race issue between i40evf_reset_task and i40evf_down 
> / i40evf_open.
> The reason is that the functions napi_enable / napi_disable must be 
> called in pairs in order not to loop indefinitely (or crash).
>
> Consider the following:
>
> ifconfig eth1 mtu 1000 & ifconfig eth1 up
>
> What happens now is that the change of mtu schedules a reset. Suppose 
> the reset task starts, and the first call to netif_running (after
> continue_reset) returns false. Before the thread reaches the second 
> call to netif_running, i40evf_open starts in another thread. Then the second 
> netif_running in reset will return true, and we will have 2 consecutive calls 
> of napi_enable.
>
> We could not reproduce this particular situation in practice (probably due to 
> the short timing).
> However, we did hang the driver using a call to ndo_close() followed 
> quickly by "ethtool -G eth1 rx 4096". In this case netif_running will 
> return true always (as we bypassed the call to dev_close), the reset 
> will be scheduled before the interface finishes going down, and 2 calls to 
> napi_disable will happen.

So this last statement isn't exactly clear. There isn't an ndo_close() in the 
kernel last I knew. There is an ndo_stop() and an i40evf_close(), but there 
isn't an ndo_close(). Can you clarify which one of these you were calling?

I ask because ndo_stop() and i40evf_close() should only be called with the RTNL 
lock held. It sounds like you may not be doing that and that could cause a 
collsion with something like an "ethtool -G" command because the ethtool ioctl 
is taking the RTNL lock to avoid such collisions and if your call that is 
getting into i40evf_close() isn't holding the RTNL then that might explain the 
issue.

- Alex
--
Check out the vibrant tech community on one of the world's most engaging tech 
sites, Slashdot.org! http://sdm.link/slashdot 
___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
http://communities.intel.com/community/wired

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
http://communities.intel.com/community/wired

Re: [E1000-devel] Possible bug in the i40evf driver

[Fujinaka, Todd]

Our developer thinks the i40evf driver is guarded against the race issue as you 
mentioned. 

The main thing is in i40evf driver, the check/set "while 
(test_and_set_bit(__I40EVF_IN_CRITICAL_TASK, >crit_section))" is 
present ahead of the call of i40evf_napi_disable_all(adapter) in i40evf_reset 
and i40evf_down. So basically the race condition won't happen as the 
__I40EVF_IN_CRITICAL_TASK bit check/set prevents it from happening. 

In the developer's reproduction, the commands were run quickly/repeatedly one 
after another as shown below. We did see "i40evf :04:0a.1: Failed to get 
lock in i40evf_set_rx_mode" in dmesg log from time to time and that was there 
exactly because of the check/set against __I40EVF_IN_CRITICAL_TASK bit. No hang 
of the driver ever happened.

ifconfig eth1 mtu 1000 & ifconfig eth1 up ifconfig eth1 down ethtool -G eth1 rx 
4096

Can you give us more information? We need exact reproduction steps, OS/kernel 
versions, driver & firmware versions (ethtool -i  will show this), and 
your hardware. You can file a bug on e1000.sourceforge.net to provide the 
information as attachments, or preferably open an IPS. I know there are IXIA 
accounts on IPS as I was just sent an issue.

Thanks.

Todd Fujinaka
Software Application Engineer
Datacenter Engineering Group
Intel Corporation
todd.fujin...@intel.com
(503) 712-4565


-----Original Message-
From: Fujinaka, Todd [mailto:todd.fujin...@intel.com] 
Sent: Tuesday, August 1, 2017 1:41 PM
To: Codrut Grosu <cogr...@ixiacom.com>; e1000-devel@lists.sourceforge.net
Subject: Re: [E1000-devel] Possible bug in the i40evf driver

Thanks! We're having the developers look into this issue.

Todd Fujinaka
Software Application Engineer
Datacenter Engineering Group
Intel Corporation
todd.fujin...@intel.com
(503) 712-4565


-Original Message-
From: Codrut Grosu [mailto:cogr...@ixiacom.com]
Sent: Tuesday, August 1, 2017 8:30 AM
To: e1000-devel@lists.sourceforge.net
Subject: [E1000-devel] Possible bug in the i40evf driver

   Hi,

  We believe there might be a bug in the i40evf driver.

  We think that there is race issue between i40evf_reset_task and i40evf_down / 
i40evf_open.
The reason is that the functions napi_enable / napi_disable must be called in 
pairs in order not to loop indefinitely (or crash).

Consider the following:

ifconfig eth1 mtu 1000 & ifconfig eth1 up

What happens now is that the change of mtu schedules a reset. Suppose the reset 
task starts, and the first call to netif_running (after continue_reset) returns 
false. Before the thread reaches the second call to netif_running, i40evf_open 
starts in another thread. Then the second netif_running in reset will return 
true, and we will have 2 consecutive calls of napi_enable.

We could not reproduce this particular situation in practice (probably due to 
the short timing).
However, we did hang the driver using a call to ndo_close() followed quickly by 
"ethtool -G eth1 rx 4096". In this case netif_running will return true always 
(as we bypassed the call to dev_close), the reset will be scheduled before the 
interface finishes going down, and 2 calls to napi_disable will happen.

  Please let us know your opinion.

   Best wishes,
  Tudor, Codrut
--
Check out the vibrant tech community on one of the world's most engaging tech 
sites, Slashdot.org! http://sdm.link/slashdot 
___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
http://communities.intel.com/community/wired

--
Check out the vibrant tech community on one of the world's most engaging tech 
sites, Slashdot.org! http://sdm.link/slashdot 
___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
http://communities.intel.com/community/wired

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
http://communities.intel.com/community/wired

Re: [E1000-devel] Possible bug in the i40evf driver

[Fujinaka, Todd]

Thanks! We're having the developers look into this issue.

Todd Fujinaka
Software Application Engineer
Datacenter Engineering Group
Intel Corporation
todd.fujin...@intel.com
(503) 712-4565


-Original Message-
From: Codrut Grosu [mailto:cogr...@ixiacom.com] 
Sent: Tuesday, August 1, 2017 8:30 AM
To: e1000-devel@lists.sourceforge.net
Subject: [E1000-devel] Possible bug in the i40evf driver

   Hi,

  We believe there might be a bug in the i40evf driver.

  We think that there is race issue between i40evf_reset_task and i40evf_down / 
i40evf_open.
The reason is that the functions napi_enable / napi_disable must be called in 
pairs in order not to loop indefinitely (or crash).

Consider the following:

ifconfig eth1 mtu 1000 & ifconfig eth1 up

What happens now is that the change of mtu schedules a reset. Suppose the reset 
task starts, and the first call to netif_running (after continue_reset) returns 
false. Before the thread reaches the second call to netif_running, i40evf_open 
starts in another thread. Then the second netif_running in reset will return 
true, and we will have 2 consecutive calls of napi_enable.

We could not reproduce this particular situation in practice (probably due to 
the short timing).
However, we did hang the driver using a call to ndo_close() followed quickly by 
"ethtool -G eth1 rx 4096". In this case netif_running will return true always 
(as we bypassed the call to dev_close), the reset will be scheduled before the 
interface finishes going down, and 2 calls to napi_disable will happen.

  Please let us know your opinion.

   Best wishes,
  Tudor, Codrut
--
Check out the vibrant tech community on one of the world's most engaging tech 
sites, Slashdot.org! http://sdm.link/slashdot 
___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
http://communities.intel.com/community/wired

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
http://communities.intel.com/community/wired

Re: [E1000-devel] The NVM Checksum Is Not Valid

[Fujinaka, Todd]

What hardware are you running? I would suggest getting this into IPS through 
your FAE if this is something you've designed.

If it's off-the-shelf, you may need to go to the manufacturer first.

Todd Fujinaka
Software Application Engineer
Datacenter Engineering Group
Intel Corporation
todd.fujin...@intel.com
(503) 712-4565


-Original Message-
From: Paulsen, Keith [mailto:kpaul...@curtisswright.com] 
Sent: Monday, July 31, 2017 9:46 AM
To: e1000-de...@lists.sf.net
Subject: [E1000-devel] The NVM Checksum Is Not Valid

I am having difficulty getting the I210 Gigabit (rev 03) to work.

I am on Linux kernel version 3.10.0-514.el7.x86_64

I get the following message in dmesg.

Intel Gigabit Ethernet Ntwork Driver - version 5.3.5.7 Igb :01:00.0 : irq 
32 Igb :01:00.0 : irq 34 Igb :01:00.0 : The NVM Checksum Is Not Valid
Igb: probe of :01:00.0 failed with error -5

Do you know what I may have done wrong?

Thank you very much!

Keith



___
This e-mail and any files transmitted with it are proprietary and intended 
solely for the use of the individual or entity to whom they are addressed.  If 
you have reason to believe that you have received this e-mail in error, please 
notify the sender and destroy this e-mail and any attached files.  Please note 
that any views or opinions presented in this e-mail are solely those of the 
author and do not necessarily represent those of the Curtiss-Wright Corporation 
or any of its subsidiaries.  Documents attached hereto may contain technology 
subject to government export regulations.  Recipient is solely responsible for 
ensuring that any re-export, transfer or disclosure of this information is in 
accordance with applicable government export regulations.  The recipient should 
check this e-mail and any attachments for the presence of viruses.  
Curtiss-Wright Corporation and its subsidiaries accept no liability for any 
damage caused by any virus transmitted by this e-mail.
--
Check out the vibrant tech community on one of the world's most engaging tech 
sites, Slashdot.org! http://sdm.link/slashdot 
___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
http://communities.intel.com/community/wired

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
http://communities.intel.com/community/wired

Re: [E1000-devel] i40e driver / XL710 receive all bad packets

[Fujinaka, Todd]

I'm having some issues with the documentation. I've sent you an email directly 
suggesting that you file an IPS with your FAE for the quickest answer.

Otherwise I'll try to get the documentation fixed and the next release of the 
documentation might not be as fast.

Todd Fujinaka
Software Application Engineer
Datacenter Engineering Group
Intel Corporation
todd.fujin...@intel.com
(503) 712-4565


-Original Message-
From: Codrut Grosu [mailto:cogr...@ixiacom.com] 
Sent: Thursday, July 13, 2017 7:58 AM
To: e1000-devel@lists.sourceforge.net
Subject: [E1000-devel] i40e driver / XL710 receive all bad packets

   Hi,

  I would like to modify the i40e driver to make xl710 receive bad packets as 
well (for example, ignore crc errors). From the datasheet I see that I should 
set the SBP bit in the PRT_SBPVSI register. But, I don't know how to do this. I 
don't even know what is the address of this register.

 I would be grateful for any help.

 Best wishes,

   Codrut
--
Check out the vibrant tech community on one of the world's most engaging tech 
sites, Slashdot.org! http://sdm.link/slashdot 
___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
http://communities.intel.com/community/wired

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
http://communities.intel.com/community/wired

Re: [E1000-devel] Ubuntu Kernel Version on AWS EC2

[Fujinaka, Todd]

Anything bigger than 255 is customized, most likely by AWS. We can't support 
every variant and that's a reason to have that check.

We only support the stock LTS kernels - since you're running a custom kernel, 
you get to run a custom driver. You'll need to ask AWS what they changed in the 
kernel.

Todd Fujinaka
Software Application Engineer
Datacenter Engineering Group
Intel Corporation
todd.fujin...@intel.com
(503) 712-4565


-Original Message-
From: Mike Hicklen [mailto:mike.hick...@rackspace.com] 
Sent: Wednesday, July 05, 2017 12:07 PM
To: e1000-devel@lists.sourceforge.net
Subject: [E1000-devel] Ubuntu Kernel Version on AWS EC2

Ubuntu 16.04 uses a kernel version of 1022 as of this email:



/usr/src/ixgbevf-4.1.2# dkms add -m ixgbevf -v 4.1.2

Creating symlink /var/lib/dkms/ixgbevf/4.1.2/source ->
 /usr/src/ixgbevf-4.1.2

DKMS: add completed.
root@ip-10-50-38-224:/usr/src/ixgbevf-4.1.2# dkms build -m ixgbevf -v 4.1.2

Kernel preparation unnecessary for this kernel.  Skipping...

Building module:
cleaning build area
cd src/; make BUILD_KERNEL=4.4.0-1022-aws(bad exit status: 2) ERROR (dkms 
apport): binary package for ixgbevf: 4.1.2 not found Error! Bad return status 
for module build on kernel: 4.4.0-1022-aws (x86_64) Consult 
/var/lib/dkms/ixgbevf/4.1.2/build/make.log for more information.



/usr/src/ixgbevf-4.1.2# uname -r
4.4.0-1022-aws




 807 #if UTS_UBUNTU_RELEASE_ABI > 255
 808 #error UTS_UBUNTU_RELEASE_ABI is too large...
 809 #endif /* UTS_UBUNTU_RELEASE_ABI > 255 */
 810
"../ixgbevf-4.1.2/src/kcompat.h" 5442 lines --12%-- 
702,9 13%



I fixed it as follows:


 807 #if UTS_UBUNTU_RELEASE_ABI >2048
 808 #error UTS_UBUNTU_RELEASE_ABI is too large...
 809 #endif /* UTS_UBUNTU_RELEASE_ABI > 255 */
 810
"../ixgbevf-4.1.2/src/kcompat.h" 5442 lines --12%-- 
702,9 13%



Any ideas on how to best address this?  It built after this but it's not 
terribly convincing.
--
Check out the vibrant tech community on one of the world's most engaging tech 
sites, Slashdot.org! http://sdm.link/slashdot 
___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
http://communities.intel.com/community/wired

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
http://communities.intel.com/community/wired

Re: [E1000-devel] [linux-nics] will Intel igb-5.3.5.7 support OpenWrt platform?

[Fujinaka, Todd]

We do not support OpenWRT, but the kernel should have an igb driver. If it 
doesn't, you need to contact the OpenWRT project.

Todd Fujinaka
Software Application Engineer
Datacenter Engineering Group
Intel Corporation
todd.fujin...@intel.com
(503) 712-4565


-Original Message-
From: linux-nics-boun...@isotope.jf.intel.com 
[mailto:linux-nics-boun...@isotope.jf.intel.com] On Behalf Of ???
Sent: Wednesday, July 05, 2017 12:06 AM
To: Linux NICS 
Cc: e1000-devel 
Subject: [linux-nics] will Intel igb-5.3.5.7 support OpenWrt platform?

Could anyone please make a kernel module package to support igb in OpenWrt 
system?
Since currently many platform using OpenWrt as the Router system.
___
Linux-nics mailing list
linux-n...@intel.com
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
http://communities.intel.com/community/wired

Re: [E1000-devel] Installed RHEL 6.5 LAN communication not working

[Fujinaka, Todd]

RHEL 6.5 released before the i219 and reached EOL November 30, 2015. You can 
either try downloading and compiling a standalone driver or you can get a 
supported version of RHEL.

In either case, you should contact Red Hat for initial support of RHEL.

Todd Fujinaka
Software Application Engineer
Datacenter Engineering Group
Intel Corporation
todd.fujin...@intel.com
(503) 712-4565


-Original Message-
From: sanjeevaraor--- via E1000-devel 
[mailto:e1000-devel@lists.sourceforge.net] 
Sent: Wednesday, June 07, 2017 2:57 AM
To: e1000-devel@lists.sourceforge.net
Subject: [E1000-devel] Installed RHEL 6.5 LAN communication not working

I installed RHEL 6.5 on a new Dell Desktop optiplex7040. This desktop has a 
I219-LM ehternet interface.

I installed RHEL6.5, UEFI mode, with a Windows 10 dual boot.
It succeeded to install, I get the prompt of RHEL, can login

Unfortunatly, drivers for I219-LM are not installed. There is no ifcfg-e* in 
/etc/sysconfig/network-scripts/.
Only a ifcfg-lo file.

How can I install the drivers module or make my LAN communication work?

Best Regards,
Sanjeeva Rao

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
http://communities.intel.com/community/wired

Re: [E1000-devel] i40e driver vs firmware compatibility

[Fujinaka, Todd]

We only validate the latest firmware with the latest driver. I would think that 
using a newer driver with older firmware might work, but using a newer firmware 
with an older driver sounds less likely to work well.

Keep in mind that we're releasing new bug fixes with the newer drivers and 
firmware and I would strongly suggest you update both.

In any case, we only guarantee the latest firmware with the latest driver and, 
as they say, YMMV.

Todd Fujinaka
Software Application Engineer
Networking Division (ND)
Intel Corporation
todd.fujin...@intel.com
(503) 712-4565


-Original Message-
From: M.R. [mailto:marianrob...@yahoo.com] 
Sent: Thursday, March 30, 2017 9:00 AM
To: e1000-devel@lists.sourceforge.net
Subject: [E1000-devel] i40e driver vs firmware compatibility

Hello,
1. I would like to learn whether the XL710 firmware is backward compatible.2. 
What to look for in case of incompatibility of driver vs firmware?
Thanks!
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
http://communities.intel.com/community/wired

Re: [E1000-devel] Intel i210 - igb information

[Fujinaka, Todd]

Someone else might reply here, but this is an OS issue rather than a driver 
issue and I'd suggest the Ubuntu forums for support on this issue.

Todd Fujinaka
Software Application Engineer
Networking Division (ND)
Intel Corporation
todd.fujin...@intel.com
(503) 712-4565


-Original Message-
From: Paul Tsvika [mailto:mozloverin...@gmail.com] 
Sent: Wednesday, March 22, 2017 1:35 AM
To: e1000-devel@lists.sourceforge.net
Subject: [E1000-devel] Intel i210 - igb information

Hi all,

Before addressing my question, below is my system configuration:

MB: SUPERMICRO X10SBA
Lan chip: Intel® i210AT dual port GbE LAN -  two lan ports available on the 
board
OS: Ubuntu 16.04

As far as I know, the network naming mechanism has been changed since Ubuntu 
15.10 and its newer version, udev will follow the rule to assign the network 
interface name:

* Predictable network interface device names based on:
* - firmware/bios-provided index numbers for on-board devices

By using udevadm to get more information about these two lan ports ( detail log 
can be found in the attachment ):

1.  Two lan chips report the same index
* ATTRS{index}=="1"*

2. Based on the udev, one network interface is named eno1 < the number "1" 
is because of reporting from index
However, the other one is incorrect, it's interface name is "rename3"

3. The system boots very slow due to the race condition of network naming (
eno1 is taken and the other one keeps trying to get this and then finally gave 
up )

4. I revert back to the original network interface naming rule ( eth0, eth1... 
), the system boots as fast as I expect.

Question:

1. My understanding is that the index value should be unique. Since the board 
has two lan ports, the index value should not be the same. If i am wrong, 
please correct me.

2. I traced udev  and igb. The value reported by udevadm is obtained from 
*/sys/class/net/xxx*. I assume the information in */sys/class/net/xxx *is 
reported from igb driver.

3.  Hence, where is *ATTRS{index}=="1" *reported from, should it be Lan chip 
firmware or bios ?


Any discussion is appreciated.


Thanks



Paul

--
P.T
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
http://communities.intel.com/community/wired

Re: [E1000-devel] Can I join the mailing list?

[Fujinaka, Todd]

You should be able to join from the sourceforge website.

Todd Fujinaka
Software Application Engineer
Networking Division (ND)
Intel Corporation
todd.fujin...@intel.com
(503) 712-4565


-Original Message-
From: Paul Tsvika [mailto:mozloverin...@gmail.com] 
Sent: Wednesday, March 22, 2017 12:45 AM
To: e1000-devel@lists.sourceforge.net
Subject: [E1000-devel] Can I join the mailing list?

As title.

Thanks.



Paul

-- 
P.T
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
http://communities.intel.com/community/wired

Re: [E1000-devel] How to install - Ubuntu 16.04

[Fujinaka, Todd]

There's a README in our tarballs and you should just be able to do a "make 
install". However, that parts should be in the Ubuntu kernel. You can open a 
bug on sourceforge, but this might be a question for Canonical/Ubuntu.

Todd Fujinaka
Software Application Engineer
Networking Division (ND)
Intel Corporation
todd.fujin...@intel.com
(503) 712-4565


-Original Message-
From: Anthony Rooney [mailto:roon...@iinet.net.au] 
Sent: Tuesday, March 21, 2017 3:15 AM
To: e1000-devel@lists.sourceforge.net
Subject: [E1000-devel] How to install - Ubuntu 16.04

Hello

 

I have downloaded the e1000e drivers tar.gz.  Where do I copy the files to 
install.

 

I am trying to light up a 82566DN-2 on board adapter that Ubuntu can detect 
lshe -C Network but ethtool sees no such devise so I have no wired networking 
since fresh install.

 

Worked on the same hardware fine with 10.04 and 12.04.

 

 

 

Kind Regards

 

 

Anthony Rooney

0411 649978

 


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
http://communities.intel.com/community/wired

Re: [E1000-devel] nvmupdate problem

[Fujinaka, Todd]

Your card appears to be a Dell NIC, and you'll have to contact Dell for the 
updater.

Todd Fujinaka
Software Application Engineer
Networking Division (ND)
Intel Corporation
todd.fujin...@intel.com
(503) 712-4565


-Original Message-
From: Łukasz Chrustek [mailto:luk...@chrustek.net] 
Sent: Monday, March 20, 2017 4:16 PM
To: Buchholz, Donald ; 
e1000-devel@lists.sourceforge.net
Subject: Re: [E1000-devel] nvmupdate problem

Hi,

As  I  wrote at the end - I was trying 5.05, but the effect remain the
same:

# ./nvmupdate64e

Intel(R) Ethernet NVM Update Tool
NVMUpdate version 1.28.19.4
Copyright (C) 2013 - 2016 Intel Corporation.


WARNING: To avoid damage to your device, do not stop the update or reboot or 
power off the system during this update.
Inventory in progress. Please wait [|.]


Num Description   Ver. DevId S:BStatus
===  = = == ===
01) Intel(R) Ethernet Converged Network   4.41  1572 00:002 Update not 
Adapter X710available
02) Intel(R) I350 Gigabit Network Connection  1.99  1521 00:004 Update not 
available
03) Intel(R) Ethernet Converged Network   4.41  1572 00:129 Update not 
Adapter X710available


Tool execution completed with the following status: Device not found Press any 
key to exit.



# ./nvmupdate64e -i -l

Intel(R) Ethernet NVM Update Tool
NVMUpdate version 1.28.19.4
Copyright (C) 2013 - 2016 Intel Corporation.

Inventory
[00:002:00:00]: Intel(R) Ethernet Converged Network Adapter X710
EEPROM inventory started
Alternate MAC address is not set
EEPROM inventory finished
Flash inventory started
Flash inventory finished
OROM inventory started
OROM inventory finished
[00:002:00:01]: Intel(R) Ethernet Controller X710 for 10GbE SFP+
Device already inventoried.
[00:004:00:00]: Intel(R) I350 Gigabit Network Connection
EEPROM inventory started
EEPROM inventory finished
Flash inventory started
Flash is not supported on this adapter
Flash inventory finished
[00:004:00:01]: Intel(R) I350 Gigabit Network Connection
Device already inventoried.
[00:129:00:00]: Intel(R) Ethernet Converged Network Adapter X710
EEPROM inventory started
Alternate MAC address is not set
EEPROM inventory finished
Flash inventory started
Flash inventory finished
OROM inventory started
OROM inventory finished
[00:129:00:01]: Intel(R) Ethernet Controller X710 for 10GbE SFP+
Device already inventoried.
[00:002:00:00]: Intel(R) Ethernet Converged Network Adapter X710
Vendor : 8086
Device : 1572
Subvendor  : 8086
Subdevice  : 6
Revision   : 1
LAN MAC: 3CFDFE06D180
Alt MAC: 
SAN MAC: 3CFDFE06D181
ETrackId   : 80001866
NVM Version: 4.41
Flash update   : No config file entry
  size : 8388608
VPD status:: Valid
VPD size   : 303
NVM update : No config file entry
  checksum : Valid
OROM update: No config file entry
  CIVD : 16.5.10
  PXE  : 1.0.10, checksum Not Relevant
  ISCSI: 3.0.44, checksum Not Relevant
  ISCSI_SETUP  : 3.0.44, checksum Not Relevant
  EFI  : 1.1.33, checksum None
  SMCLP: 3.0.30, checksum Valid
  IMAGE_SHARED_40G : 1.0.7, checksum Not Relevant
[00:002:00:01]: Intel(R) Ethernet Controller X710 for 10GbE SFP+
Vendor : 8086
Device : 1572
Subvendor  : 8086
Subdevice  : 0
Revision   : 1
LAN MAC: 3CFDFE06D182
Alt MAC: 
SAN MAC: 3CFDFE06D183
ETrackId   : 80001866
NVM Version: 4.41
Flash update   : No config file entry
  size : 8388608
VPD status:: Valid
VPD size   : 303
NVM update : No config file entry
  checksum : Valid
OROM update: No config file entry
  CIVD : 16.5.10
  PXE  : 1.0.10, checksum Not Relevant
  ISCSI: 3.0.44, checksum Not Relevant
  ISCSI_SETUP  : 3.0.44, checksum Not 

Re: [E1000-devel] Queue timeout problems with ixgbe/Intel X540-AT2 on Linux 4.9

[Fujinaka, Todd]

The first step is to make sure everything is OK on the Supermicro end, which 
means checking with them for the latest updates to your BIOS, etc.

The second step, is to update the driver with the latest standalone driver from 
e1000.sourceforge.net which is currently ixgbe-5.0.4.

If that doesn’t help, check the per-core CPU utilization and IRQ spread 
(/proc/interrupts | grep ethx).
How much traffic are you seeing when this is happening and what are you 
communicating with? "sar –n DEV 1 10" should show the interface bandwidth and 
netstat should show the connections.

And finally, I see a lot of issues with "current" Debian kernels, but this 
doesn't sound like one of those issues. If it was, I would suggest a newer 
stable kernel from kernel.org.

Hope that helps.

Todd Fujinaka
Software Application Engineer
Networking Division (ND)
Intel Corporation
todd.fujin...@intel.com
(503) 712-4565


-Original Message-
From: Johannes Truschnigg [mailto:johannes.truschn...@geizhals.at] 
Sent: Thursday, March 02, 2017 2:09 AM
To: e1000-devel@lists.sourceforge.net
Subject: [E1000-devel] Queue timeout problems with ixgbe/Intel X540-AT2 on 
Linux 4.9

Hello list,

A machine we recently put into service is showing (presumably) Ethernet-related 
problems. The host is a Supermicro SYS-1028U-TNRT+ barebone with 256GB of 
ECC-RDIMM, 2x Intel Xeon E5-2660 v4 CPUs (24 Cores, HT disabled, BIOS dated 
08/09/2016), and connected to a 1GBit switchport via one of its on-board 
X540-AT2-provided ports (PCIe link properties negotiated: Speed 5GT/s, Width 
x8). The machine's CPU-normalized load is about 1, so it is quite busy.

Additional software/firmware info and NIC stats:

# uname -a
Linux inject 4.9.0-0.bpo.1-amd64 #1 SMP Debian 4.9.2-2~bpo8+1
(2017-01-26) x86_64 GNU/Linux


# ethtool -i eth0
driver: ixgbe
version: 4.4.0-k
firmware-version: 0x83e2
bus-info: :01:00.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: no


# ethtool -S eth0 | grep -v ' 0$'
NIC statistics:
  rx_packets: 273710944
  tx_packets: 398971152
  rx_bytes: 313480861463
  tx_bytes: 470304591176
  rx_pkts_nic: 273710875
  tx_pkts_nic: 398971010
  rx_bytes_nic: 314575702117
  tx_bytes_nic: 471900519485
  lsc_int: 5
  rx_dropped: 56473
  multicast: 58774
  broadcast: 195115
  fdir_match: 273920501
  fdir_miss: 139668
  fdir_overflow: 22
  tx_timeout_count: 4
  tx_restart_queue: 3
[omitting lines that merely detail [rx]x_queue_\d+_{bytes,packets} counters]


Relevant debug ringbuffer contents:

[40807.952873] [ cut here ]
[40807.952921] WARNING: CPU: 18 PID: 15921 at 
/home/zumbi/linux-4.9.2/net/sched/sch_generic.c:316 dev_watchdog+0x220/0x230
[40807.952959] NETDEV WATCHDOG: eth0 (ixgbe): transmit queue 0 timed out
[40807.952983] Modules linked in: tcp_diag inet_diag netconsole configfs 
ipmi_watchdog ast ttm drm_kms_helper drm i2c_algo_bit iTCO_wdt 
iTCO_vendor_support intel_rapl sb_edac edac_core x86_pkg_temp_thermal 
intel_powerclamp coretemp kvm_intel kvm irqbypass crct10dif_pclmul 
crc32_pclmul ghash_clmulni_intel intel_cstate intel_uncore pcspkr evdev 
joydev mei_me i2c_i801 lpc_ich intel_rapl_perf i2c_smbus mei ioatdma 
mfd_core shpchp wmi tpm_tis tpm_tis_core tpm acpi_power_meter acpi_pad 
button ipmi_si ipmi_poweroff ipmi_devintf ipmi_msghandler autofs4 ext4 
crc16 jbd2 fscrypto mbcache raid0 raid1 md_mod hid_generic usbhid hid sg 
sd_mod crc32c_intel aesni_intel ahci aes_x86_64 glue_helper lrw libahci 
gf128mul ablk_helper cryptd xhci_pci libata xhci_hcd ehci_pci ehci_hcd 
ixgbe usbcore scsi_mod dca nvme ptp usb_common
[40807.953445]  pps_core nvme_core mdio fjes
[40807.953467] CPU: 18 PID: 15921 Comm: inject Not tainted 
4.9.0-0.bpo.1-amd64 #1 Debian 4.9.2-2~bpo8+1
[40807.953501] Hardware name: Supermicro SYS-1028U-TNRT+/X10DRU-i+, BIOS 
2.0b 08/09/2016
[40807.953529]   8fd2a1f5 9f977f303e38 

[40807.953564]  8fa77884  9f977f303e90 
9f776ec0
[40807.953599]  0012 9f776ec24f40 0040 
8fa778ff
[40807.953633] Call Trace:
[40807.953646]  
[40807.953665]  [] ? dump_stack+0x5c/0x77
[40807.953688]  [] ? __warn+0xc4/0xe0
[40807.953708]  [] ? warn_slowpath_fmt+0x5f/0x80
[40807.953731]  [] ? dev_watchdog+0x220/0x230
[40807.953753]  [] ? 
dev_deactivate_queue.constprop.27+0x60/0x60
[40807.953784]  [] ? call_timer_fn+0x30/0x130
[40807.953807]  [] ? run_timer_softirq+0x215/0x4b0
[40807.953832]  [] ? timerqueue_add+0x54/0xa0
[40807.953853]  [] ? enqueue_hrtimer+0x38/0x80
[40807.953878]  [] ? __do_softirq+0x106/0x292
[40807.953902]  [] ? 
trace_event_raw_event_mm_lru_insertion+0x170/0x170
[40807.953931]  [] ? irq_exit+0x98/0xa0
[40807.953951]  [] ? smp_apic_timer_interrupt+0x3e/0x50
[40807.953977]  [] ? apic_timer_interrupt+0x82/0x90
[40807.953999]  
[40807.954011]  [] ? 

Re: [E1000-devel] Linux i350 driver problem

[Fujinaka, Todd]

Please don’t send this directly to me.

We don’t have any ARM systems in-house and it may be better for you to ask the 
ARM mailing list.

Todd Fujinaka
Software Application Engineer
Networking Division (ND)
Intel Corporation
todd.fujin...@intel.com
(503) 712-4565

From: hechen...@avsolutiontech.com [mailto:hechen...@avsolutiontech.com]
Sent: Wednesday, February 22, 2017 10:22 PM
To: Fujinaka, Todd <todd.fujin...@intel.com>
Subject: Re: RE: [E1000-devel] Linux i350 driver problem

Thank you for your reply.This is the dmseg message ,When an error occurs.

--Dmseg 
Start
root@dm816x:~# dmesg
Linux version 2.6.37 (root@avst-linux-server) (gcc version 4.5.3 20110311 
(prerelease) (GCC) ) #38 Thu May 5 11:48:44 CST 2016
CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7f
CPU: VIPT nonaliasing data cache, VIPT aliasing instruction cache
Machine: ti8168evm
vram size = 31457280 at 0x0
ti81xx_reserve: ### Reserved DDR region @8ff0
reserved size = 31457280 at 0x0
FB: Reserving 31457280 bytes SDRAM for VRAM
Memory policy: ECC disabled, Data cache writeback
OMAP chip is TI8168 2.1
On node 0 totalpages: 57600
free_area_init_node: node 0, pgdat c0494cd4, node_mem_map c04d
  Normal zone: 512 pages used for memmap
  Normal zone: 0 pages reserved
  Normal zone: 57088 pages, LIFO batch:15
pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
pcpu-alloc: [0] 0
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 57088
Kernel command line: mem=256M console=ttyO2,115200n8 root=/dev/mmcblk0p2 rw 
rootdelay=3 nolock vram=30M notifyk.vpssm3_sva=0xBEE0 ddr_mem=1024M
PID hash table entries: 1024 (order: 0, 4096 bytes)
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Memory: 224MB 1MB = 225MB total
Memory: 223184k/223184k available, 38960k reserved, 0K highmem
Virtual kernel memory layout:
vector  : 0x - 0x1000   (   4 kB)
fixmap  : 0xfff0 - 0xfffe   ( 896 kB)
DMA : 0xffc0 - 0xffe0   (   2 MB)
vmalloc : 0xd080 - 0xf800   ( 632 MB)
lowmem  : 0xc000 - 0xd000   ( 256 MB)
pkmap   : 0xbfe0 - 0xc000   (   2 MB)
modules : 0xbf00 - 0xbfe0   (  14 MB)
  .init : 0xc0008000 - 0xc003f000   ( 220 kB)
  .text : 0xc003f000 - 0xc0456000   (4188 kB)
  .data : 0xc0456000 - 0xc0496540   ( 258 kB)
SLUB: Genslabs=11, HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
NR_IRQS:375
IRQ: Found an INTC at 0xfa20 (revision 5.0) with 128 interrupts
Total of 128 interrupts on 1 active controller
GPMC revision 6.0
Trying to install interrupt handler for IRQ368
Trying to install interrupt handler for IRQ369
Trying to install interrupt handler for IRQ370
Trying to install interrupt handler for IRQ371
Trying to install interrupt handler for IRQ372
Trying to install interrupt handler for IRQ373
Trying to install interrupt handler for IRQ374
Trying to install type control for IRQ375
Trying to set irq flags for IRQ375
OMAP clockevent source: GPTIMER1 at 2700 Hz
Console: colour dummy device 80x30
Calibrating delay loop... 1097.72 BogoMIPS (lpj=5488640)
pid_max: default: 32768 minimum: 301
Security Framework initialized
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
devtmpfs: initialized
TI81XX: Map 0x8ff0 to 0xfe50 for dram barrier
TI81XX: Map 0x4030 to 0xfe60 for sram barrier
omap_voltage_early_init: voltage driver support not added
regulator: core version 0.5
regulator: dummy:
NET: Registered protocol family 16
omap_voltage_domain_lookup: Voltage driver init not yet happened.Faulting!
omap_voltage_add_dev: VDD specified does not exist!
OMAP GPIO hardware version 0.1
OMAP GPIO hardware version 0.1
omap_mux_init: Add partition: #1: core, flags: 0
_omap_mux_get_by_name: Could not find signal i2c2_scl.i2c2_scl
_omap_mux_get_by_name: Could not find signal i2c2_sda.i2c2_sda

 Registering AIC & MCASP2

 Registering AIC & MCASP - Done

 Registering TVP5158 & MCASP0
registered ti816x_sr device
Cannot clk_get ck_32
pm_dbg_init: only OMAP3 supported
registered ti81xx_vpss device
registered ti81xx_vidout device
registered ti81xx on-chip HDMI device
registered ti81xx_fb device
registered ti81xx_vin device
ti81xx_pcie: Invoking PCI BIOS...
ti81xx_pcie: Setting up Host Controller...
ti81xx_pcie: Register base mapped @0xd082
ti81xx_pcie: MSI info not available, disabled
ti81xx_pcie: Starting PCI scan...
pci :00:00.0: [104c:b800] type 1 class 0x000604
PCI: bus0: Fast back to back transfers disabled
pci :01:00.0: [8086:1521] type 0 class 0x000200
pci :01:00.0: reg 10: [mem 0x-0x0001]
pci :01:00.0: reg 18: [io  0x-0x001f]
pci :01:00.0: reg 1c: [mem 0x-0x3fff]
pci :01:00.0: PME# supported from D0 D3hot D3cold
pci :01:00.0: PME# disable

Re: [E1000-devel] Linux i350 driver problem

[Fujinaka, Todd]

Not enough detail. That hang could be from just about anything. We need to know 
a lot more about your issue. Send full dmesg, lspci, EEPROM dump, etc.

If you have an FAE, file the issue with them. Otherwise, you'll have to file a 
bug on sourceforge.

Todd Fujinaka
Software Application Engineer
Networking Division (ND)
Intel Corporation
todd.fujin...@intel.com
(503) 712-4565

-Original Message-
From: hechen...@avsolutiontech.com [mailto:hechen...@avsolutiontech.com] 
Sent: Wednesday, February 22, 2017 12:01 AM
To: e1000-devel 
Subject: [E1000-devel] Linux i350 driver problem

Honorific Intel Engineer：
I'm a embedded engineer based on Linux. When I use the i350T2 Network 
driver ,error occurred,as shown below.
 My Linux version is 2.6.37 , the version of i350T2 driver is 5.0.6.
I would like to ask you how can I solve this problem? Thank you very much. 
This is my contact information:

Telephone : 15201197364  
Mailbox : hechen...@avsolutiontech.com

--[ cut here 
]-
igb :01:00.0: Detected Tx Unit Hang
  Tx Queue <0>
  TDH  
  TDT  
  next_to_use  
  next_to_clean
buffer_info[next_to_clean]
  time_stamp   <91811>
  next_to_watch
  jiffies  <91b40>
  desc.status  <1568200>
[ cut here ]
WARNING: at net/sched/sch_generic.c:258 dev_watchdog+0x148/0x230() NETDEV 
WATCHDOG: eth0 (igb): transmit queue 0 timed out Modules linked in: 
aur5g8ke_face_lcd avst_digit_audio ti81xxhdmi ti81xxfb vpss osa_kermod syslink
Backtrace: 
[] (dump_backtrace+0x0/0x110) from [] (dump_stack+0x18/0x1c)
 r6:c042b298 r5:0102 r4:c0457df0 r3:6113 [] 
(dump_stack+0x0/0x1c) from [] (warn_slowpath_common+0x54/0x6c) 
[] (warn_slowpath_common+0x0/0x6c) from [] 
(warn_slowpath_fmt+0x38/0x40)  r8:c02c78bc r7:0100 r6: r5:c04cb59c 
r4:cdc0c000
r3:0009
[] (warn_slowpath_fmt+0x0/0x40) from [] 
(dev_watchdog+0x148/0x230)
 r3:cdc0c000 r2:c042b2b0
[] (dev_watchdog+0x0/0x230) from [] 
(run_timer_softirq+0x130/0x1c8)
 r6:0100 r5:c0456000 r4:c04b7c40
[] (run_timer_softirq+0x0/0x1c8) from [] 
(__do_softirq+0x84/0x114) [] (__do_softirq+0x0/0x114) from 
[] (irq_exit+0x48/0x98) [] (irq_exit+0x0/0x98) from 
[] (asm_do_IRQ+0x7c/0x9c) [] (asm_do_IRQ+0x0/0x9c) from 
[] (__irq_svc+0x34/0xa0) Exception stack(0xc0457f18 to 0xc0457f60)
7f00:   c0496610 0002
7f20: cbaa8000 5efe1920 cbaa801c c0459040 0015 c982f8c0 ccd24300 413fc082
7f40: ccd24300 c0457f6c c0457f70 c0457f60 c033b460 c033d01c 6013 
 r5:fa20 r4:
[] (atomic_notifier_call_chain+0x0/0x28) from [] 
(__switch_to+0x2c/0x4c) [] (schedule+0x0/0x304) from [] 
(cpu_idle+0x80/0x90) [] (cpu_idle+0x0/0x90) from [] 
(rest_init+0x60/0x78)
 r6:c06d0900 r5:c002dd50 r4:c04babbc r3: [] 
(rest_init+0x0/0x78) from [] (start_kernel+0x264/0x2b8) [] 
(start_kernel+0x0/0x2b8) from [<80008048>] (0x80008048) 
-[ end trace bb79dcc8c86613b8 
]--



hechen...@avsolutiontech.com

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
http://communities.intel.com/community/wired

Re: [E1000-devel] Need Linux Ethernet Driver for Asus B85M-G Motherboard

[Fujinaka, Todd]

I'm sure you've tried things, but that part should be in the latest RHEL 
kernel. You could try booting from a live DVD (like Ubuntu Live) to see if that 
works, but look very carefully at your dmesg when you get home.

Also, make sure you check your BIOS and read the errata and update if necessary.

In any case, you'll probably need to contact Asus. Good luck.

Todd Fujinaka
Software Application Engineer
Networking Division (ND)
Intel Corporation
todd.fujin...@intel.com
(503) 712-4565


-Original Message-
From: Jarod King [mailto:jarodkk...@gmail.com] 
Sent: Wednesday, February 08, 2017 7:41 AM
To: Fujinaka, Todd <todd.fujin...@intel.com>
Cc: Neftin, Sasha <sasha.nef...@intel.com>; e1000-devel@lists.sourceforge.net
Subject: Re: [E1000-devel] Need Linux Ethernet Driver for Asus B85M-G 
Motherboard

Yeah... I was thinking about using a USB dongle NIC and updating to a newer 
kernel.  Thanks Todd.

Sent from my iPhone

> On Feb 8, 2017, at 9:33 AM, Fujinaka, Todd <todd.fujin...@intel.com> wrote:
> 
> I googled your motherboard. It appears you have Realtek Ethernet and we can't 
> help you here.
> 
> I would suggest trying a current stable kernel if your Ethernet is new, but I 
> have no idea how new a Realtek(r) 8111G is.
> 
> Todd Fujinaka
> Software Application Engineer
> Networking Division (ND)
> Intel Corporation
> todd.fujin...@intel.com
> (503) 712-4565
> 
> -Original Message-
> From: Jarod King [mailto:jarodkk...@gmail.com]
> Sent: Wednesday, February 08, 2017 7:10 AM
> To: Neftin, Sasha <sasha.nef...@intel.com>
> Cc: e1000-devel@lists.sourceforge.net
> Subject: Re: [E1000-devel] Need Linux Ethernet Driver for Asus B85M-G 
> Motherboard
> 
> Thanks Sasha,
> 
> I will take these steps when I get home from work this afternoon.
> 
> Jarod
> 
> Sent from my iPhone
> 
>>> On Feb 8, 2017, at 8:22 AM, Neftin, Sasha <sasha.nef...@intel.com> wrote:
>>> 
>>> On 2/8/2017 15:41, Jarod King wrote:
>>> Yes LAN is enabled in BIOS settings.  I was running Windows 7 on this 
>>> machine prior to installing CentOS with no problems.
>>> 
>>> Sent from my iPhone
>>> 
>>>>> On Feb 8, 2017, at 1:07 AM, Neftin, Sasha <sasha.nef...@intel.com> wrote:
>>>>> 
>>>>> On 2/8/2017 07:01, Jarod King wrote:
>>>>> Thanks Stephen.  I tried lspci but it only shows the following devices...
>>>>> 
>>>>> Host bridge
>>>>> PCI bridge
>>>>> VGA compatible controller
>>>>> Audio device
>>>>> USB controller
>>>>> Communication controller: Intel Corporation 8 Series/C220 Series 
>>>>> Chipset Family MEI Controller #1 (rev 4) ISA bridge SATA 
>>>>> controller SMBus
>>>>> 
>>>>> Sent from my iPhone
>>>>> 
>>>>>> On Feb 7, 2017, at 10:51 PM, Stephen Hemminger 
>>>>>> <step...@networkplumber.org> wrote:
>>>>>> 
>>>>>> On Tue, 7 Feb 2017 22:09:24 -0600 Jarod King 
>>>>>> <jarodkk...@gmail.com> wrote:
>>>>>> 
>>>>>>> Help please!  I need a Linux Ethernet Driver for Asus B85M-G 
>>>>>>> Motherboard.  I've just installed CentOS 7 and the network adapter is 
>>>>>>> not showing up.  Whatever happened to installing Linux and the drivers 
>>>>>>> just working?
>>>>>>> 
>>>>>>> Thanks,
>>>>>>> 
>>>>>>> Jarod
>>>>>>> 
>>>>>>> Sent from my iPhone
>>>>>> Use lspci to identify the device.
>>>>> --
>>>>> -
>>>>> --- Check out the vibrant tech community on one of the 
>>>>> world's most engaging tech sites, SlashDot.org!
>>>>> http://sdm.link/slashdot
>>>>> ___
>>>>> E1000-devel mailing list
>>>>> E1000-devel@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/e1000-devel
>>>>> To learn more about Intel Ethernet, visit 
>>>>> http://communities.intel.com/community/wired
>>>> Please, check in BIOS option if LAN controller is enabled.
>>>> 
>> LAN is enabled in BIOS - that's good.  Also you checked that LAN works with 
>> Windows. Can you tell which LAN appeared in Windows?
>> 
>> few things: if device work in windows a