From nobody@FreeBSD.org  Fri Nov  6 01:18:12 2009
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 247F1106568B
	for <freebsd-gnats-submit@FreeBSD.org>; Fri,  6 Nov 2009 01:18:12 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (www.freebsd.org [IPv6:2001:4f8:fff6::21])
	by mx1.freebsd.org (Postfix) with ESMTP id 1408C8FC1A
	for <freebsd-gnats-submit@FreeBSD.org>; Fri,  6 Nov 2009 01:18:12 +0000 (UTC)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by www.freebsd.org (8.14.3/8.14.3) with ESMTP id nA61IBVo027140
	for <freebsd-gnats-submit@FreeBSD.org>; Fri, 6 Nov 2009 01:18:11 GMT
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.14.3/8.14.3/Submit) id nA61IBJn027139;
	Fri, 6 Nov 2009 01:18:11 GMT
	(envelope-from nobody)
Message-Id: <200911060118.nA61IBJn027139@www.freebsd.org>
Date: Fri, 6 Nov 2009 01:18:11 GMT
From: Maksym Sobolyev <sobomax@FreeBSD.org>
To: freebsd-gnats-submit@FreeBSD.org
Subject: em0: watchdog timeout when communicating to windows using 9K MTU
X-Send-Pr-Version: www-3.1
X-GNATS-Notify:

>Number:         140326
>Category:       kern
>Synopsis:       [em] em0: watchdog timeout when communicating to windows using 9K MTU
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    jfv
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Fri Nov 06 01:20:01 UTC 2009
>Closed-Date:    
>Last-Modified:  Mon Aug 23 17:45:32 UTC 2010
>Originator:     Maksym Sobolyev
>Release:        7.2-p4
>Organization:
Sippy Software, Inc.
>Environment:
FreeBSD pioneer.sippysoft.com 7.2-RELEASE-p4 FreeBSD 7.2-RELEASE-p4 #0: Sun Oct  4 03:08:04 PDT 2009     root@pioneer.sippysoft.com:/usr/obj/usr/src/sys/PIONEER  amd64
>Description:
My em0 interface repeatedly hangs up with watchdog timeout when communicating to the windows host at MTU 9K.

[sobomax@pioneer ~]$ grep em0 /var/run/dmesg.boot
em0: <Intel(R) PRO/1000 Network Connection 6.9.6> port 0xecc0-0xecdf mem 0xfe6e0000-0xfe6fffff,0xfe6d9000-0xfe6d9fff irq 21 at device 25.0 on pci0
em0: Using MSI interrupt
em0: [FILTER]
em0: Ethernet address: 00:22:19:32:87:2f
[sobomax@pioneer ~]$ uname -a
FreeBSD pioneer.sippysoft.com 7.2-RELEASE-p4 FreeBSD 7.2-RELEASE-p4 #0: Sun Oct  4 03:08:04 PDT 2009     root@pioneer.sippysoft.com:/usr/obj/usr/src/sys/PIONEER  amd64
[sobomax@pioneer ~]$ ifconfig em0
em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 9000
        options=98<VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM>
        ether 00:22:19:32:87:2f
        inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255
        inet 192.168.2.1 netmask 0xffffff00 broadcast 192.168.2.255
        inet6 fec0::1 prefixlen 64
        media: Ethernet autoselect (1000baseTX <full-duplex>)
        status: active
[sobomax@pioneer ~]$ dmesg | grep watchd
em0: watchdog timeout -- resetting
em0: watchdog timeout -- resetting
em0: watchdog timeout -- resetting
em0: watchdog timeout -- resetting
em0: watchdog timeout -- resetting

I have managed to make a packet capture right at the time when hang happens. It appears to be that either "MAC Pause" or "TCP Segment of reassembled PDU" is the last packet that goes through before the interface hangs.

Here is the screenshot, if somebody wants to take closer look at the actual packets please let me know.

http://sobomax.sippysoft.com/~sobomax/ScreenShot527.png

Turning off TSO and TXCSUM/RXCSUM has not helped. Bringing MTU down to 1,500 resolved the issue.

I have had the same problem happening several times in the past (although I initially attributed it to the bad cable or something like that), so it's definitely not on-off issue.

Given popularity of intel/pro chips in today's computers it look like quite serious issue to me. Any help is greatly appreciated.
>How-To-Repeat:

