Menu
▾
▴
e1000-devel — Discussion of the Intel Ethernet out-of-tree drivers
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
(1) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
|
Feb
|
Mar
(1) |
Apr
(9) |
May
(3) |
Jun
|
Jul
(3) |
Aug
(6) |
Sep
|
Oct
(7) |
Nov
|
Dec
|
| 2004 |
Jan
|
Feb
(5) |
Mar
(10) |
Apr
(2) |
May
(22) |
Jun
(8) |
Jul
(4) |
Aug
(8) |
Sep
(3) |
Oct
|
Nov
(36) |
Dec
(52) |
| 2005 |
Jan
(9) |
Feb
(13) |
Mar
(9) |
Apr
|
May
(14) |
Jun
(5) |
Jul
(20) |
Aug
(31) |
Sep
(2) |
Oct
(3) |
Nov
(18) |
Dec
(18) |
| 2006 |
Jan
(36) |
Feb
(16) |
Mar
(76) |
Apr
(78) |
May
(32) |
Jun
(30) |
Jul
(67) |
Aug
(43) |
Sep
(54) |
Oct
(116) |
Nov
(223) |
Dec
(158) |
| 2007 |
Jan
(180) |
Feb
(71) |
Mar
(110) |
Apr
(114) |
May
(203) |
Jun
(100) |
Jul
(238) |
Aug
(191) |
Sep
(177) |
Oct
(171) |
Nov
(211) |
Dec
(159) |
| 2008 |
Jan
(227) |
Feb
(288) |
Mar
(197) |
Apr
(253) |
May
(132) |
Jun
(152) |
Jul
(109) |
Aug
(143) |
Sep
(157) |
Oct
(198) |
Nov
(121) |
Dec
(147) |
| 2009 |
Jan
(105) |
Feb
(61) |
Mar
(191) |
Apr
(161) |
May
(118) |
Jun
(172) |
Jul
(166) |
Aug
(67) |
Sep
(86) |
Oct
(79) |
Nov
(118) |
Dec
(181) |
| 2010 |
Jan
(136) |
Feb
(154) |
Mar
(92) |
Apr
(83) |
May
(101) |
Jun
(66) |
Jul
(118) |
Aug
(78) |
Sep
(134) |
Oct
(131) |
Nov
(132) |
Dec
(104) |
| 2011 |
Jan
(79) |
Feb
(104) |
Mar
(144) |
Apr
(145) |
May
(130) |
Jun
(169) |
Jul
(146) |
Aug
(76) |
Sep
(113) |
Oct
(82) |
Nov
(145) |
Dec
(122) |
| 2012 |
Jan
(132) |
Feb
(106) |
Mar
(145) |
Apr
(238) |
May
(140) |
Jun
(162) |
Jul
(166) |
Aug
(147) |
Sep
(80) |
Oct
(148) |
Nov
(192) |
Dec
(90) |
| 2013 |
Jan
(139) |
Feb
(162) |
Mar
(174) |
Apr
(81) |
May
(261) |
Jun
(301) |
Jul
(106) |
Aug
(175) |
Sep
(305) |
Oct
(222) |
Nov
(95) |
Dec
(120) |
| 2014 |
Jan
(196) |
Feb
(171) |
Mar
(146) |
Apr
(118) |
May
(127) |
Jun
(93) |
Jul
(175) |
Aug
(66) |
Sep
(85) |
Oct
(120) |
Nov
(81) |
Dec
(192) |
| 2015 |
Jan
(141) |
Feb
(133) |
Mar
(189) |
Apr
(126) |
May
(59) |
Jun
(117) |
Jul
(56) |
Aug
(97) |
Sep
(44) |
Oct
(48) |
Nov
(33) |
Dec
(87) |
| 2016 |
Jan
(37) |
Feb
(56) |
Mar
(72) |
Apr
(65) |
May
(66) |
Jun
(65) |
Jul
(98) |
Aug
(54) |
Sep
(84) |
Oct
(68) |
Nov
(69) |
Dec
(60) |
| 2017 |
Jan
(30) |
Feb
(38) |
Mar
(53) |
Apr
(6) |
May
(2) |
Jun
(5) |
Jul
(15) |
Aug
(15) |
Sep
(7) |
Oct
(18) |
Nov
(23) |
Dec
(6) |
| 2018 |
Jan
(39) |
Feb
(5) |
Mar
(34) |
Apr
(26) |
May
(27) |
Jun
(5) |
Jul
(12) |
Aug
(4) |
Sep
|
Oct
(4) |
Nov
(4) |
Dec
(4) |
| 2019 |
Jan
(7) |
Feb
(10) |
Mar
(21) |
Apr
(26) |
May
(4) |
Jun
(5) |
Jul
(11) |
Aug
(6) |
Sep
(7) |
Oct
(13) |
Nov
(3) |
Dec
(17) |
| 2020 |
Jan
|
Feb
(3) |
Mar
(3) |
Apr
(5) |
May
(2) |
Jun
(5) |
Jul
|
Aug
|
Sep
(6) |
Oct
(7) |
Nov
(2) |
Dec
(7) |
| 2021 |
Jan
(9) |
Feb
(10) |
Mar
(18) |
Apr
(1) |
May
(3) |
Jun
|
Jul
(16) |
Aug
(2) |
Sep
|
Oct
|
Nov
(9) |
Dec
(2) |
| 2022 |
Jan
(3) |
Feb
|
Mar
(9) |
Apr
(8) |
May
(5) |
Jun
(6) |
Jul
(1) |
Aug
|
Sep
(1) |
Oct
|
Nov
(7) |
Dec
(2) |
| 2023 |
Jan
(7) |
Feb
(2) |
Mar
(6) |
Apr
|
May
(4) |
Jun
(2) |
Jul
(4) |
Aug
(3) |
Sep
(4) |
Oct
(2) |
Nov
(4) |
Dec
(10) |
| 2024 |
Jan
(4) |
Feb
(2) |
Mar
(1) |
Apr
|
May
(1) |
Jun
(1) |
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
1
(3) |
2
(1) |
3
(2) |
|
4
(1) |
5
(2) |
6
(1) |
7
(3) |
8
(4) |
9
(8) |
10
|
|
11
|
12
(3) |
13
(1) |
14
(4) |
15
(21) |
16
(11) |
17
(1) |
|
18
(2) |
19
(2) |
20
(5) |
21
(3) |
22
(1) |
23
(2) |
24
|
|
25
(3) |
26
(9) |
27
(2) |
28
(4) |
29
(12) |
30
(2) |
|
|
From: Ronciak, J. <joh...@in...> - 2011-09-30 04:58:25
|
Do the HW statistics show the driver dropping the packets? You can use ethtool to view the HW Ethernet stats of the ixgbe device. Please do so but I'm guessing that it's not the HW (or driver) dropping the packets. It's the stack. You can also use 'netstat -s' to see the stack statistics which may also show what's going on. Cheers, John > -----Original Message----- > From: Zhang Qianli [mailto:zh...@ce...] > Sent: Thursday, September 29, 2011 9:19 PM > To: e10...@li... > Subject: [E1000-devel] Possible problem in ixgbe driver? > > Dear Sirs: > We are using a linux bridge with two intel 10gb cards(82599) to > connect two routers. These two routers are running OSPF protocol. > Currently the problem is: > 1) Using IPv4, all is correct. > 2) Using IPv6, two routers can ping each other, but the ospf > protocol packets are dropped by linux bridge. > With tcpdump, we find that: > 1) All IPv4 packets are forwarded by linux bridge. > 2) For IPv6, unicast packts are forwarded, ICMPv6 neighbor > discovery packets (destined to 33:33:00:00:00:02) are also forwarded, > but OSPFv3 protocol packets (destined to 33:33:00:00:00:05) cannot be > forwarded. > The linux bridge has disabled IPv6. Since bridge will forward any > packets, we assume that possible ixgbe discard the multicast packets? > It is really very weird, will you give me some suggestions? Thank you! > Best regards > Qianli Zhang > > ----------------------------------------------------------------------- > ------- > All of the data generated in your IT infrastructure is seriously > valuable. > Why? It contains a definitive record of application performance, > security threats, fraudulent activity, and more. Splunk takes this data > and makes sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-d2dcopy2 > _______________________________________________ > E1000-devel mailing list > E10...@li... > https://lists.sourceforge.net/lists/listinfo/e1000-devel > To learn more about Intel® Ethernet, visit > http://communities.intel.com/community/wired |
|
From: Zhang Q. <zh...@ce...> - 2011-09-30 04:35:36
|
Dear Sirs:
We are using a linux bridge with two intel 10gb cards(82599) to
connect two routers. These two routers are running OSPF protocol.
Currently the problem is:
1) Using IPv4, all is correct.
2) Using IPv6, two routers can ping each other, but the ospf protocol
packets are dropped by linux bridge.
With tcpdump, we find that:
1) All IPv4 packets are forwarded by linux bridge.
2) For IPv6, unicast packts are forwarded, ICMPv6 neighbor discovery
packets (destined to 33:33:00:00:00:02) are also forwarded, but OSPFv3
protocol packets (destined to 33:33:00:00:00:05) cannot be forwarded.
The linux bridge has disabled IPv6. Since bridge will forward any
packets, we assume that possible ixgbe discard the multicast packets? It
is really very weird, will you give me some suggestions? Thank you!
Best regards
Qianli Zhang
|
|
From: Travis M. <tra...@ao...> - 2011-09-29 22:08:39
|
http://gammessud.com/shop/photo.php?html2 |
|
From: Allan, B. W <bru...@in...> - 2011-09-29 16:49:25
|
>-----Original Message----- >From: Jeff Kirsher [mailto:jef...@in...] >Sent: Thursday, September 29, 2011 6:01 AM >To: Indira ramasamy >Cc: E10...@li... >Subject: Re: [E1000-devel] Regarding - Detected Tx Unit Hang > >On Thu, Sep 29, 2011 at 05:05, Indira ramasamy <vel...@gm...> wrote: >> Hi, >> >> I am using e1000e driver(version: 0.4.1.12-NAPI, firmware-version: 5.10-2) >> . In dmesg I am seeing >> 0000:00:19.0: eth0: Detected Tx Unit Hang: >> TDH <b7> >> TDT <a3> >> next_to_use <a3> >> next_to_clean <b7> >> buffer_info[next_to_clean]: >> time_stamp <358fd1e> >> next_to_watch <b7> >> jiffies <3590670> >> next_to_watch.status <0> >> 0000:00:19.0: eth0: Detected Tx Unit Hang: >> TDH <b7> >> TDT <a3> >> next_to_use <a3> >> next_to_clean <b7> >> buffer_info[next_to_clean]: >> time_stamp <358fd1e> >> next_to_watch <b7> >> jiffies <3590e40> >> next_to_watch.status <0> >> 0000:00:19.0: eth0: Detected Tx Unit Hang: >> TDH <b7> >> TDT <a3> >> next_to_use <a3> >> next_to_clean <b7> >> buffer_info[next_to_clean]: >> time_stamp <358fd1e> >> next_to_watch <b7> >> jiffies <3591610> >> next_to_watch.status <0> >> 0000:00:19.0: eth0: Detected Tx Unit Hang: >> TDH <b7> >> TDT <a3> >> next_to_use <a3> >> next_to_clean <b7> >> buffer_info[next_to_clean]: >> time_stamp <358fd1e> >> next_to_watch <b7> >> jiffies <3591de0> >> next_to_watch.status <0> >> NETDEV WATCHDOG: eth0: transmit timed out >> 0000:00:19.0: eth0: Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX >> >> My Nic card is, >> 00:19.0 Ethernet controller: Intel Corporation 82566DM-2 Gigabit Network >> Connection (rev 02) >> >> Can you please suggest me, how will I fix this issue. >> >> Thanks, >> Indira. >> >> > >What kernel are you running? (uname -r) > >-- >Cheers, >Jeff The driver version you are using is nearly 3 years old. Many changes have gone into the driver since then so it is recommended to try the latest version on http://sourceforge.net/projects/e1000/files/e1000e%20stable/. If the problem still persists, please file a detailed bug tracker at http://sourceforge.net/tracker/?group_id=42302&atid=447449. |
|
From: Allan, B. W <bru...@in...> - 2011-09-29 16:44:13
|
>-----Original Message----- >From: Carsten Aulbert [mailto:Car...@ae...] >Sent: Wednesday, September 28, 2011 11:42 PM >To: Brandeburg, Jesse >Cc: e10...@li...; Tejun Heo >Subject: Re: [E1000-devel] Possible to stop external IPMI/BMC access (port 623) >by bringing iface up? > >Hi Jesse > >On Thursday 29 September 2011 01:12:19 Jesse Brandeburg wrote: >> This is probably the driver touching a register that prevents IPMI >> traffic from flowing to the bmc. It may be a patch that Debian made >> that broke it, I don't generally track debian's forks of the kernel. :-) >> > >At least I can rule that one out as it's a self-compiled 2.6.32.28 or >2.6.32.46 - and I'm using exactly the same binary kernel package >> Can you send the output from the ethregs tool before down/after down. >> >> ethregs is available on e1000.sf.net in the downloads area. > >Attached tarball with 4 files > >ethregs.{lenny,squeeze}.{down,up} > >which should cover all 4 cases hopefully well enough. > >Just in case you need it: > >lenny: >n1570:/tmp/ethregs-1.13.0# modinfo e1000e >filename: /lib/modules/2.6.32.28-atlas- >generic/kernel/drivers/net/e1000e/e1000e.ko >version: 1.0.2-k2 >license: GPL >description: Intel(R) PRO/1000 Network Driver >author: Intel Corporation, <lin...@in...> >srcversion: AF3F52EBD9A435E0A141B19 >[...] > >squeeze: >root@n1670:~# modinfo e1000e >filename: /lib/modules/2.6.32.28-atlas- >generic/kernel/drivers/net/e1000e/e1000e.ko >version: 1.0.2-k2 >license: GPL >description: Intel(R) PRO/1000 Network Driver >author: Intel Corporation, <lin...@in...> >srcversion: AF3F52EBD9A435E0A141B19 > >HTH > >Carsten Please file a bug tracker for this issue at http://sourceforge.net/tracker/?group_id=42302&atid=447449 and include all the information presented in this thread. |
|
From: Allan, B. W <bru...@in...> - 2011-09-29 16:38:22
|
>-----Original Message----- >From: joeyli [mailto:jl...@su...] >Sent: Wednesday, September 28, 2011 10:33 PM >To: Dave Young >Cc: e10...@li...; lin...@vg... >Subject: Re: [E1000-devel] [BUG?] e1000e Detected Hardware Unit Hang > >於 四，2011-09-29 於 13:37 +0800，Dave Young 提到： >> On 09/29/2011 01:28 PM, joeyli wrote: >> >> > Hi Dave, >> > >> > 於 四，2011-09-29 於 10:41 +0800，Dave Young 提到： >> >> Hi, >> >> >> >> suspend to ram, after resume, I got below info: (attached the full dmesg) >> >> >> >> [106900.343520] e1000e 0000:00:19.0: eth0: Detected Hardware Unit Hang: >> >> [106900.343521] TDH <1> >> >> [106900.343522] TDT <2> >> >> [106900.343523] next_to_use <2> >> >> [106900.343523] next_to_clean <1> >> >> [106900.343524] buffer_info[next_to_clean]: >> >> [106900.343525] time_stamp <101e7f773> >> >> [106900.343526] next_to_watch <1> >> >> [106900.343526] jiffies <101e7fa4a> >> >> [106900.343527] next_to_watch.status <0> >> >> [106900.343528] MAC Status <80683> >> >> [106900.343529] PHY Status <796d> >> >> [106900.343529] PHY 1000BASE-T Status <3800> >> >> [106900.343530] PHY Extended Status <3000> >> >> [106900.343531] PCI Status <10> >> >> [106902.342904] e1000e 0000:00:19.0: eth0: Detected Hardware Unit Hang: >> >> [106902.342905] TDH <1> >> >> [106902.342906] TDT <2> >> >> [106902.342907] next_to_use <2> >> >> [106902.342907] next_to_clean <1> >> >> [106902.342908] buffer_info[next_to_clean]: >> >> [106902.342909] time_stamp <101e7f773> >> >> [106902.342909] next_to_watch <1> >> >> [106902.342910] jiffies <101e7fca2> >> >> [106902.342911] next_to_watch.status <0> >> >> [106902.342912] MAC Status <80683> >> >> [106902.342912] PHY Status <796d> >> >> [106902.342913] PHY 1000BASE-T Status <3800> >> >> [106902.342914] PHY Extended Status <3000> >> >> [106902.342915] PCI Status <10> >> >> [106903.349326] ------------[ cut here ]------------ >> >> [106903.349336] WARNING: at net/sched/sch_generic.c:255 >> >> dev_watchdog+0xeb/0x14b() >> >> [106903.349339] Hardware name: OptiPlex 760 >> >> [106903.349342] NETDEV WATCHDOG: eth0 (e1000e): transmit queue 0 timed out >> >> [106903.349344] Modules linked in: cdc_ether usbnet mii tun kvm_intel >> >> kvm snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device >> >> snd_pcm_oss snd_mixer_oss fuse snd_hda_codec_analog snd_hda_intel >> >> snd_hda_codec snd_hwdep snd_pcm radeon snd_timer snd_page_alloc ttm >> >> dell_wmi sparse_keymap wmi >> >> [106903.349379] Pid: 0, comm: swapper Not tainted 3.1.0-rc6+ #202 >> >> [106903.349382] Call Trace: >> >> [106903.349384] <IRQ> [<ffffffff8103c5a7>] warn_slowpath_common+0x80/0x98 >> >> [106903.349394] [<ffffffff8103c653>] warn_slowpath_fmt+0x41/0x43 >> >> [106903.349399] [<ffffffff81560149>] dev_watchdog+0xeb/0x14b >> >> [106903.349404] [<ffffffff810497c6>] run_timer_softirq+0x217/0x300 >> >> [106903.349408] [<ffffffff81049733>] ? run_timer_softirq+0x184/0x300 >> >> [106903.349413] [<ffffffff8156005e>] ? netif_tx_unlock+0x51/0x51 >> >> [106903.349419] [<ffffffff810423c6>] __do_softirq+0xe2/0x1bc >> >> [106903.349424] [<ffffffff81007a81>] ? paravirt_read_tsc+0x9/0xd >> >> [106903.349428] [<ffffffff81007fc8>] ? sched_clock+0x9/0xd >> >> [106903.349434] [<ffffffff8160063c>] call_softirq+0x1c/0x30 >> >> [106903.349438] [<ffffffff81003ba2>] do_softirq+0x46/0x9c >> >> [106903.349442] [<ffffffff81042696>] irq_exit+0x5b/0xbe >> >> [106903.349446] [<ffffffff8100384a>] do_IRQ+0x89/0xa0 >> >> [106903.349452] [<ffffffff815f8e33>] common_interrupt+0x73/0x73 >> >> [106903.349454] <EOI> [<ffffffff81008d81>] ? mwait_idle+0x8a/0xc1 >> >> [106903.349462] [<ffffffff81008d78>] ? mwait_idle+0x81/0xc1 >> >> [106903.349467] [<ffffffff810012ab>] cpu_idle+0xb3/0xd5 >> >> [106903.349473] [<ffffffff815d8dbe>] rest_init+0xb2/0xb9 >> >> [106903.349477] [<ffffffff815d8d0c>] ? >> >> csum_partial_copy_generic+0x16c/0x16c >> >> [106903.349483] [<ffffffff81a22b49>] start_kernel+0x390/0x39b >> >> [106903.349487] [<ffffffff81a222af>] x86_64_start_reservations+0xb6/0xba >> >> [106903.349491] [<ffffffff81a223b4>] x86_64_start_kernel+0x101/0x110 >> >> [106903.349495] ---[ end trace 1d36d9ed335e092c ]--- >> >> [106903.349722] e1000e 0000:00:19.0: eth0: Reset adapter >> >> >> > >> > What's your kernel version? >> >> >> My info: >> >> bash-4.1$ uname -a >> Linux darkstar 3.1.0-rc6+ #202 SMP Tue Sep 20 12:55:02 HKT 2011 x86_64 >> Intel(R) Core(TM)2 Quad CPU Q9400 @ 2.66GHz GenuineIntel GNU/Linux >> >> bash-4.1$ lspci|grep Ethernet >> 00:19.0 Ethernet controller: Intel Corporation 82567LM-3 Gigabit Network >> Connection (rev 02) >> > >My pci info: >06:00.0 Ethernet controller: Intel Corporation 80003ES2LAN Gigabit >Ethernet Controller (Copper) (rev 01) > >> > >> > On my machine also have the same problem, but don't need suspend/resume, >> > just need BOOT and WAIT!! >> > Sometimes just need wait 35 - 45 minutes, but sometimes just need wait 3 >> > minutes. >> > >> > My kernel version is v3.0. >> > >> > > > >Thank's >Joey Lee These sound like two different issues. Please file separate bug trackers for each issue at http://sourceforge.net/tracker/?group_id=42302&atid=447449 and include kernel version, driver version, lspci -vvv output and system log message including the Hardware Unit Hang message and stack trace. |
|
From: Jeff K. <jef...@in...> - 2011-09-29 13:01:04
|
On Thu, Sep 29, 2011 at 05:05, Indira ramasamy <vel...@gm...> wrote: > Hi, > > I am using e1000e driver(version: 0.4.1.12-NAPI, firmware-version: 5.10-2) > . In dmesg I am seeing > 0000:00:19.0: eth0: Detected Tx Unit Hang: > TDH <b7> > TDT <a3> > next_to_use <a3> > next_to_clean <b7> > buffer_info[next_to_clean]: > time_stamp <358fd1e> > next_to_watch <b7> > jiffies <3590670> > next_to_watch.status <0> > 0000:00:19.0: eth0: Detected Tx Unit Hang: > TDH <b7> > TDT <a3> > next_to_use <a3> > next_to_clean <b7> > buffer_info[next_to_clean]: > time_stamp <358fd1e> > next_to_watch <b7> > jiffies <3590e40> > next_to_watch.status <0> > 0000:00:19.0: eth0: Detected Tx Unit Hang: > TDH <b7> > TDT <a3> > next_to_use <a3> > next_to_clean <b7> > buffer_info[next_to_clean]: > time_stamp <358fd1e> > next_to_watch <b7> > jiffies <3591610> > next_to_watch.status <0> > 0000:00:19.0: eth0: Detected Tx Unit Hang: > TDH <b7> > TDT <a3> > next_to_use <a3> > next_to_clean <b7> > buffer_info[next_to_clean]: > time_stamp <358fd1e> > next_to_watch <b7> > jiffies <3591de0> > next_to_watch.status <0> > NETDEV WATCHDOG: eth0: transmit timed out > 0000:00:19.0: eth0: Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX > > My Nic card is, > 00:19.0 Ethernet controller: Intel Corporation 82566DM-2 Gigabit Network > Connection (rev 02) > > Can you please suggest me, how will I fix this issue. > > Thanks, > Indira. > > What kernel are you running? (uname -r) -- Cheers, Jeff |
|
From: Indira r. <vel...@gm...> - 2011-09-29 12:05:24
|
Hi, I am using e1000e driver(version: 0.4.1.12-NAPI, firmware-version: 5.10-2) . In dmesg I am seeing 0000:00:19.0: eth0: Detected Tx Unit Hang: TDH <b7> TDT <a3> next_to_use <a3> next_to_clean <b7> buffer_info[next_to_clean]: time_stamp <358fd1e> next_to_watch <b7> jiffies <3590670> next_to_watch.status <0> 0000:00:19.0: eth0: Detected Tx Unit Hang: TDH <b7> TDT <a3> next_to_use <a3> next_to_clean <b7> buffer_info[next_to_clean]: time_stamp <358fd1e> next_to_watch <b7> jiffies <3590e40> next_to_watch.status <0> 0000:00:19.0: eth0: Detected Tx Unit Hang: TDH <b7> TDT <a3> next_to_use <a3> next_to_clean <b7> buffer_info[next_to_clean]: time_stamp <358fd1e> next_to_watch <b7> jiffies <3591610> next_to_watch.status <0> 0000:00:19.0: eth0: Detected Tx Unit Hang: TDH <b7> TDT <a3> next_to_use <a3> next_to_clean <b7> buffer_info[next_to_clean]: time_stamp <358fd1e> next_to_watch <b7> jiffies <3591de0> next_to_watch.status <0> NETDEV WATCHDOG: eth0: transmit timed out 0000:00:19.0: eth0: Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX My Nic card is, 00:19.0 Ethernet controller: Intel Corporation 82566DM-2 Gigabit Network Connection (rev 02) Can you please suggest me, how will I fix this issue. Thanks, Indira. |
|
From: Carsten A. <Car...@ae...> - 2011-09-29 06:41:54
|
Hi Jesse On Thursday 29 September 2011 01:12:19 Jesse Brandeburg wrote: > This is probably the driver touching a register that prevents IPMI > traffic from flowing to the bmc. It may be a patch that Debian made > that broke it, I don't generally track debian's forks of the kernel. :-) > At least I can rule that one out as it's a self-compiled 2.6.32.28 or 2.6.32.46 - and I'm using exactly the same binary kernel package > Can you send the output from the ethregs tool before down/after down. > > ethregs is available on e1000.sf.net in the downloads area. Attached tarball with 4 files ethregs.{lenny,squeeze}.{down,up} which should cover all 4 cases hopefully well enough. Just in case you need it: lenny: n1570:/tmp/ethregs-1.13.0# modinfo e1000e filename: /lib/modules/2.6.32.28-atlas- generic/kernel/drivers/net/e1000e/e1000e.ko version: 1.0.2-k2 license: GPL description: Intel(R) PRO/1000 Network Driver author: Intel Corporation, <lin...@in...> srcversion: AF3F52EBD9A435E0A141B19 [...] squeeze: root@n1670:~# modinfo e1000e filename: /lib/modules/2.6.32.28-atlas- generic/kernel/drivers/net/e1000e/e1000e.ko version: 1.0.2-k2 license: GPL description: Intel(R) PRO/1000 Network Driver author: Intel Corporation, <lin...@in...> srcversion: AF3F52EBD9A435E0A141B19 HTH Carsten |
|
From: Bokhan A. <ar...@em...> - 2011-09-29 06:09:14
|
29.09.2011 1:23, Carsten Aulbert пишет: > But now we reinstalled several machines with Debian Squeeze and suddenly we > can only query the BMC when eth0 is down. The same with ubuntu LTS 10.04 (2.6.32) and latest e1000 drivers from sf.net. We have some hardware with AOC-SIMSO IPMI modules. |
|
From: joeyli <jl...@su...> - 2011-09-29 05:38:24
|
於 四，2011-09-29 於 13:37 +0800，Dave Young 提到： > On 09/29/2011 01:28 PM, joeyli wrote: > > > Hi Dave, > > > > 於 四，2011-09-29 於 10:41 +0800，Dave Young 提到： > >> Hi, > >> > >> suspend to ram, after resume, I got below info: (attached the full dmesg) > >> > >> [106900.343520] e1000e 0000:00:19.0: eth0: Detected Hardware Unit Hang: > >> [106900.343521] TDH <1> > >> [106900.343522] TDT <2> > >> [106900.343523] next_to_use <2> > >> [106900.343523] next_to_clean <1> > >> [106900.343524] buffer_info[next_to_clean]: > >> [106900.343525] time_stamp <101e7f773> > >> [106900.343526] next_to_watch <1> > >> [106900.343526] jiffies <101e7fa4a> > >> [106900.343527] next_to_watch.status <0> > >> [106900.343528] MAC Status <80683> > >> [106900.343529] PHY Status <796d> > >> [106900.343529] PHY 1000BASE-T Status <3800> > >> [106900.343530] PHY Extended Status <3000> > >> [106900.343531] PCI Status <10> > >> [106902.342904] e1000e 0000:00:19.0: eth0: Detected Hardware Unit Hang: > >> [106902.342905] TDH <1> > >> [106902.342906] TDT <2> > >> [106902.342907] next_to_use <2> > >> [106902.342907] next_to_clean <1> > >> [106902.342908] buffer_info[next_to_clean]: > >> [106902.342909] time_stamp <101e7f773> > >> [106902.342909] next_to_watch <1> > >> [106902.342910] jiffies <101e7fca2> > >> [106902.342911] next_to_watch.status <0> > >> [106902.342912] MAC Status <80683> > >> [106902.342912] PHY Status <796d> > >> [106902.342913] PHY 1000BASE-T Status <3800> > >> [106902.342914] PHY Extended Status <3000> > >> [106902.342915] PCI Status <10> > >> [106903.349326] ------------[ cut here ]------------ > >> [106903.349336] WARNING: at net/sched/sch_generic.c:255 > >> dev_watchdog+0xeb/0x14b() > >> [106903.349339] Hardware name: OptiPlex 760 > >> [106903.349342] NETDEV WATCHDOG: eth0 (e1000e): transmit queue 0 timed out > >> [106903.349344] Modules linked in: cdc_ether usbnet mii tun kvm_intel > >> kvm snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device > >> snd_pcm_oss snd_mixer_oss fuse snd_hda_codec_analog snd_hda_intel > >> snd_hda_codec snd_hwdep snd_pcm radeon snd_timer snd_page_alloc ttm > >> dell_wmi sparse_keymap wmi > >> [106903.349379] Pid: 0, comm: swapper Not tainted 3.1.0-rc6+ #202 > >> [106903.349382] Call Trace: > >> [106903.349384] <IRQ> [<ffffffff8103c5a7>] warn_slowpath_common+0x80/0x98 > >> [106903.349394] [<ffffffff8103c653>] warn_slowpath_fmt+0x41/0x43 > >> [106903.349399] [<ffffffff81560149>] dev_watchdog+0xeb/0x14b > >> [106903.349404] [<ffffffff810497c6>] run_timer_softirq+0x217/0x300 > >> [106903.349408] [<ffffffff81049733>] ? run_timer_softirq+0x184/0x300 > >> [106903.349413] [<ffffffff8156005e>] ? netif_tx_unlock+0x51/0x51 > >> [106903.349419] [<ffffffff810423c6>] __do_softirq+0xe2/0x1bc > >> [106903.349424] [<ffffffff81007a81>] ? paravirt_read_tsc+0x9/0xd > >> [106903.349428] [<ffffffff81007fc8>] ? sched_clock+0x9/0xd > >> [106903.349434] [<ffffffff8160063c>] call_softirq+0x1c/0x30 > >> [106903.349438] [<ffffffff81003ba2>] do_softirq+0x46/0x9c > >> [106903.349442] [<ffffffff81042696>] irq_exit+0x5b/0xbe > >> [106903.349446] [<ffffffff8100384a>] do_IRQ+0x89/0xa0 > >> [106903.349452] [<ffffffff815f8e33>] common_interrupt+0x73/0x73 > >> [106903.349454] <EOI> [<ffffffff81008d81>] ? mwait_idle+0x8a/0xc1 > >> [106903.349462] [<ffffffff81008d78>] ? mwait_idle+0x81/0xc1 > >> [106903.349467] [<ffffffff810012ab>] cpu_idle+0xb3/0xd5 > >> [106903.349473] [<ffffffff815d8dbe>] rest_init+0xb2/0xb9 > >> [106903.349477] [<ffffffff815d8d0c>] ? > >> csum_partial_copy_generic+0x16c/0x16c > >> [106903.349483] [<ffffffff81a22b49>] start_kernel+0x390/0x39b > >> [106903.349487] [<ffffffff81a222af>] x86_64_start_reservations+0xb6/0xba > >> [106903.349491] [<ffffffff81a223b4>] x86_64_start_kernel+0x101/0x110 > >> [106903.349495] ---[ end trace 1d36d9ed335e092c ]--- > >> [106903.349722] e1000e 0000:00:19.0: eth0: Reset adapter > >> > > > > What's your kernel version? > > > My info: > > bash-4.1$ uname -a > Linux darkstar 3.1.0-rc6+ #202 SMP Tue Sep 20 12:55:02 HKT 2011 x86_64 > Intel(R) Core(TM)2 Quad CPU Q9400 @ 2.66GHz GenuineIntel GNU/Linux > > bash-4.1$ lspci|grep Ethernet > 00:19.0 Ethernet controller: Intel Corporation 82567LM-3 Gigabit Network > Connection (rev 02) > My pci info: 06:00.0 Ethernet controller: Intel Corporation 80003ES2LAN Gigabit Ethernet Controller (Copper) (rev 01) > > > > On my machine also have the same problem, but don't need suspend/resume, > > just need BOOT and WAIT!! > > Sometimes just need wait 35 - 45 minutes, but sometimes just need wait 3 > > minutes. > > > > My kernel version is v3.0. > > > > Thank's Joey Lee |
|
From: Dave Y. <dy...@re...> - 2011-09-29 05:35:42
|
On 09/29/2011 01:28 PM, joeyli wrote: > Hi Dave, > > 於 四，2011-09-29 於 10:41 +0800，Dave Young 提到： >> Hi, >> >> suspend to ram, after resume, I got below info: (attached the full dmesg) >> >> [106900.343520] e1000e 0000:00:19.0: eth0: Detected Hardware Unit Hang: >> [106900.343521] TDH <1> >> [106900.343522] TDT <2> >> [106900.343523] next_to_use <2> >> [106900.343523] next_to_clean <1> >> [106900.343524] buffer_info[next_to_clean]: >> [106900.343525] time_stamp <101e7f773> >> [106900.343526] next_to_watch <1> >> [106900.343526] jiffies <101e7fa4a> >> [106900.343527] next_to_watch.status <0> >> [106900.343528] MAC Status <80683> >> [106900.343529] PHY Status <796d> >> [106900.343529] PHY 1000BASE-T Status <3800> >> [106900.343530] PHY Extended Status <3000> >> [106900.343531] PCI Status <10> >> [106902.342904] e1000e 0000:00:19.0: eth0: Detected Hardware Unit Hang: >> [106902.342905] TDH <1> >> [106902.342906] TDT <2> >> [106902.342907] next_to_use <2> >> [106902.342907] next_to_clean <1> >> [106902.342908] buffer_info[next_to_clean]: >> [106902.342909] time_stamp <101e7f773> >> [106902.342909] next_to_watch <1> >> [106902.342910] jiffies <101e7fca2> >> [106902.342911] next_to_watch.status <0> >> [106902.342912] MAC Status <80683> >> [106902.342912] PHY Status <796d> >> [106902.342913] PHY 1000BASE-T Status <3800> >> [106902.342914] PHY Extended Status <3000> >> [106902.342915] PCI Status <10> >> [106903.349326] ------------[ cut here ]------------ >> [106903.349336] WARNING: at net/sched/sch_generic.c:255 >> dev_watchdog+0xeb/0x14b() >> [106903.349339] Hardware name: OptiPlex 760 >> [106903.349342] NETDEV WATCHDOG: eth0 (e1000e): transmit queue 0 timed out >> [106903.349344] Modules linked in: cdc_ether usbnet mii tun kvm_intel >> kvm snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device >> snd_pcm_oss snd_mixer_oss fuse snd_hda_codec_analog snd_hda_intel >> snd_hda_codec snd_hwdep snd_pcm radeon snd_timer snd_page_alloc ttm >> dell_wmi sparse_keymap wmi >> [106903.349379] Pid: 0, comm: swapper Not tainted 3.1.0-rc6+ #202 >> [106903.349382] Call Trace: >> [106903.349384] <IRQ> [<ffffffff8103c5a7>] warn_slowpath_common+0x80/0x98 >> [106903.349394] [<ffffffff8103c653>] warn_slowpath_fmt+0x41/0x43 >> [106903.349399] [<ffffffff81560149>] dev_watchdog+0xeb/0x14b >> [106903.349404] [<ffffffff810497c6>] run_timer_softirq+0x217/0x300 >> [106903.349408] [<ffffffff81049733>] ? run_timer_softirq+0x184/0x300 >> [106903.349413] [<ffffffff8156005e>] ? netif_tx_unlock+0x51/0x51 >> [106903.349419] [<ffffffff810423c6>] __do_softirq+0xe2/0x1bc >> [106903.349424] [<ffffffff81007a81>] ? paravirt_read_tsc+0x9/0xd >> [106903.349428] [<ffffffff81007fc8>] ? sched_clock+0x9/0xd >> [106903.349434] [<ffffffff8160063c>] call_softirq+0x1c/0x30 >> [106903.349438] [<ffffffff81003ba2>] do_softirq+0x46/0x9c >> [106903.349442] [<ffffffff81042696>] irq_exit+0x5b/0xbe >> [106903.349446] [<ffffffff8100384a>] do_IRQ+0x89/0xa0 >> [106903.349452] [<ffffffff815f8e33>] common_interrupt+0x73/0x73 >> [106903.349454] <EOI> [<ffffffff81008d81>] ? mwait_idle+0x8a/0xc1 >> [106903.349462] [<ffffffff81008d78>] ? mwait_idle+0x81/0xc1 >> [106903.349467] [<ffffffff810012ab>] cpu_idle+0xb3/0xd5 >> [106903.349473] [<ffffffff815d8dbe>] rest_init+0xb2/0xb9 >> [106903.349477] [<ffffffff815d8d0c>] ? >> csum_partial_copy_generic+0x16c/0x16c >> [106903.349483] [<ffffffff81a22b49>] start_kernel+0x390/0x39b >> [106903.349487] [<ffffffff81a222af>] x86_64_start_reservations+0xb6/0xba >> [106903.349491] [<ffffffff81a223b4>] x86_64_start_kernel+0x101/0x110 >> [106903.349495] ---[ end trace 1d36d9ed335e092c ]--- >> [106903.349722] e1000e 0000:00:19.0: eth0: Reset adapter >> > > What's your kernel version? My info: bash-4.1$ uname -a Linux darkstar 3.1.0-rc6+ #202 SMP Tue Sep 20 12:55:02 HKT 2011 x86_64 Intel(R) Core(TM)2 Quad CPU Q9400 @ 2.66GHz GenuineIntel GNU/Linux bash-4.1$ lspci|grep Ethernet 00:19.0 Ethernet controller: Intel Corporation 82567LM-3 Gigabit Network Connection (rev 02) > > On my machine also have the same problem, but don't need suspend/resume, > just need BOOT and WAIT!! > Sometimes just need wait 35 - 45 minutes, but sometimes just need wait 3 > minutes. > > My kernel version is v3.0. > > > Thank's > Joey Lee > -- Thanks Dave |
|
From: joeyli <jl...@su...> - 2011-09-29 05:34:09
|
Hi Dave, 於 四，2011-09-29 於 10:41 +0800，Dave Young 提到： > Hi, > > suspend to ram, after resume, I got below info: (attached the full dmesg) > > [106900.343520] e1000e 0000:00:19.0: eth0: Detected Hardware Unit Hang: > [106900.343521] TDH <1> > [106900.343522] TDT <2> > [106900.343523] next_to_use <2> > [106900.343523] next_to_clean <1> > [106900.343524] buffer_info[next_to_clean]: > [106900.343525] time_stamp <101e7f773> > [106900.343526] next_to_watch <1> > [106900.343526] jiffies <101e7fa4a> > [106900.343527] next_to_watch.status <0> > [106900.343528] MAC Status <80683> > [106900.343529] PHY Status <796d> > [106900.343529] PHY 1000BASE-T Status <3800> > [106900.343530] PHY Extended Status <3000> > [106900.343531] PCI Status <10> > [106902.342904] e1000e 0000:00:19.0: eth0: Detected Hardware Unit Hang: > [106902.342905] TDH <1> > [106902.342906] TDT <2> > [106902.342907] next_to_use <2> > [106902.342907] next_to_clean <1> > [106902.342908] buffer_info[next_to_clean]: > [106902.342909] time_stamp <101e7f773> > [106902.342909] next_to_watch <1> > [106902.342910] jiffies <101e7fca2> > [106902.342911] next_to_watch.status <0> > [106902.342912] MAC Status <80683> > [106902.342912] PHY Status <796d> > [106902.342913] PHY 1000BASE-T Status <3800> > [106902.342914] PHY Extended Status <3000> > [106902.342915] PCI Status <10> > [106903.349326] ------------[ cut here ]------------ > [106903.349336] WARNING: at net/sched/sch_generic.c:255 > dev_watchdog+0xeb/0x14b() > [106903.349339] Hardware name: OptiPlex 760 > [106903.349342] NETDEV WATCHDOG: eth0 (e1000e): transmit queue 0 timed out > [106903.349344] Modules linked in: cdc_ether usbnet mii tun kvm_intel > kvm snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device > snd_pcm_oss snd_mixer_oss fuse snd_hda_codec_analog snd_hda_intel > snd_hda_codec snd_hwdep snd_pcm radeon snd_timer snd_page_alloc ttm > dell_wmi sparse_keymap wmi > [106903.349379] Pid: 0, comm: swapper Not tainted 3.1.0-rc6+ #202 > [106903.349382] Call Trace: > [106903.349384] <IRQ> [<ffffffff8103c5a7>] warn_slowpath_common+0x80/0x98 > [106903.349394] [<ffffffff8103c653>] warn_slowpath_fmt+0x41/0x43 > [106903.349399] [<ffffffff81560149>] dev_watchdog+0xeb/0x14b > [106903.349404] [<ffffffff810497c6>] run_timer_softirq+0x217/0x300 > [106903.349408] [<ffffffff81049733>] ? run_timer_softirq+0x184/0x300 > [106903.349413] [<ffffffff8156005e>] ? netif_tx_unlock+0x51/0x51 > [106903.349419] [<ffffffff810423c6>] __do_softirq+0xe2/0x1bc > [106903.349424] [<ffffffff81007a81>] ? paravirt_read_tsc+0x9/0xd > [106903.349428] [<ffffffff81007fc8>] ? sched_clock+0x9/0xd > [106903.349434] [<ffffffff8160063c>] call_softirq+0x1c/0x30 > [106903.349438] [<ffffffff81003ba2>] do_softirq+0x46/0x9c > [106903.349442] [<ffffffff81042696>] irq_exit+0x5b/0xbe > [106903.349446] [<ffffffff8100384a>] do_IRQ+0x89/0xa0 > [106903.349452] [<ffffffff815f8e33>] common_interrupt+0x73/0x73 > [106903.349454] <EOI> [<ffffffff81008d81>] ? mwait_idle+0x8a/0xc1 > [106903.349462] [<ffffffff81008d78>] ? mwait_idle+0x81/0xc1 > [106903.349467] [<ffffffff810012ab>] cpu_idle+0xb3/0xd5 > [106903.349473] [<ffffffff815d8dbe>] rest_init+0xb2/0xb9 > [106903.349477] [<ffffffff815d8d0c>] ? > csum_partial_copy_generic+0x16c/0x16c > [106903.349483] [<ffffffff81a22b49>] start_kernel+0x390/0x39b > [106903.349487] [<ffffffff81a222af>] x86_64_start_reservations+0xb6/0xba > [106903.349491] [<ffffffff81a223b4>] x86_64_start_kernel+0x101/0x110 > [106903.349495] ---[ end trace 1d36d9ed335e092c ]--- > [106903.349722] e1000e 0000:00:19.0: eth0: Reset adapter > What's your kernel version? On my machine also have the same problem, but don't need suspend/resume, just need BOOT and WAIT!! Sometimes just need wait 35 - 45 minutes, but sometimes just need wait 3 minutes. My kernel version is v3.0. Thank's Joey Lee |
|
From: Dave Y. <dy...@re...> - 2011-09-29 02:40:04
|
Hi, suspend to ram, after resume, I got below info: (attached the full dmesg) [106900.343520] e1000e 0000:00:19.0: eth0: Detected Hardware Unit Hang: [106900.343521] TDH <1> [106900.343522] TDT <2> [106900.343523] next_to_use <2> [106900.343523] next_to_clean <1> [106900.343524] buffer_info[next_to_clean]: [106900.343525] time_stamp <101e7f773> [106900.343526] next_to_watch <1> [106900.343526] jiffies <101e7fa4a> [106900.343527] next_to_watch.status <0> [106900.343528] MAC Status <80683> [106900.343529] PHY Status <796d> [106900.343529] PHY 1000BASE-T Status <3800> [106900.343530] PHY Extended Status <3000> [106900.343531] PCI Status <10> [106902.342904] e1000e 0000:00:19.0: eth0: Detected Hardware Unit Hang: [106902.342905] TDH <1> [106902.342906] TDT <2> [106902.342907] next_to_use <2> [106902.342907] next_to_clean <1> [106902.342908] buffer_info[next_to_clean]: [106902.342909] time_stamp <101e7f773> [106902.342909] next_to_watch <1> [106902.342910] jiffies <101e7fca2> [106902.342911] next_to_watch.status <0> [106902.342912] MAC Status <80683> [106902.342912] PHY Status <796d> [106902.342913] PHY 1000BASE-T Status <3800> [106902.342914] PHY Extended Status <3000> [106902.342915] PCI Status <10> [106903.349326] ------------[ cut here ]------------ [106903.349336] WARNING: at net/sched/sch_generic.c:255 dev_watchdog+0xeb/0x14b() [106903.349339] Hardware name: OptiPlex 760 [106903.349342] NETDEV WATCHDOG: eth0 (e1000e): transmit queue 0 timed out [106903.349344] Modules linked in: cdc_ether usbnet mii tun kvm_intel kvm snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss fuse snd_hda_codec_analog snd_hda_intel snd_hda_codec snd_hwdep snd_pcm radeon snd_timer snd_page_alloc ttm dell_wmi sparse_keymap wmi [106903.349379] Pid: 0, comm: swapper Not tainted 3.1.0-rc6+ #202 [106903.349382] Call Trace: [106903.349384] <IRQ> [<ffffffff8103c5a7>] warn_slowpath_common+0x80/0x98 [106903.349394] [<ffffffff8103c653>] warn_slowpath_fmt+0x41/0x43 [106903.349399] [<ffffffff81560149>] dev_watchdog+0xeb/0x14b [106903.349404] [<ffffffff810497c6>] run_timer_softirq+0x217/0x300 [106903.349408] [<ffffffff81049733>] ? run_timer_softirq+0x184/0x300 [106903.349413] [<ffffffff8156005e>] ? netif_tx_unlock+0x51/0x51 [106903.349419] [<ffffffff810423c6>] __do_softirq+0xe2/0x1bc [106903.349424] [<ffffffff81007a81>] ? paravirt_read_tsc+0x9/0xd [106903.349428] [<ffffffff81007fc8>] ? sched_clock+0x9/0xd [106903.349434] [<ffffffff8160063c>] call_softirq+0x1c/0x30 [106903.349438] [<ffffffff81003ba2>] do_softirq+0x46/0x9c [106903.349442] [<ffffffff81042696>] irq_exit+0x5b/0xbe [106903.349446] [<ffffffff8100384a>] do_IRQ+0x89/0xa0 [106903.349452] [<ffffffff815f8e33>] common_interrupt+0x73/0x73 [106903.349454] <EOI> [<ffffffff81008d81>] ? mwait_idle+0x8a/0xc1 [106903.349462] [<ffffffff81008d78>] ? mwait_idle+0x81/0xc1 [106903.349467] [<ffffffff810012ab>] cpu_idle+0xb3/0xd5 [106903.349473] [<ffffffff815d8dbe>] rest_init+0xb2/0xb9 [106903.349477] [<ffffffff815d8d0c>] ? csum_partial_copy_generic+0x16c/0x16c [106903.349483] [<ffffffff81a22b49>] start_kernel+0x390/0x39b [106903.349487] [<ffffffff81a222af>] x86_64_start_reservations+0xb6/0xba [106903.349491] [<ffffffff81a223b4>] x86_64_start_kernel+0x101/0x110 [106903.349495] ---[ end trace 1d36d9ed335e092c ]--- [106903.349722] e1000e 0000:00:19.0: eth0: Reset adapter -- Thanks Dave |
|
From: Jesse B. <jes...@in...> - 2011-09-28 23:46:31
|
On Wed, 28 Sep 2011 11:23:50 -0700 Carsten Aulbert <Car...@ae...> wrote: > But now we reinstalled several machines with Debian Squeeze and > suddenly we can only query the BMC when eth0 is down. The kernel we > use is exactly the same (2.6.32.28 or 2.6.32.46 currently), i.e. same > binary .deb package, same config, only the userland is changed. This is probably the driver touching a register that prevents IPMI traffic from flowing to the bmc. It may be a patch that Debian made that broke it, I don't generally track debian's forks of the kernel. :-) Can you send the output from the ethregs tool before down/after down. ethregs is available on e1000.sf.net in the downloads area. |
|
From: Jesse B. <jes...@in...> - 2011-09-28 23:20:17
|
On Wed, 28 Sep 2011 11:39:54 -0700 Denis Radovanovic <Den...@ri...> wrote: > We are currently testing small packet performance on 82574, comparing > it to 82571. Initial pktgen measurements have shown a significant > difference in performance that is the most visible when running > bidirectional traffic with 256 byte packets. > > Looking at the e1000e driver, we noticed that flag FLAG2_DMA_BURST is > enabled for 82571 and 82572 but it is not enabled for 82574. After > enabling the flag, the 82574 performance significantly improved, > approaching the one on 82571. At the time the feature was implemented we didn't have the bandwidth to validate it on other parts besides 82571/2 As it stands, yes you can enable it, but there will likely be some bugs that you will run into that we already know about but don't fully have fixed in the code. The bugs might result in tx hangs or other issues. I do agree that there are significant performance gains to be had via this feature, if the bugs can all be worked out. if this is a feature that you would really like implemented please use your Intel Field Agent or TME contacts in order to document your requirement so we can consider it for future releases. Thanks, Jesse |
|
From: Denis R. <Den...@ri...> - 2011-09-28 19:14:10
|
Hi, We are currently testing small packet performance on 82574, comparing it to 82571. Initial pktgen measurements have shown a significant difference in performance that is the most visible when running bidirectional traffic with 256 byte packets. Looking at the e1000e driver, we noticed that flag FLAG2_DMA_BURST is enabled for 82571 and 82572 but it is not enabled for 82574. After enabling the flag, the 82574 performance significantly improved, approaching the one on 82571. Is there a reason that this flag is not enabled for 82574? Thank you, Denis Radovanovic |
|
From: Carsten A. <Car...@ae...> - 2011-09-28 18:40:29
|
Hi all
this is a shot into the dark, but I thought maybe an expert here might
recognize this issue.
We use many Supermicro PDSML-LN2+ based server where the board management
controller (BMC/IPMI) shares the physical network connection with the system's
eth0 device. lspci shows
0d:00.0 Ethernet controller: Intel Corporation 82573E Gigabit Ethernet
Controller (Copper) (rev 03)
0e:00.0 Ethernet controller: Intel Corporation 82573L Gigabit Ethernet
Controller
The 82573E controller is the one shared with the BMC. Under Debian Lenny we
have not encountered any problem with remote access to these systems, e.g.
ipmitool -U USER -P PASSWORD -I lan -H IPMI_IP power status
works. Our setup is that eth0, eth1 and the BMC have distinct IP addresses,
but eth0 and BMC share one MAC, e.g.
n1570:~# ifconfig
eth0 Link encap:Ethernet HWaddr 00:30:48:99:97:3a
inet addr:172.26.15.70 Bcast:172.31.255.255 Mask:255.240.0.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:39289518 errors:0 dropped:0 overruns:0 frame:0
TX packets:28656886 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:3059622083 (2.8 GiB) TX bytes:2912754831 (2.7 GiB)
Memory:ee100000-ee120000
eth1 Link encap:Ethernet HWaddr 00:30:48:99:97:3b
inet addr:10.10.15.70 Bcast:10.255.255.255 Mask:255.0.0.0
UP BROADCAST RUNNING MULTICAST MTU:9000 Metric:1
RX packets:733539842 errors:0 dropped:11890044 overruns:0 frame:0
TX packets:373277670 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:3467288935387 (3.1 TiB) TX bytes:350737301109 (326.6 GiB)
Memory:ee200000-ee220000
and
n1570:~# ipmitool lan print
Set in Progress : Set Complete
Auth Type Support : NONE MD2 MD5 PASSWORD
Auth Type Enable : Callback : MD2 MD5 PASSWORD
: User : MD2 MD5 PASSWORD
: Operator : MD2 MD5 PASSWORD
: Admin : MD5 PASSWORD
: OEM : MD2 MD5 PASSWORD
IP Address Source : Static Address
IP Address : 172.27.15.70
Subnet Mask : 255.240.0.0
MAC Address : 00:30:48:99:97:3a
SNMP Community String : public
IP Header : TTL=0x40 Flags=0x40 Precedence=0x00 TOS=0x10
BMC ARP Control : ARP Responses Enabled, Gratuitous ARP Disabled
Gratituous ARP Intrvl : 2.0 seconds
Default Gateway IP : 0.0.0.0
Default Gateway MAC : 00:00:00:00:00:00
Backup Gateway IP : 0.0.0.0
Backup Gateway MAC : 00:00:00:00:00:00
802.1q VLAN ID : Disabled
802.1q VLAN Priority : 0
RMCP+ Cipher Suites : 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14
Cipher Suite Priv Max : Xaaaaaaaaaaaaaa
: X=Cipher Suite Unused
: c=CALLBACK
: u=USER
: o=OPERATOR
: a=ADMIN
: O=OEM
But now we reinstalled several machines with Debian Squeeze and suddenly we
can only query the BMC when eth0 is down. The kernel we use is exactly the
same (2.6.32.28 or 2.6.32.46 currently), i.e. same binary .deb package, same
config, only the userland is changed.
There is no service listening on port 623 used by IPMI thus there should not
be any interference. strace shows some differencing when running ifconfig eth0
up (both attached). From my point of view, the only big difference is
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 4
[...]
ioctl(4, SIOCGIFFLAGS, {ifr_name="eth0", ifr_flags=IFF_BROADCAST|
IFF_MULTICAST}) = 0
with lenny and with squeeze:
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 4
[...]
ioctl(4, SIOCGIFFLAGS, {ifr_name="eth0", ifr_flags=IFF_BROADCAST|
IFF_MULTICAST}) = 0
ioctl(4, SIOCSIFFLAGS, {ifr_name="eth0", ifr_flags=IFF_UP|IFF_BROADCAST|
IFF_RUNNING|IFF_MULTICAST}) = 0
Could this be the problem?
thanks for any suggestion!
Cheers
Carsten
--
Dr. Carsten Aulbert - Max Planck Institute for Gravitational Physics
Callinstrasse 38, 30167 Hannover, Germany
Phone/Fax: +49 511 762-17185 / -17193
http://www.top500.org/system/9234 | http://www.top500.org/connfam/6
CaCert Assurer | Get free certificates from http://www.cacert.org/
|
|
From: Hariharan N. -X (h. - H. T. L. at Cisco)
<han...@ci...> - 2011-09-27 07:52:16
|
Hi Atita, Thanks for your pointers. I looked at the bonding code and patch you pointed out which makes rtnl_lock synchronized version of bond_mii_monitor() . But when I looked at ixgbe driver code path for shutdown , I don't find rtnl_lock being used/held anywhere in this path. So just curious to understand how will rtnl_lock in bonding code will help to avoid this particular race condition. Thanks, Hari -----Original Message----- From: Shirwaikar, Atita [mailto:ati...@in...] Sent: Saturday, September 24, 2011 3:04 AM To: e10...@li... Cc: Skidmore, Donald C; Hariharan Nagarajan -X (hanagara - HCL TECHNOLOGIES LIMITED at Cisco) Subject: RE: [E1000-devel] crash in ixgbe driver code during system reboot when operating in bonding[ active-backup ] mode Hi Hari The issue that you are seeing, seems to have been fixed in the 2.6.24 kernel. In summary , RTNL lock is now acquired by the bonding driver before it does any failover processing like changing the MAC address. This should prevent race conditions like the one you are seeing. The following patch did the fix http://kerneltrap.org/mailarchive/linux-netdev/2007/10/11/334752. Thanks Atita -----Original Message----- From: Skidmore, Donald C Sent: Friday, September 09, 2011 3:11 PM To: Shirwaikar, Atita Subject: FW: [E1000-devel] crash in ixgbe driver code during system reboot when operating in bonding[ active-backup ] mode This is the issue I was talking about. I think the first step would be to try and recreate the failure. He seemed to think it wasn't that difficult. But then I haven't done it so ... ;) Thanks, -Don -----Original Message----- From: Hariharan Nagarajan -X (hanagara - HCL TECHNOLOGIES LIMITED at Cisco) [mailto:han...@ci...] Sent: Friday, September 09, 2011 1:26 AM To: Skidmore, Donald C; e10...@li... Cc: Siddharth Vajirkar (svajirka) Subject: RE: [E1000-devel] crash in ixgbe driver code during system reboot when operating in bonding[ active-backup ] mode Hi Don, Thanks for your reply . While we have not tried later drivers, we are also not seeing the issue every time during reboot because of timing nature of this race . But considering that from code inspection on these two paths, I think it would be nice if we can address this in one of upcoming releases. Thanks, Hari -----Original Message----- From: Skidmore, Donald C [mailto:don...@in...] Sent: Friday, September 09, 2011 7:36 AM To: Hariharan Nagarajan -X (hanagara - HCL TECHNOLOGIES LIMITED at Cisco); e10...@li... Cc: Siddharth Vajirkar (svajirka) Subject: RE: [E1000-devel] crash in ixgbe driver code during system reboot when operating in bonding[ active-backup ] mode Hi Hari, First thanks for the detailed analysis of your crash dump. It does look like a possible race condition between shutdown and the bonding device trying to update the address list. We haven't seen a similar failure during our validation but we will try more targeted testing for this his specific event. By any chance have you seen this failure with a more resent driver (3.4.24)? Like I mentioned above we haven't seen this failure before so I don't know of a fix in the later driver but a fair amount of the code affected here was refactored since the release you're running with. We will look into this failure and work to get it in to an upcoming release as well as in the kernel driver as soon as possible. However I doubt it will make the next source forge release which I should be pushing up to Source Forge tomorrow. Thanks, -Don Skidmore <don...@in...> >-----Original Message----- >From: Hariharan Nagarajan -X (hanagara - HCL TECHNOLOGIES LIMITED at >Cisco) [mailto:han...@ci...] >Sent: Thursday, September 08, 2011 5:03 AM >To: e10...@li... >Cc: Siddharth Vajirkar (svajirka) >Subject: [E1000-devel] crash in ixgbe driver code during system reboot >when operating in bonding[ active-backup ] mode > >Hello all, > > > >We have application running on Linux based OS. In one of our systems >which is based on 2.6.23 linux kernel, we have 10G Nics being used with >in active-back bond mode to provide > >interface backup capability in case one of link fails. > > > >eth2 and eth3 are the system interfaces in bonding with active-backup >mode. > > > >OS: Linux based on 2.6.23 kernel version > >ixgbe driver version: 3.1.17 > > > >The system is multiprocessor systems with ~ 24 cpu cores > > > >On particular instance while rebooting the system, we encountered a >kernel crash and system entered Kernel debugger mode due to double >fault. > > > >with dmesgs like this > >6>ACPI: PCI interrupt for device 0000:0a:00.0 disabled > ><6>ACPI: PCI interrupt for device 0000:09:00.0 disabled > ><3>ixgbe: eth3: ixgbe_disable_rx_queue: RXDCTL.ENABLE on Rx queue 0 not >cleared within the polling period > ><3>ixgbe: eth3: ixgbe_disable_rx_queue: RXDCTL.ENABLE on Rx queue 1 not >cleared within the polling period > ><3>ixgbe: eth3: ixgbe_disable_rx_queue: RXDCTL.ENABLE on Rx queue 2 not >cleared within the polling period > ><3>ixgbe: eth3: ixgbe_disable_rx_queue: RXDCTL.ENABLE on Rx queue 3 not >cleared within the polling period > ><3>ixgbe: eth3: ixgbe_disable_rx_queue: RXDCTL.ENABLE on Rx queue 4 not >cleared within the polling period > ><3>ixgbe: eth3: ixgbe_disable_rx_queue: RXDCTL.ENABLE on Rx queue 5 not >cleared within the polling period > ><3>ixgbe: eth3: ixgbe_disable_rx_queue: RXDCTL.ENABLE on Rx queue 6 not >cleared within the polling period > ><3>ixgbe: eth3: ixgbe_disable_rx_queue: RXDCTL.ENABLE on Rx queue 7 not >cleared within the polling period > ><3>ixgbe: eth3: ixgbe_disable_rx_queue: RXDCTL.ENABLE on Rx queue 8 not >cleared within the polling period > ><3>ixgbe: eth3: ixgbe_disable_rx_queue: RXDCTL.ENABLE on Rx queue 9 not >cleared within the polling period > ><3>ixgbe: eth3: ixgbe_disable_rx_queue: RXDCTL.ENABLE on Rx queue 10 not >cleared within the polling period > ><3>ixgbe: eth3: ixgbe_disable_rx_queue: RXDCTL.ENABLE on Rx queue 11 not >cleared within the polling period > ><3>ixgbe: eth3: ixgbe_disable_rx_queue: RXDCTL.ENABLE on Rx queue 12 not >cleared within the polling period > ><3>ixgbe: eth3: ixgbe_disable_rx_queue: RXDCTL.ENABLE on Rx queue 13 not >cleared within the polling period > ><3>ixgbe: eth3: ixgbe_disable_rx_queue: RXDCTL.ENABLE on Rx queue 14 not >cleared within the polling period > ><3>ixgbe: eth3: ixgbe_disable_rx_queue: RXDCTL.ENABLE on Rx queue 15 not >cleared within the polling period > ><6>bonding: bond5: link status definitely down for interface eth3, >disabling it > ><6>bonding: bond5: making interface eth2 the new active one. > ><0>double fault: 0000 [1] SMP > >[0]kdb> bt > >Stack traceback for pid 0 > >0xffffffff80945180 0 0 1 0 R 0xffffffff80945480 >*swapper > >rsp rip Function (args) > >======================= <doublefault> > >kdb_bb: address 0xffffffffffffffff not recognised > >Using old style backtrace, unreliable with no arguments > >rsp rip Function (args) > >======================= <doublefault> > >0xffffffff80de8fd8 0xffffffff804ab4c3 ixgbe_clear_vmdq_generic+0x73 > >+++ Cannot resolve next stack > >[0]kdb> cpu 1 > > > >==================================== > > > >While decoding the stack on all cpus , we found two cpus actively >doing ixgbe operation. > > > >Backtraces: > > CPU 2: > >Stack traceback for pid 6328 > >0xffff8101885fe000 6328 5757 1 2 R 0xffff8101885fe300 >*reboot > >rsp rip Function (args) > >0xffff8102e1777c08 0xffffffff8071acc6 kdb_interrupt+0x66 (0x3a991, >0x3028, 0x7ddd3, 0x9e582c6e, 0x3028, 0xe028) > >0xffff8102e1777c68 0xffffffff803a81ce __delay+0xe (0x3a991) > >0xffff8102e1777ca0 0xffffffff803a8211 __const_udelay+0x31 (invalid) > >0xffff8102e1777cb0 0xffffffff804a95bc ixgbe_disable_pcie_master+0xac >(0xffff81062f97d280) > >0xffff8102e1777ce0 0xffffffff804b39dc ixgbe_reset_hw_82599+0x7c >(0xffff81062f97d280) > >0xffff8102e1777d10 0xffffffff804a8d4f ixgbe_init_hw_generic+0xf >(0xffff81062f97d280) > >0xffff8102e1777d30 0xffffffff804a2f43 ixgbe_reset+0x63 >(0xffff81062f97c740) > >0xffff8102e1777d50 0xffffffff804a355b ixgbe_down+0x2cb >(0xffff81062f97c740) > >0xffff8102e1777d90 0xffffffff804a56d8 __ixgbe_shutdown+0xf8 >(0xffff8103322f8800, 0xffff8102e1777ddf) > >0xffff8102e1777dd0 0xffffffff804a57c5 ixgbe_shutdown+0x15 >(0xffff8103322f8800) > >0xffff8102e1777df0 0xffffffff803b8815 pci_device_shutdown+0x25 (invalid) > >0xffff8102e1777e00 0xffffffff80422d8a device_shutdown+0x7a > >0xffff8102e1777e20 0xffffffff8024040c kernel_restart_prepare+0x2c >(invalid) > >0xffff8102e1777e30 0xffffffff80240431 kernel_restart+0x11 (0x0) > >0xffff8102e1777e50 0xffffffff80240726 sys_reboot+0x1d6 (invalid, >invalid, invalid, 0x0) > >0xffff8102e1777f80 0xffffffff80220542 ia32_sysret (invalid, invalid, >invalid, invalid) > >CPU 0 > >(infinite loop, since IXGBE_WRITE_REG() is not taking effect), seems to >be due to reset done by other CPU shown above > > > >0xffffffff80de6d08 0xffffffff804aa387 ixgbe_clear_rar_generic+0x77 > >0xffffffff80de6d18 0xffffffff804ab4ca ixgbe_clear_vmdq_generic+0x7a > >0xffffffff80de6d28 0xffffffff804aa387 ixgbe_clear_rar_generic+0x77 > >0xffffffff80de6d38 0xffffffff804ab4ca ixgbe_clear_vmdq_generic+0x7a > >0xffffffff80de6d48 0xffffffff804aa387 ixgbe_clear_rar_generic+0x77 > >0xffffffff80de6d58 0xffffffff804a1b30 ixgbe_set_rx_mode+0x1a0 > >0xffffffff80de6da8 0xffffffff80659b8c __dev_set_rx_mode+0x6c > >0xffffffff80de6dc8 0xffffffff8065ccba dev_mc_add+0x9a > >0xffffffff80de6e08 0xffffffff804bce33 bond_change_active_slave+0x143 > >0xffffffff80de6e38 0xffffffff804bd1ab bond_select_active_slave+0x8b > >0xffffffff80de6e58 0xffffffff804bd40c bond_mii_monitor+0x1cc > >0xffffffff80de6e98 0xffffffff804bd240 bond_mii_monitor > >0xffffffff80de6eb8 0xffffffff8023b2b8 run_timer_softirq+0xe8 > >0xffffffff80de6f08 0xffffffff802372e5 __do_softirq+0x75 > >0xffffffff80de6f48 0xffffffff8020d3cc call_softirq+0x1c > >0xffffffff80de6f60 0xffffffff8020f329 do_softirq+0x49 > >0xffffffff80de6f80 0xffffffff802373d5 irq_exit+0x45 > >0xffffffff80de6f90 0xffffffff80219125 smp_apic_timer_interrupt+0x55 > >0xffffffff80de6f98 0xffffffff8020a4b0 mwait_idle > >0xffffffff80de6fb0 0xffffffff8020ce76 apic_timer_interrupt+0x66 > >======================= <normal> > >0xffffffff80a0be98 0xffffffff8020ce76 apic_timer_interrupt+0x66 > >0xffffffff80a0bef8 0xffffffff8020a4f3 mwait_idle+0x43 > >0xffffffff80a0bf20 0xffffffff8020a1d2 enter_idle+0x22 > >0xffffffff80a0bf30 0xffffffff8020a448 cpu_idle+0x78 > >0xffffffff80a0bf50 0xffffffff80717adc rest_init+0x5c > >0xffffffff80a0bf60 0xffffffff80a1894f start_kernel+0x29f > >This looks like an unfortunate interaction between reboot and the >bonding driver. > >One cpu is running reboot, and calls ixgbe down/reset, disabling the >ixgbe. > >Another cpu runs the bonding monitor, and is trying to change the >addresses > >on the bonding devices. This ends up looping between >clear_vmda/clear_rar > >because the device (being shutdown) is not responding to the writes. > >It looks like some logic will be needed in order to interlock between a >ixgbe > >device shutdown and attempting to rewrite the address list > > > >Is this an issue which is reported earlier? If not can this issue be >addressed in future ixgbe releases considering the race condition we >have > >in this execution path during shutdown? > > > >Thanks, > >Hari |
|
From: Dan T. <DT...@El...> - 2011-09-26 23:47:56
|
Hi, I am currently conducting multiple searches for mobile handset or device test engineers. We have positions ranging from test lab managers, to drive test engineers. If you have ANY experience doing high or low level handset testing on the carrier or device OEM side, with technologies such as 3G, 4G, GSM, CDMA, WiFi or WIMAX, please send your current resume along with phone contact information. *Due to the volume of resumes I receive, I may only have time to respond to the closest matches in experience. Sincerely, Dan Tobias Executive Recruiter Electronic Search, Inc. 5105 Tollview Dr. #245 Rolling Meadows, IL 60008 dt...@el... www.WirelessRecruiters.com?source=emaildtsig Direct: 847.506.2497 Fax: 847.506.9999 "Building Wireless Futures" View my Linked In profile at http://www.linkedin.com/in/RecruiterTobias Your resume with the email address e10...@li... is in our database of professionals interested in career advancement. You may have sent it to us or posted it to an Internet Job-Board. If you do not want to receive future job notifications from Electronic Search, Inc. please forward this message to Re...@El.... (The following links were included with this email:) mailto:dt...@el...?source=emailDTSig http://www.wirelessrecruiters.com/?source=emaildtsig http://www.linkedin.com/in/RecruiterTobias mailto:Re...@El... (The following links were included with this email:) mailto:dt...@el...?source=emailDTSig http://www.wirelessrecruiters.com/?source=emaildtsig http://www.linkedin.com/in/RecruiterTobias mailto:Re...@El... |
|
From: Ben G. <gr...@ca...> - 2011-09-26 18:27:16
|
On 09/26/2011 09:40 AM, Chris Friesen wrote: > On 09/26/2011 10:04 AM, Alexander Duyck wrote: > >> It sounds like you are using a single card, would that be correct? If >> you are running close to line rate on both ports this could be causing >> you to saturate the PCIe x8 link. > > According to > "http://communities.intel.com/community/wired/blog/2009/06/08/understanding-pci-express-bandwidth" > 8x PCIe should have a bandwidth of 4GB/s. 2 10Gigabit ports is 2.5GB/s. > > The 82599 only goes up to 8x, so I'd expect that it should be sufficient > to handle the full traffic. > > To any of the Intel guys out there...any ideas? Can an 82599 on an 8x > bus handle max line rate with minimum size packets? Rick Jones sent me an interesting link related to this. Short answer seems to be 'yes', but it seems not for any normal off-the-shelf software stack. > This: http://comments.gmane.org/gmane.linux.network/203602 should lead you to some slide. Thanks, Ben -- Ben Greear <gr...@ca...> Candela Technologies Inc http://www.candelatech.com |
|
From: Ben G. <gr...@ca...> - 2011-09-26 17:58:09
|
On 09/26/2011 10:46 AM, Chris Friesen wrote: > On 09/26/2011 11:24 AM, Ben Greear wrote: >> On 09/26/2011 09:40 AM, Chris Friesen wrote: > >>> To any of the Intel guys out there...any ideas? Can an 82599 on an 8x >>> bus handle max line rate with minimum size packets? >> >> Rick Jones sent me an interesting link related to this. Short answer seems >> to be 'yes', but it seems not for any normal off-the-shelf software stack. >> >> > This: http://comments.gmane.org/gmane.linux.network/203602 should >> lead you to some slide. > > Interesting. I wonder if Intel's DPDK will be the only way to handle those sorts of packet rates. Pktgen is probably still the fastest general code that I know of, but we had some interesting results setting the TCP_MAXSEGS to 88, which creates around 150 byte packets, and let the NICs offload chop up large TCP writes into small packets on the wire. Using core-I7 980x CPU, and dual-port 82599, we could send around 4Mpps and receive around 2Mpps between two machines. We were using a single port on each NIC/machine for this test. Connection was a bit asymmetric, seems one side would over-power the other...so if we twiddled a bit, we could get around 3Mpps in each direction. Our user-space app has some over-head as well, but we can send at least 5Gbps full duplex on two ports using normal sized frames, so I think the bottleneck in this case is the TCP offload in the NIC. Still, pretty impressive for stateful TCP packets per second :) Top-of-tree netperf just learned to do the TCP_MAXSEG trick as well, so it might be fun to play with that. It probably has less overhead than our tool, so might run even faster. Thanks, Ben -- Ben Greear <gr...@ca...> Candela Technologies Inc http://www.candelatech.com |
|
From: Chris F. <chr...@ge...> - 2011-09-26 17:47:21
|
On 09/26/2011 11:24 AM, Ben Greear wrote: > On 09/26/2011 09:40 AM, Chris Friesen wrote: >> To any of the Intel guys out there...any ideas? Can an 82599 on an 8x >> bus handle max line rate with minimum size packets? > > Rick Jones sent me an interesting link related to this. Short answer seems > to be 'yes', but it seems not for any normal off-the-shelf software stack. > > > This: http://comments.gmane.org/gmane.linux.network/203602 should > lead you to some slide. Interesting. I wonder if Intel's DPDK will be the only way to handle those sorts of packet rates. Chris -- Chris Friesen Software Developer GENBAND chr...@ge... www.genband.com |
|
From: Chris F. <chr...@ge...> - 2011-09-26 17:19:54
|
On 09/26/2011 10:04 AM, Alexander Duyck wrote: > It sounds like you are using a single card, would that be correct? If > you are running close to line rate on both ports this could be causing > you to saturate the PCIe x8 link. According to "http://communities.intel.com/community/wired/blog/2009/06/08/understanding-pci-express-bandwidth" 8x PCIe should have a bandwidth of 4GB/s. 2 10Gigabit ports is 2.5GB/s. The 82599 only goes up to 8x, so I'd expect that it should be sufficient to handle the full traffic. To any of the Intel guys out there...any ideas? Can an 82599 on an 8x bus handle max line rate with minimum size packets? Chris -- Chris Friesen Software Developer GENBAND chr...@ge... www.genband.com |
|
From: Ronciak, J. <joh...@in...> - 2011-09-26 16:44:06
|
If you use a 2.6.39 or newer kernel 1588 timestamping is enabled in the driver by default when it's enabled in the kernel. Please try a newer kernel. If you can't look to see if you can backport both the kernel and possibly driver changes to your older kernel. Cheers, John > -----Original Message----- > From: Plank, Stefan [mailto:ste...@si...] > Sent: Monday, September 26, 2011 7:38 AM > To: e10...@li... > Subject: [E1000-devel] Needing help for igb > > Hello, > > I have studied documentation for IEEE 1588 PTP and Intel 82576 with IGB > driver. > But I don't get HW timestamps in sending PTP packets? > > I am using > linux kernel 2.6.37.6 > igb driver 3.1.16 > > I downloaded a ptpd which works without hw timestamping very well. > When adding hw support nothing happens? > > As described in linux documentation following seems to be > (additionally) necessary: > ioctl(sock, SIOCSHWTSTAMP, &hwtstamp) with HWTSTAMP_TX_ON > setsockopt(sock, SOL_SOCKET, SO_TIMESTAMP, &temp, sizeof(int)) > so_timestamping_flags = SOF_TIMESTAMPING_TX_HARDWARE | > SOF_TIMESTAMPING_RX_HARDWARE | SOF_TIMESTAMPING_SYS_HARDWARE; > setsockopt(sock, SOL_SOCKET, SO_TIMESTAMPING, &so_timestamping_flags, > sizeof(so_timestamping_flags)) > > Can you give me a hint how it works as wanted? > Does the 82576 place the timestamps (only) in ptp packets? > The offset in the packets is not always the same - how is this handled? > > Looking forward to your answer I say thank you. > > Kind regards > Stefan Plank > Development > > Siemens Enterprise Communications GmbH & Co. KG Hofmannstr. 51 80200 > Munich > Tel.: +49 89 7007-32410 > Fax: +49 89 7007-31675 > mailto:ste...@si... > > Communication for the open minded > www.siemens-enterprise.de<http://www.siemens-enterprise.de/> > > Siemens Enterprise Communications GmbH & Co. KG; Sitz der Gesellschaft: > München; Registergericht: München, HRA 88546; WEEE-Reg.Nr. DE 27980375; > Persönlich haftende Gesellschafterin: Siemens Enterprise Communications > Management GmbH; Geschäftsführer: Alexander Frick, Thomas Heim, Stefan > Herrlich, Vera Meyer; Vorsitzender des Aufsichtsrates: Mark Stone; Sitz > der Gesellschaft: München; Registergericht: München, HRB 163415 > > Siemens Enterprise Communications GmbH & Co. KG is a Trademark Licensee > of Siemens AG Wichtiger Hinweis: Diese E-Mail und etwaige Anlagen > enthalten firmenvertrauliche Informationen. Sollten Sie diese E-Mail > irrtümlich erhalten haben, benachrichtigen Sie uns bitte durch Antwort- > Mail und löschen Sie diese E-Mail nebst Anlagen von Ihrem System. > Vielen Dank. |
10 messages has been excluded from this view by a project administrator.
