Re: [E1000-devel] Missing VLAN Header
On Mon, Mar 22, 2010 at 7:57 AM, Andreas Grau wrote: > Hi, > > We are currently experimenting with vlan on a 10GE i82599 nic. Linux 2.6.18 > with ixgbe version 2.0.62.4-NAPI is used on top of XEN 3.1.2. > > For the experiments we are using the following scenario: > > - --- --- - > | domU.1 | | dom0.1 | | dom0.2 | | domU.2 | > | | | | | | | | > | 1.0.0.1 | | | | | | 1.0.0.2 | > | vlan100 | | bridge | | bridge | | vlan100 | > | | | | | | | | | | | | | | > | eth0 | | vif eth0 | | vif eth0 | | eth0 | > - --- --- - > | | | | | | > -- ---crossover--- --- > 10GE-kable There is a bug with respect to vlan header stripping (that is not disabled correctly in promisc mode) and 82599, the fix is pretty simple, but is not released yet. > We now execute in domU.1 "ping 1.0.0.2". Unfortunately the ping-request is not > answered. > > Running on dom0.1 "tcpdump -i eth0" gives (as expected): > 16:44:21 vlan 100, p 0, ARP, Request who-has 1.0.0.2 tell 1.0.0.1, length 28 > > Running on dom0.2 "tcpdump -i eth0" gives: > 16:44:21 ARP, Request who-has 1.0.0.2 tell 1.0.0.1, length 42 > > For some reason the vlan header is removed? Could anyone tell me why? > > Cheers Andreas > > PS: Running the same scenario using another gigabit nic and the igb driver, > everything works. We'll have a release out soon with that fix. -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ 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] Network stalls with e1000 driver and 82541 network chips
Dear John, Ronciak, John wrote: > Thanks, it's a bit hard to try and translate this into some we can > understand. :-( Let me know, if there is anything specific you'd like to know and I'll try to translate those bits. >> I am getting dropped packets on the 82572EI interfaces as well. > Thanks not good. This means that the interrupts are not being > serviced fast enough to keep up with the traffic. With 5 networking > ports it doesn't surprise me. What kind of tests are you running to > cause this? It's unclear if this system can withstand the traffic > from these ports. Have you tried to run the test on a single port to > see if the drops happen then as well? Try to see where the problem > starts to happen. Are interrupts being shared between the devices? > What OS are you running? We are running Debian Lenny with different kernel versions. At the moment we are testing with 2.6.30 bpo version. Reading through the archives I've tried the module options TxDescriptorStep=4 TxDescriptors=1024 with the e1000 module. This changes the behaviour. We no longer have tx unit hang messages in the log, but the link nevertheless goes down sporadically and comes back after some seconds. There is no down message in the logs, just the up message: syslog:Mar 22 17:34:09 gw kernel: [765361.074217] e1000: aur-mgt: e1000_watchdog_task: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None syslog:Mar 22 22:28:21 gw kernel: [783013.698259] e1000: aur-mgt: e1000_watchdog_task: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None Interrupts of the 82541 ports are shared with USB, interrupts of the 82572 ports are not shared. I think that the error rate corresponds to the load of the interfaces somehow. Interfaces with little traffic have a smaller value of rx_no_buffer_count and rx_missed_errors than interfaces with lots of traffic. CPU0 CPU1 0: 2676 0 IO-APIC-edge timer 1: 2 0 IO-APIC-edge i8042 3: 896339 0 IO-APIC-edge serial 4: 11 0 IO-APIC-edge 7: 0 0 IO-APIC-edge parport0 8: 56 0 IO-APIC-edge rtc0 9: 0 0 IO-APIC-fasteoi acpi 14: 0 0 IO-APIC-edge ide0 16: 14766 0 IO-APIC-fasteoi uhci_hcd:usb4, ath 18: 193566354 0 IO-APIC-fasteoi uhci_hcd:usb3, aur-mgt 19:1904270 0 IO-APIC-fasteoi uhci_hcd:usb2, gst 23: 0 0 IO-APIC-fasteoi uhci_hcd:usb1, ehci_hcd:usb5 28:6776261 0 PCI-MSI-edge pbr-Q0 29: 2 0 PCI-MSI-edge pbr 30: 66797611 0 PCI-MSI-edge dmz-Q0 31:871 0 PCI-MSI-edge dmz 32: 218588672 0 PCI-MSI-edge inet-Q0 33: 475455 0 PCI-MSI-edge inet 35:5566356 0 PCI-MSI-edge ahci NMI: 0 0 Non-maskable interrupts LOC: 70790723 55485197 Local timer interrupts SPU: 0 0 Spurious interrupts RES: 303286 277829 Rescheduling interrupts CAL:127293 Function call interrupts TLB: 237854 61406 TLB shootdowns Strange thing is we have five of those devices, two show this behavior, three don't. I might be able to dedicate a single device for further testing. Would it help to diagnose further if you had shell access to one of those devices? Best regards, Lars -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ 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] Tx Hang
Hi Guys, I am facing the following issue with e1000 when having a big load. Mar 17 22:18:34 c862f3sq01 kernel: e1000: eth1: e1000_clean_tx_irq: Detected Tx Unit Hang Mar 17 22:18:34 c862f3sq01 kernel: Tx Queue <0> Mar 17 22:18:34 c862f3sq01 kernel: TDH Mar 17 22:18:34 c862f3sq01 kernel: TDT Mar 17 22:18:34 c862f3sq01 kernel: next_to_use Mar 17 22:18:34 c862f3sq01 kernel: next_to_clean Mar 17 22:18:34 c862f3sq01 kernel: buffer_info[next_to_clean] Mar 17 22:18:34 c862f3sq01 kernel: time_stamp <100b3b042> Mar 17 22:18:34 c862f3sq01 kernel: next_to_watch Mar 17 22:18:34 c862f3sq01 kernel: jiffies <100b3b0cc> Mar 17 22:18:34 c862f3sq01 kernel: next_to_watch.status <0> Mar 17 22:18:34 c862f3sq01 kernel: klogd 1.4.1, -- state change -- Mar 17 22:18:36 c862f3sq01 kernel: e1000: eth1: e1000_clean_tx_irq: Detected Tx Unit Hang Mar 17 22:18:36 c862f3sq01 kernel: Tx Queue <0> Mar 17 22:18:36 c862f3sq01 kernel: TDH Mar 17 22:18:36 c862f3sq01 kernel: TDT Mar 17 22:18:36 c862f3sq01 kernel: next_to_use Mar 17 22:18:36 c862f3sq01 kernel: next_to_clean Mar 17 22:18:36 c862f3sq01 kernel: buffer_info[next_to_clean] Mar 17 22:18:36 c862f3sq01 kernel: time_stamp <100b3b042> Mar 17 22:18:36 c862f3sq01 kernel: next_to_watch Mar 17 22:18:36 c862f3sq01 kernel: jiffies <100b3b194> Mar 17 22:18:36 c862f3sq01 kernel: next_to_watch.status <0> Mar 17 22:18:38 c862f3sq01 kernel: e1000: eth1: e1000_clean_tx_irq: Detected Tx Unit Hang Mar 17 22:18:38 c862f3sq01 kernel: Tx Queue <0> Mar 17 22:18:38 c862f3sq01 kernel: TDH Mar 17 22:18:38 c862f3sq01 kernel: TDT Mar 17 22:18:38 c862f3sq01 kernel: next_to_use Mar 17 22:18:38 c862f3sq01 kernel: next_to_clean Mar 17 22:18:38 c862f3sq01 kernel: buffer_info[next_to_clean] Mar 17 22:18:38 c862f3sq01 kernel: time_stamp <100b3b042> Mar 17 22:18:38 c862f3sq01 kernel: next_to_watch Mar 17 22:18:38 c862f3sq01 kernel: jiffies <100b3b25c> Mar 17 22:18:38 c862f3sq01 kernel: next_to_watch.status <0> Mar 17 22:18:40 c862f3sq01 kernel: e1000: eth1: e1000_clean_tx_irq: Detected Tx Unit Hang Mar 17 22:18:40 c862f3sq01 kernel: Tx Queue <0> Mar 17 22:18:40 c862f3sq01 kernel: TDH Mar 17 22:18:40 c862f3sq01 kernel: TDT Mar 17 22:18:40 c862f3sq01 kernel: next_to_use Mar 17 22:18:40 c862f3sq01 kernel: next_to_clean Mar 17 22:18:40 c862f3sq01 kernel: buffer_info[next_to_clean] Mar 17 22:18:40 c862f3sq01 kernel: time_stamp <100b3b042> Mar 17 22:18:40 c862f3sq01 kernel: next_to_watch Mar 17 22:18:40 c862f3sq01 kernel: jiffies <100b3b324> Mar 17 22:18:40 c862f3sq01 kernel: next_to_watch.status <0> Mar 17 22:18:41 c862f3sq01 kernel: [ cut here ] Mar 17 22:18:41 c862f3sq01 kernel: Badness at net/sched/sch_generic.c:219 Mar 17 22:18:41 c862f3sq01 kernel: NIP: c0498eac LR: c0498d8c CTR: 0001 Mar 17 22:18:41 c862f3sq01 kernel: REGS: cf68fa80 TRAP: 0700 Tainted: G (2.6.27.19-5-ppc64) Mar 17 22:18:41 c862f3sq01 kernel: MSR: 80029032 CR: 8822 XER: 0010 Mar 17 22:18:41 c862f3sq01 kernel: TASK = c0918340[0] 'swapper' THREAD: c09d CPU: 0 Mar 17 22:18:41 c862f3sq01 kernel: GPR00: cf68fd00 c09cbc80 0080 Mar 17 22:18:41 c862f3sq01 kernel: GPR04: c0498ce4 c09bb550 c001dcbbb680 Mar 17 22:18:41 c862f3sq01 kernel: GPR08: 0002 c0c91e68 0080 feaf Mar 17 22:18:41 c862f3sq01 kernel: GPR12: 8828 c0a92c80 00051bc3 00051aa1 Mar 17 22:18:41 c862f3sq01 kernel: GPR16: 00051bbb c0a51280 Mar 17 22:18:41 c862f3sq01 kernel: GPR20: c0bda198 c0bda598 c0bda998 0002 Mar 17 22:18:41 c862f3sq01 kernel: GPR24: Mar 17 22:18:41 c862f3sq01 kernel: GPR28: c001dcdc2380 0001 c0961118 c001dcbbb680 Mar 17 22:18:41 c862f3sq01 kernel: NIP [c0498eac] .dev_watchdog+0x190/0x2cc Mar 17 22:18:41 c862f3sq01 kernel: LR [c0498d8c] .dev_watchdog+0x70/0x2cc Mar 17 22:18:41 c862f3sq01 kernel: Call Trace: Mar 17 22:18:41 c862f3sq01 kernel: [cf68fd00] [c0498d8c] .dev_watchdog+0x70/0x2cc (unreliable) Mar 17 22:18:41 c862f3sq01 kernel: [cf68fdc0] [c009cec4] .run_timer_softirq+0x1e8/0x2c4 Mar 17 22:18:41 c862f3sq01 kernel: [cf68fec0] [c009705c] .__do_softirq+0x13c/0x284 Mar 17
[E1000-devel] Missing VLAN Header
Hi, We are currently experimenting with vlan on a 10GE i82599 nic. Linux 2.6.18 with ixgbe version 2.0.62.4-NAPI is used on top of XEN 3.1.2. For the experiments we are using the following scenario: ---- ---- | domU.1 | | dom0.1 || dom0.2 | | domU.2 | | | | || | | | | 1.0.0.1 | | || | | 1.0.0.2 | | vlan100 | | bridge || bridge | | vlan100 | ||| | || || || | ||| | eth0 | | vif eth0 || vif eth0 | | eth0 | ---- ---- | || || | -- ---crossover--- --- 10GE-kable We now execute in domU.1 "ping 1.0.0.2". Unfortunately the ping-request is not answered. Running on dom0.1 "tcpdump -i eth0" gives (as expected): 16:44:21 vlan 100, p 0, ARP, Request who-has 1.0.0.2 tell 1.0.0.1, length 28 Running on dom0.2 "tcpdump -i eth0" gives: 16:44:21 ARP, Request who-has 1.0.0.2 tell 1.0.0.1, length 42 For some reason the vlan header is removed? Could anyone tell me why? Cheers Andreas PS: Running the same scenario using another gigabit nic and the igb driver, everything works. -- Andreas Grau Universitaet Stuttgart, IPVSphone : +49(0)711 7816-236 Universitaetsstraße 38 fax : +49(0)711 7816-424 D-70569 Stuttgart email : andreas.g...@ipvs.uni-stuttgart.de -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ 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] e1000e driver ChangeLog?
In the files/, there is occasionally a release.txt file with some incremental changes listed, but I don't see a ChangeLog for the e1000e driver. Where could I find that? Andy -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ 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