>Fix:


>Release-Note:
>Audit-Trail:

From: Jack Vogel <jfvogel@gmail.com>
To: Maksym Sobolyev <sobomax@freebsd.org>
Cc: freebsd-gnats-submit@freebsd.org
Subject: Re: kern/140326: em0: watchdog timeout when communicating to windows 
	using 9K MTU
Date: Thu, 5 Nov 2009 17:28:50 -0800

 --0016e6d99d6125581f0477a9c469
 Content-Type: text/plain; charset=ISO-8859-1
 
 Can't do much unless you adequately identify hardware, on BOTH sides,
 believe
 it or not "windows" is not a sufficient description :)
 
 I need to know what the E1000 hardware is, using pciconf -l, and I also need
 to
 know what is on the Windows side before having a clue on how to repro or
 help
 you.
 
 Cheers,
 
 Jack
 
 
 On Thu, Nov 5, 2009 at 5:18 PM, Maksym Sobolyev <sobomax@freebsd.org> wrote:
 
 >
 > >Number:         140326
 > >Category:       kern
 > >Synopsis:       em0: watchdog timeout when communicating to windows using
 > 9K MTU
 > >Confidential:   no
 > >Severity:       serious
 > >Priority:       high
 > >Responsible:    freebsd-bugs
 > >State:          open
 > >Quarter:
 > >Keywords:
 > >Date-Required:
 > >Class:          sw-bug
 > >Submitter-Id:   current-users
 > >Arrival-Date:   Fri Nov 06 01:20:01 UTC 2009
 > >Closed-Date:
 > >Last-Modified:
 > >Originator:     Maksym Sobolyev
 > >Release:        7.2-p4
 > >Organization:
 > Sippy Software, Inc.
 > >Environment:
 > FreeBSD pioneer.sippysoft.com 7.2-RELEASE-p4 FreeBSD 7.2-RELEASE-p4 #0:
 > Sun Oct  4 03:08:04 PDT 2009     root@pioneer.sippysoft.com:/usr/obj/usr/src/sys/PIONEER
 >  amd64
 > >Description:
 > My em0 interface repeatedly hangs up with watchdog timeout when
 > communicating to the windows host at MTU 9K.
 >
 > [sobomax@pioneer ~]$ grep em0 /var/run/dmesg.boot
 > em0: <Intel(R) PRO/1000 Network Connection 6.9.6> port 0xecc0-0xecdf mem
 > 0xfe6e0000-0xfe6fffff,0xfe6d9000-0xfe6d9fff irq 21 at device 25.0 on pci0
 > em0: Using MSI interrupt
 > em0: [FILTER]
 > em0: Ethernet address: 00:22:19:32:87:2f
 > [sobomax@pioneer ~]$ uname -a
 > FreeBSD pioneer.sippysoft.com 7.2-RELEASE-p4 FreeBSD 7.2-RELEASE-p4 #0:
 > Sun Oct  4 03:08:04 PDT 2009     root@pioneer.sippysoft.com:/usr/obj/usr/src/sys/PIONEER
 >  amd64
 > [sobomax@pioneer ~]$ ifconfig em0
 > em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 9000
 >        options=98<VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM>
 >        ether 00:22:19:32:87:2f
 >        inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255
 >        inet 192.168.2.1 netmask 0xffffff00 broadcast 192.168.2.255
 >        inet6 fec0::1 prefixlen 64
 >        media: Ethernet autoselect (1000baseTX <full-duplex>)
 >        status: active
 > [sobomax@pioneer ~]$ dmesg | grep watchd
 > em0: watchdog timeout -- resetting
 > em0: watchdog timeout -- resetting
 > em0: watchdog timeout -- resetting
 > em0: watchdog timeout -- resetting
 > em0: watchdog timeout -- resetting
 >
 > I have managed to make a packet capture right at the time when hang
 > happens. It appears to be that either "MAC Pause" or "TCP Segment of
 > reassembled PDU" is the last packet that goes through before the interface
 > hangs.
 >
 > Here is the screenshot, if somebody wants to take closer look at the actual
 > packets please let me know.
 >
 > http://sobomax.sippysoft.com/~sobomax/ScreenShot527.png<http://sobomax.sippysoft.com/%7Esobomax/ScreenShot527.png>
 >
 > Turning off TSO and TXCSUM/RXCSUM has not helped. Bringing MTU down to
 > 1,500 resolved the issue.
 >
 > I have had the same problem happening several times in the past (although I
 > initially attributed it to the bad cable or something like that), so it's
 > definitely not on-off issue.
 >
 > Given popularity of intel/pro chips in today's computers it look like quite
 > serious issue to me. Any help is greatly appreciated.
 > >How-To-Repeat:
 >
 > >Fix:
 >
 >
 > >Release-Note:
 > >Audit-Trail:
 > >Unformatted:
 > _______________________________________________
 > freebsd-bugs@freebsd.org mailing list
 > http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
 > To unsubscribe, send any mail to "freebsd-bugs-unsubscribe@freebsd.org"
 >
 
 --0016e6d99d6125581f0477a9c469
 Content-Type: text/html; charset=ISO-8859-1
 Content-Transfer-Encoding: quoted-printable
 
 Can&#39;t do much unless you adequately identify hardware, on BOTH sides, b=
 elieve<br>it or not &quot;windows&quot; is not a sufficient description :)<=
 br><br>I need to know what the E1000 hardware is, using pciconf -l, and I a=
 lso need to<br>
 know what is on the Windows side before having a clue on how to repro or he=
 lp<br>you.<br><br>Cheers,<br><br>Jack<br><br><br><div class=3D"gmail_quote"=
 >On Thu, Nov 5, 2009 at 5:18 PM, Maksym Sobolyev <span dir=3D"ltr">&lt;<a h=
 ref=3D"mailto:sobomax@freebsd.org">sobomax@freebsd.org</a>&gt;</span> wrote=
 :<br>
 <blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, =
 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
 &gt;Number: =A0 =A0 =A0 =A0 140326<br>
 &gt;Category: =A0 =A0 =A0 kern<br>
 &gt;Synopsis: =A0 =A0 =A0 em0: watchdog timeout when communicating to windo=
 ws using 9K MTU<br>
 &gt;Confidential: =A0 no<br>
 &gt;Severity: =A0 =A0 =A0 serious<br>
 &gt;Priority: =A0 =A0 =A0 high<br>
 &gt;Responsible: =A0 =A0freebsd-bugs<br>
 &gt;State: =A0 =A0 =A0 =A0 =A0open<br>
 &gt;Quarter:<br>
 &gt;Keywords:<br>
 &gt;Date-Required:<br>
 &gt;Class: =A0 =A0 =A0 =A0 =A0sw-bug<br>
 &gt;Submitter-Id: =A0 current-users<br>
 &gt;Arrival-Date: =A0 Fri Nov 06 01:20:01 UTC 2009<br>
 &gt;Closed-Date:<br>
 &gt;Last-Modified:<br>
 &gt;Originator: =A0 =A0 Maksym Sobolyev<br>
 &gt;Release: =A0 =A0 =A0 =A07.2-p4<br>
 &gt;Organization:<br>
 Sippy Software, Inc.<br>
 &gt;Environment:<br>
 FreeBSD <a href=3D"http://pioneer.sippysoft.com" target=3D"_blank">pioneer.=
 sippysoft.com</a> 7.2-RELEASE-p4 FreeBSD 7.2-RELEASE-p4 #0: Sun Oct =A04 03=
 :08:04 PDT 2009 =A0 =A0 root@pioneer.sippysoft.com:/usr/obj/usr/src/sys/PIO=
 NEER =A0amd64<br>
 
 &gt;Description:<br>
 My em0 interface repeatedly hangs up with watchdog timeout when communicati=
 ng to the windows host at MTU 9K.<br>
 <br>
 [sobomax@pioneer ~]$ grep em0 /var/run/dmesg.boot<br>
 em0: &lt;Intel(R) PRO/1000 Network Connection 6.9.6&gt; port 0xecc0-0xecdf =
 mem 0xfe6e0000-0xfe6fffff,0xfe6d9000-0xfe6d9fff irq 21 at device 25.0 on pc=
 i0<br>
 em0: Using MSI interrupt<br>
 em0: [FILTER]<br>
 em0: Ethernet address: 00:22:19:32:87:2f<br>
 [sobomax@pioneer ~]$ uname -a<br>
 FreeBSD <a href=3D"http://pioneer.sippysoft.com" target=3D"_blank">pioneer.=
 sippysoft.com</a> 7.2-RELEASE-p4 FreeBSD 7.2-RELEASE-p4 #0: Sun Oct =A04 03=
 :08:04 PDT 2009 =A0 =A0 root@pioneer.sippysoft.com:/usr/obj/usr/src/sys/PIO=
 NEER =A0amd64<br>
 
 [sobomax@pioneer ~]$ ifconfig em0<br>
 em0: flags=3D8843&lt;UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST&gt; metric 0 mt=
 u 9000<br>
  =A0 =A0 =A0 =A0options=3D98&lt;VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM&gt;<br>
  =A0 =A0 =A0 =A0ether 00:22:19:32:87:2f<br>
  =A0 =A0 =A0 =A0inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255=
 <br>
  =A0 =A0 =A0 =A0inet 192.168.2.1 netmask 0xffffff00 broadcast 192.168.2.255=
 <br>
  =A0 =A0 =A0 =A0inet6 fec0::1 prefixlen 64<br>
  =A0 =A0 =A0 =A0media: Ethernet autoselect (1000baseTX &lt;full-duplex&gt;)=
 <br>
  =A0 =A0 =A0 =A0status: active<br>
 [sobomax@pioneer ~]$ dmesg | grep watchd<br>
 em0: watchdog timeout -- resetting<br>
 em0: watchdog timeout -- resetting<br>
 em0: watchdog timeout -- resetting<br>
 em0: watchdog timeout -- resetting<br>
 em0: watchdog timeout -- resetting<br>
 <br>
 I have managed to make a packet capture right at the time when hang happens=
 . It appears to be that either &quot;MAC Pause&quot; or &quot;TCP Segment o=
 f reassembled PDU&quot; is the last packet that goes through before the int=
 erface hangs.<br>
 
 <br>
 Here is the screenshot, if somebody wants to take closer look at the actual=
  packets please let me know.<br>
 <br>
 <a href=3D"http://sobomax.sippysoft.com/%7Esobomax/ScreenShot527.png" targe=
 t=3D"_blank">http://sobomax.sippysoft.com/~sobomax/ScreenShot527.png</a><br=
 >
 <br>
 Turning off TSO and TXCSUM/RXCSUM has not helped. Bringing MTU down to 1,50=
 0 resolved the issue.<br>
 <br>
 I have had the same problem happening several times in the past (although I=
  initially attributed it to the bad cable or something like that), so it&#3=
 9;s definitely not on-off issue.<br>
 <br>
 Given popularity of intel/pro chips in today&#39;s computers it look like q=
 uite serious issue to me. Any help is greatly appreciated.<br>
 &gt;How-To-Repeat:<br>
 <br>
 &gt;Fix:<br>
 <br>
 <br>
 &gt;Release-Note:<br>
 &gt;Audit-Trail:<br>
 &gt;Unformatted:<br>
 _______________________________________________<br>
 <a href=3D"mailto:freebsd-bugs@freebsd.org">freebsd-bugs@freebsd.org</a> ma=
 iling list<br>
 <a href=3D"http://lists.freebsd.org/mailman/listinfo/freebsd-bugs" target=
 =3D"_blank">http://lists.freebsd.org/mailman/listinfo/freebsd-bugs</a><br>
 To unsubscribe, send any mail to &quot;<a href=3D"mailto:freebsd-bugs-unsub=
 scribe@freebsd.org">freebsd-bugs-unsubscribe@freebsd.org</a>&quot;<br>
 </blockquote></div><br>
 
 --0016e6d99d6125581f0477a9c469--

