Hi,
just a quick update: I still need to run with TSO off on RELENG_7
build Sep 1, because otherwise throughput via em interfaces is
sometimes very poor.
Lars
On Fri, May 22, 2009 at 03:50:07PM -0400, Michael L. Squires wrote:
>
>
> On Thu, 21 May 2009, Pyun YongHyeon wrote:
>
> >On Wed, May 20, 2009 at 05:55:29PM -0400, Michael L. Squires wrote:
> >>I started having speed problems after shifting from 7.1-STABLE to
> >>7.1-PRERELEASE. They have conti
On Thu, 21 May 2009, Pyun YongHyeon wrote:
On Wed, May 20, 2009 at 05:55:29PM -0400, Michael L. Squires wrote:
I started having speed problems after shifting from 7.1-STABLE to
7.1-PRERELEASE. They have continued with 7.2-STABLLE.
Reverting to the 7.1-STABLE kernel eliminated the problem.
On Wed, May 20, 2009 at 05:55:29PM -0400, Michael L. Squires wrote:
> I started having speed problems after shifting from 7.1-STABLE to
> 7.1-PRERELEASE. They have continued with 7.2-STABLLE.
>
> Reverting to the 7.1-STABLE kernel eliminated the problem.
>
> After downloading 7.2-STABLE from cv
I started having speed problems after shifting from 7.1-STABLE to
7.1-PRERELEASE. They have continued with 7.2-STABLLE.
Reverting to the 7.1-STABLE kernel eliminated the problem.
After downloading 7.2-STABLE from cvsup.freebsd.org at about 10:40 AM EST
on 5/20/2009, doing a buildworld/buildker
Hello, Lars.
You wrote 14 мая 2009 г., 12:28:43:
> Reproducing the issue is as easy as setting net.inet.tcp.tso=1.
> What's interesting is that I only see the issue on one of the eight em
> interfaces. That interface is connected to a D-Link DIR-655 WLAN
> router. When I tcpdump on the other int
On Thu, May 14, 2009 at 11:28:43AM +0300, Lars Eggert wrote:
> Hi,
>
> On 2009-5-14, at 11:27, Pyun YongHyeon wrote:
> >Then you're seeing different problem on em(4). Last time I checked
> >em(4) TSO code in em(4) didn't use m_pullup and just returned
> >ENXIO to caller. I'm not sure that is relat
In my case, it's a
e...@pci0:12:0:0: class=0x02 card=0x135e8086 chip=0x105e8086
rev=0x06 hdr=0x00
vendor = 'Intel Corporation'
device = 'PRO/1000 PT'
class = network
subclass = ethernet
Lars
On 2009-5-14, at 11:46, Lev Serebryakov wrote:
Hello, Lars.
You w
Hi,
On 2009-5-14, at 11:27, Pyun YongHyeon wrote:
Then you're seeing different problem on em(4). Last time I checked
em(4) TSO code in em(4) didn't use m_pullup and just returned
ENXIO to caller. I'm not sure that is related with your issue but
would you tell us your network configuration?
thi
On Thu, May 14, 2009 at 10:10:12AM +0300, Lars Eggert wrote:
> Hi,
>
> I've been seeing similar issues ("IP bad-len 0" packets in tcpdump
> traces") since 7.2-STABLE and em interfaces. Turning off TSO seems to
> do the trick here, too. So at least from where I'm sitting, this is
> not only a
Hi,
I've been seeing similar issues ("IP bad-len 0" packets in tcpdump
traces") since 7.2-STABLE and em interfaces. Turning off TSO seems to
do the trick here, too. So at least from where I'm sitting, this is
not only an fxp problem.
Lars
On Wed, May 13, 2009 at 10:52:34AM +1200, Nigel Wohlers wrote:
> On 13/5/09 8:41 AM, Xin LI wrote:
> >-BEGIN PGP SIGNED MESSAGE-
> >Hash: SHA1
> >
> >Hi David,
> >
> >David Samms wrote:
> >>After upgrading to 7.2 (amd64) some customers complained of very poor
> >>bandwidth. Upon investigat
On 13/5/09 8:41 AM, Xin LI wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi David,
David Samms wrote:
After upgrading to 7.2 (amd64) some customers complained of very poor
bandwidth. Upon investigation all the effected customers were ATT DSL
clients located all over the USA, not in a s
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi, David,
David Samms wrote:
> Xin LI wrote:
>> Hi David,
>>
>> David Samms wrote:
>>> After upgrading to 7.2 (amd64) some customers complained of very poor
>>> bandwidth. Upon investigation all the effected customers were ATT DSL
>>> clients locate
On Tue, May 12, 2009 at 05:31:01PM -0400, David Samms wrote:
>
> Setting sysctl net.inet.tcp.tso=0 resolved the issue completely. What
> does sysctl net.inet.tcp.tso=0 do?
# sysctl -d net.inet.tcp.tso
net.inet.tcp.tso: Enable TCP Segmentation Offload
I had a similar problem with a different N
Xin LI wrote:
Hi David,
David Samms wrote:
After upgrading to 7.2 (amd64) some customers complained of very poor
bandwidth. Upon investigation all the effected customers were ATT DSL
clients located all over the USA, not in a single city, nor were other
ISPs effected. The server is a Supermic
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi David,
David Samms wrote:
> After upgrading to 7.2 (amd64) some customers complained of very poor
> bandwidth. Upon investigation all the effected customers were ATT DSL
> clients located all over the USA, not in a single city, nor were other
> IS
After upgrading to 7.2 (amd64) some customers complained of very poor
bandwidth. Upon investigation all the effected customers were ATT DSL
clients located all over the USA, not in a single city, nor were other
ISPs effected. The server is a Supermicro with dual (quad core)
processors with a
18 matches
Mail list logo
