The following reply was made to PR kern/144529; it has been noted by GNATS.
From: dfil...@freebsd.org (dfilter service)
To: bug-follo...@freebsd.org
Cc:
Subject: Re: kern/144529: commit references a PR
Date: Fri, 12 Mar 2010 08:10:42 + (UTC)
Author: rrs
Date: Fri Mar 12 08:10:30 2010
New
Old Synopsis: em(4) problem with dual-port adapter
New Synopsis: [em] em(4) problem with dual-port adapter
Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Fri Mar 12 08:32:37 UTC 2010
Responsible-Changed-Why:
Over to maintainer(s).
Hi,all
Based on Freebsd8.0,the multicast frames are transmited at a fixed rate 1Mbps.
I want to change the fixed rate to self-adaptive rate like unicast.
I change the multicast path to unicast in if_ath.c of ath code,but still
fail.Should I change the rate control algorithm? What changes I mus
On Fri, Mar 12, 2010 at 05:07:09PM +0800, jiani1012 wrote:
> Hi,all
>
> Based on Freebsd8.0,the multicast frames are transmited at a fixed rate
> 1Mbps. I want to change the fixed rate to self-adaptive rate like unicast.
>
> I change the multicast path to unicast in if_ath.c of ath code,but sti
Jack Vogel wrote:
The difference between things being tweaked vs not is quite dramatic,
like getting only 2 or 3 Gb versus getting 9.5 when properly set up.
The multiqueue stack support in 8.0 is part of the equation, and in
7.X you wont have that. >
Any other tweaks beyond using the bleeding
Speaking of multiqueue support in intel 10G, such as 82598,
if we use RSS feature, can we select certain ip/port pair to open a tcp
connection,
so that the returning packet will come back from a pre-known receive queue?
2010-03-12
beezarliu
发件人： Jack Vogel
发送时间： 2010-03-12 02:57:15
Old Synopsis: TCP transfer corruption using if_re
New Synopsis: [re] TCP transfer corruption using if_re
Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Fri Mar 12 13:19:14 UTC 2010
Responsible-Changed-Why:
Over to maintainer(s).
h
Jack Vogel wrote:
The 1.3.3 driver is two years old, and your OS is older. I would
respectfully suggest that you update to 8.0 where lots of effort was
put to make 10G hardware perform up to its capabilities.
OK, done source-upgrading kernel+world to 8.0-RELEASE-p2 with its stock
ixgbe driver
rihad wrote:
1800-2000 "fragmentation failed" errors per refresh.
Sorry, that's ~15000 "fragmentation failed" errors on output at 120K
input packets.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To
Maybe turning DEVICE_POLLING on would be better? According to polling(4)
ixgb supports it, but not ixgbe.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubs
rihad wrote:
Things have gotten much worse. Please help.
Turning hw.intr_storm_threshold back to 1000 solved the problem, at
least when dummynet is not in use. I wonder who was the kind soul to
write that tip in the ixgbe-1.3.3 readme file...
Important system configuration changes:
--
rihad wrote:
rihad wrote:
Things have gotten much worse. Please help.
Turning hw.intr_storm_threshold back to 1000 solved the problem, at
least when dummynet is not in use.
Although the IP "fragmentation failed" errors (according to systat -ip)
are still there, around 5-10% of the input
Synopsis: [re] TCP transfer corruption using if_re
State-Changed-From-To: open->feedback
State-Changed-By: yongari
State-Changed-When: Fri Mar 12 17:53:37 UTC 2010
State-Changed-Why:
This looks like Rx checksum offloading issue. Would you try
disabling Rx checksum offloading and test it again?
#i
rihad wrote:
Turning hw.intr_storm_threshold back to 1000 solved the problem
Nope, nothing solved, it was a coincidence that the traffic stayed at
the high level more than a few minutes. Now we're back to this:
Turning dummynet off ("pipe tablearg", ~6000 table entries) improves
things a b
Synopsis: [rc.d] async dhclient breaks stuff for too many people,
synchronous_dhclient should be enabled by default
Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Fri Mar 12 18:45:39 UTC 2010
Responsible-Changed-Why:
Although this
The following reply was made to PR kern/144680; it has been noted by GNATS.
From: Garrett Cooper
To: Pavel Argentov
Cc: freebsd-gnats-sub...@freebsd.org
Subject: Re: kern/144680: em(4) problem with dual-port adapter
Date: Fri, 12 Mar 2010 14:13:47 -0800
On Fri, Mar 12, 2010 at 12:25 AM, Pavel
The following reply was made to PR kern/144529; it has been noted by GNATS.
From: dfil...@freebsd.org (dfilter service)
To: bug-follo...@freebsd.org
Cc:
Subject: Re: kern/144529: commit references a PR
Date: Fri, 12 Mar 2010 22:59:06 + (UTC)
Author: rrs
Date: Fri Mar 12 22:58:52 2010
New
On Fri, Mar 12, 2010 at 4:19 PM, Steven Noonan wrote:
> On Fri, Mar 12, 2010 at 9:54 AM, wrote:
>> Synopsis: [re] TCP transfer corruption using if_re
>>
>> State-Changed-From-To: open->feedback
>> State-Changed-By: yongari
>> State-Changed-When: Fri Mar 12 17:53:37 UTC 2010
>> State-Changed-Why:
On Fri, Mar 12, 2010 at 9:54 AM, wrote:
> Synopsis: [re] TCP transfer corruption using if_re
>
> State-Changed-From-To: open->feedback
> State-Changed-By: yongari
> State-Changed-When: Fri Mar 12 17:53:37 UTC 2010
> State-Changed-Why:
> This looks like Rx checksum offloading issue. Would you try
Turning LRO off (ifconfig x.x.x.x -lro) instantly stopped the
"Fragmentation failed" errors and solved the problem. Thank you.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail t
On Fri, Mar 12, 2010 at 4:24 PM, Steven Noonan wrote:
> On Fri, Mar 12, 2010 at 4:19 PM, Steven Noonan wrote:
>> On Fri, Mar 12, 2010 at 9:54 AM, wrote:
>>> Synopsis: [re] TCP transfer corruption using if_re
>>>
>>> State-Changed-From-To: open->feedback
>>> State-Changed-By: yongari
>>> State-C
21 matches
Mail list logo