From: Maxim Sobolev <sobomax@FreeBSD.org>
To: Jack Vogel <jfvogel@gmail.com>
Cc: freebsd-gnats-submit@FreeBSD.org
Subject: Re: kern/140326: em0: watchdog timeout when communicating to windows
 	using 9K MTU
Date: Thu, 05 Nov 2009 18:28:13 -0800

 Jack Vogel wrote:
 > Can't do much unless you adequately identify hardware, on BOTH sides, 
 > believe
 > it or not "windows" is not a sufficient description :)
 > 
 > I need to know what the E1000 hardware is, using pciconf -l, and I also 
 > need to
 > know what is on the Windows side before having a clue on how to repro or 
 > help
 > you.
 
 Jack,
 
 Thank you for the amazingly fast reply.
 
 Sure, FreeBSD side is this:
 
 em0@pci0:0:25:0:        class=0x020000 card=0x02761028 chip=0x10de8086 
 rev=0x02 hdr=0x00
      vendor     = 'Intel Corporation'
      class      = network
      subclass   = ethernet
 
 On windows side it's Realtek GiGe card. The system itself is Windows 7 
 Ultimate 64-bit edition:
 
 PCI\VEN_10EC&DEV_8168&SUBSYS_02C01028&REV_03
 
 Please let me know if any other information is necessary.
 
 Regards,
 -- 
 Maksym Sobolyev
 Sippy Software, Inc.
 Internet Telephony (VoIP) Experts
 T/F: +1-646-651-1110
 Web: http://www.sippysoft.com
 MSN: sales@sippysoft.com
 Skype: SippySoft
Responsible-Changed-From-To: freebsd-bugs->freebsd-net 
Responsible-Changed-By: linimon 
Responsible-Changed-When: Fri Nov 6 04:35:06 UTC 2009 
Responsible-Changed-Why:  
Over to maintainer(s). 

http://www.freebsd.org/cgi/query-pr.cgi?pr=140326 

From: Jack Vogel <jfvogel@gmail.com>
To: Maxim Sobolev <sobomax@freebsd.org>
Cc: freebsd-gnats-submit@freebsd.org
Subject: Re: kern/140326: em0: watchdog timeout when communicating to windows 
	using 9K MTU
Date: Thu, 5 Nov 2009 21:05:11 -0800

 --0016e6dab0fde1e7870477acc9ad
 Content-Type: text/plain; charset=ISO-8859-1
 
 Good, that's a start. Now, is there a switch of some sort involved or are
 you going
 back to back? Some switches have problems with jumbo frames, there are also
 some vendors (including our's) interfaces that do not support jumbo frames,
 so
 you need to check on that also (I mean the RT).
 
 I will check on the Intel adapter tomorrow.
 
 Jack
 
 
 On Thu, Nov 5, 2009 at 6:28 PM, Maxim Sobolev <sobomax@freebsd.org> wrote:
 
 > Jack Vogel wrote:
 >
 >> Can't do much unless you adequately identify hardware, on BOTH sides,
 >> believe
 >> it or not "windows" is not a sufficient description :)
 >>
 >> I need to know what the E1000 hardware is, using pciconf -l, and I also
 >> need to
 >> know what is on the Windows side before having a clue on how to repro or
 >> help
 >> you.
 >>
 >
 > Jack,
 >
 > Thank you for the amazingly fast reply.
 >
 > Sure, FreeBSD side is this:
 >
 > em0@pci0:0:25:0:        class=0x020000 card=0x02761028 chip=0x10de8086
 > rev=0x02 hdr=0x00
 >    vendor     = 'Intel Corporation'
 >    class      = network
 >    subclass   = ethernet
 >
 > On windows side it's Realtek GiGe card. The system itself is Windows 7
 > Ultimate 64-bit edition:
 >
 > PCI\VEN_10EC&DEV_8168&SUBSYS_02C01028&REV_03
 >
 > Please let me know if any other information is necessary.
 >
 > Regards,
 > --
 > Maksym Sobolyev
 > Sippy Software, Inc.
 > Internet Telephony (VoIP) Experts
 > T/F: +1-646-651-1110
 > Web: http://www.sippysoft.com
 > MSN: sales@sippysoft.com
 > Skype: SippySoft
 >
 
 --0016e6dab0fde1e7870477acc9ad
 Content-Type: text/html; charset=ISO-8859-1
 Content-Transfer-Encoding: quoted-printable
 
 Good, that&#39;s a start. Now, is there a switch of some sort involved or a=
 re you going<br>back to back? Some switches have problems with jumbo frames=
 , there are also<br>some vendors (including our&#39;s) interfaces that do n=
 ot support jumbo frames, so<br>
 you need to check on that also (I mean the RT).<br><br>I will check on the =
 Intel adapter tomorrow.<br><br>Jack<br><br><br><div class=3D"gmail_quote">O=
 n Thu, Nov 5, 2009 at 6:28 PM, Maxim Sobolev <span dir=3D"ltr">&lt;<a href=
 =3D"mailto:sobomax@freebsd.org">sobomax@freebsd.org</a>&gt;</span> wrote:<b=
 r>
 <blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, =
 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class=3D"im"=
 >Jack Vogel wrote:<br>
 <blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, =
 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
 Can&#39;t do much unless you adequately identify hardware, on BOTH sides, b=
 elieve<br>
 it or not &quot;windows&quot; is not a sufficient description :)<br>
 <br>
 I need to know what the E1000 hardware is, using pciconf -l, and I also nee=
 d to<br>
 know what is on the Windows side before having a clue on how to repro or he=
 lp<br>
 you.<br>
 </blockquote>
 <br></div>
 Jack,<br>
 <br>
 Thank you for the amazingly fast reply.<br>
 <br>
 Sure, FreeBSD side is this:<br>
 <br>
 em0@pci0:0:25:0: =A0 =A0 =A0 =A0class=3D0x020000 card=3D0x02761028 chip=3D0=
 x10de8086 rev=3D0x02 hdr=3D0x00<br>
  =A0 =A0vendor =A0 =A0 =3D &#39;Intel Corporation&#39;<br>
  =A0 =A0class =A0 =A0 =A0=3D network<br>
  =A0 =A0subclass =A0 =3D ethernet<br>
 <br>
 On windows side it&#39;s Realtek GiGe card. The system itself is Windows 7 =
 Ultimate 64-bit edition:<br>
 <br>
 PCI\VEN_10EC&amp;DEV_8168&amp;SUBSYS_02C01028&amp;REV_03<br>
 <br>
 Please let me know if any other information is necessary.<br>
 <br>
 Regards,<br><font color=3D"#888888">
 -- <br>
 Maksym Sobolyev<br>
 Sippy Software, Inc.<br>
 Internet Telephony (VoIP) Experts<br>
 T/F: +1-646-651-1110<br>
 Web: <a href=3D"http://www.sippysoft.com" target=3D"_blank">http://www.sipp=
 ysoft.com</a><br>
 MSN: <a href=3D"mailto:sales@sippysoft.com" target=3D"_blank">sales@sippyso=
 ft.com</a><br>
 Skype: SippySoft<br>
 </font></blockquote></div><br>
 
 --0016e6dab0fde1e7870477acc9ad--

From: Maxim Sobolev <sobomax@FreeBSD.org>
To: Jack Vogel <jfvogel@gmail.com>
Cc: freebsd-gnats-submit@FreeBSD.org
Subject: Re: kern/140326: em0: watchdog timeout when communicating to windows
 	using 9K MTU
Date: Fri, 06 Nov 2009 00:30:33 -0800

 Jack Vogel wrote:
 > Good, that's a start. Now, is there a switch of some sort involved or 
 > are you going
 > back to back? Some switches have problems with jumbo frames, there are also
 > some vendors (including our's) interfaces that do not support jumbo 
 > frames, so
 > you need to check on that also (I mean the RT).
 > 
 > I will check on the Intel adapter tomorrow.
 
 Yes, there is switch involved (Cisco/Linksys EG008W ver.3), but I don't 
 think it's related. The problem has really escalated when I installed 
 Windows 7 on this machine yesterday. Before that the same machine with 
 Realtek was running Vista and this problem had happened to me only once 
 or twice in two weeks with the same MTU on both ends. And from the 
 capture it seems like the very specific condition causes this. 
 Unfortunately this box is a gateway for a network, so that I cannot 
 replace hub and try to reproduce the issue.
 
 -Maxim

From: Maxim Sobolev <sobomax@FreeBSD.org>
To: Jack Vogel <jfvogel@gmail.com>
Cc: freebsd-gnats-submit@FreeBSD.org
Subject: Re: kern/140326: em0: watchdog timeout when communicating to windows
 	using 9K MTU
Date: Fri, 06 Nov 2009 01:58:52 -0800

 Jack,
 
 Here is some additional info you might find useful: I have replaced 
 Linksys switch with more "professional" rack-mountable 3Com Baseline 
 2816 switch and reproduced the issue just as easy by copying large file 
 via SMB from FReeBSD to Windows 7. To me it pretty much rules out any 
 problems with the switch.
 
 Hope it helps.
 
 -Maxim
Responsible-Changed-From-To: freebsd-net->jfv 
Responsible-Changed-By: andre 
Responsible-Changed-When: Mon Aug 23 17:45:09 UTC 2010 
Responsible-Changed-Why:  
Over to maintainer. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=140326 
>Unformatted:
