Hiroki Sato h...@freebsd.org wrote
in 20091220.053757.230970486@allbsd.org:
hr Jack Vogel jfvo...@gmail.com wrote
hr in 2a41acea0912052327t7830f85aw5b4b581ab3f09...@mail.gmail.com:
hr
hr jf The 82573, when onboard (LOM) is usually special, it is used by system
hr jf management
hr jf
On Thu, Jan 28, 2010 at 11:16:02AM -0800, Jack Vogel wrote:
I am investigating it, and have a suspicion about what's going on, you can
assist in verifying my suspicion. In if_em.c search for em_setup_vlan_hw,
you will find a compile time option that uses that only if FreeBSD_version
is
No need, I set it up and tried it, and I was right, it does not fail if that
routine is not used. The interesting thing is that the igb driver, which
has the same code, works fine.
In any case, I'm hot on the track of this and hope I can figure it out
today.
Jack
On Fri, Jan 29, 2010 at 5:38
On Fri, Jan 29, 2010 at 09:45:42AM -0800, Jack Vogel wrote:
No need, I set it up and tried it, and I was right, it does not fail if that
routine is not used. The interesting thing is that the igb driver, which
has the same code, works fine.
In any case, I'm hot on the track of this and hope
You know, i know absolutely nothing about ALTQ :) This is the first I've
heard
about this problem, you should make sure the maintainer of the driver gets
informed sooner :)
Would be happy to look into it as I have time.
Jack
On Fri, Jan 29, 2010 at 5:28 PM, Nick Rogers ncrog...@gmail.com
Does any of this have anything to do with the fact that ALTQ seems to be
broken for em(4) under 8.0-RELEASE? I just ran into this similar problem
today where my PF/ALTQ hfsc rules no longer seem to do anything on em
interfaces.
http://forums.freebsd.org/showthread.php?t=6656
Any information
I just discovered it myself today. I'll try and post more info in another
thread.
On Fri, Jan 29, 2010 at 5:43 PM, Jack Vogel jfvo...@gmail.com wrote:
You know, i know absolutely nothing about ALTQ :) This is the first I've
heard
about this problem, you should make sure the maintainer of the
On Fri, Jan 29, 2010 at 5:43 PM, Jack Vogel jfvo...@gmail.com wrote:
You know, i know absolutely nothing about ALTQ :) This is the first I've
heard
about this problem, you should make sure the maintainer of the driver gets
informed sooner :)
Look like there is an old PR for it. See
On Tue, Jan 26, 2010 at 09:00:35AM -0800, Nick Rogers wrote:
Is it advisable to patch 8.0-RELEASE kernel sources with the latest
(CURRENT) em driver (i.e., src/sys/dev/e1000)? It looks like there are some
updates to the driver since 8.0-RELEASE that may fix some problems?
While on the em
I am investigating it, and have a suspicion about what's going on, you can
assist in verifying my suspicion. In if_em.c search for em_setup_vlan_hw,
you will find a compile time option that uses that only if FreeBSD_version
is 700029, hack the code however you wish so that it uses the OLD way
Is it advisable to patch 8.0-RELEASE kernel sources with the latest
(CURRENT) em driver (i.e., src/sys/dev/e1000)? It looks like there are some
updates to the driver since 8.0-RELEASE that may fix some problems?
On Mon, Jan 25, 2010 at 8:31 PM, Joshua Boyd boy...@jbip.net wrote:
I've been
looks like the patch mentioned in kern/141843 has not been applied to the
tree?
On Tue, Jan 26, 2010 at 9:00 AM, Nick Rogers ncrog...@gmail.com wrote:
Is it advisable to patch 8.0-RELEASE kernel sources with the latest
(CURRENT) em driver (i.e., src/sys/dev/e1000)? It looks like there are some
No, it hasn't, I need time to look it over and be convinced of what he was
doing.
Jack
On Tue, Jan 26, 2010 at 9:14 AM, Nick Rogers ncrog...@gmail.com wrote:
looks like the patch mentioned in kern/141843 has not been applied to the
tree?
On Tue, Jan 26, 2010 at 9:00 AM, Nick Rogers
I've tried this patch, and it completely breaks IPv6 offloads, which DO work
btw,
our testers have a netperf stress test that does both ipv4 and ipv6, and
that test
fails 100% after this change.
I could go hacking at it myself but as its your code Pyun would you like to
resolve this issue?
On Tue, Jan 26, 2010 at 11:55:00AM -0800, Jack Vogel wrote:
I've tried this patch, and it completely breaks IPv6 offloads, which DO work
btw,
our testers have a netperf stress test that does both ipv4 and ipv6, and
that test
fails 100% after this change.
I could go hacking at it myself but
Well, what our testers do is assign BOTH an ipv4 and ipv6 address to an
interface,
then netperf runs over both, I don't know the internal details but I assume
both TCP
and UDP are going over ipv6.
Prior to your change there is IPv6 handling code in the tx checksum
routine, so I
assume the
On Tue, Jan 26, 2010 at 12:22:01PM -0800, Jack Vogel wrote:
Well, what our testers do is assign BOTH an ipv4 and ipv6 address to an
interface,
then netperf runs over both, I don't know the internal details but I assume
both TCP
and UDP are going over ipv6.
Prior to your change there is
Great, if you can get the changes to me quickly I'd like to incorporate
them.
BTW, I have merged your igb changes into my code and its very stable, should
see that checked in for 7.3 shortly.
Thanks for your hard work Pyun!
Jack
On Tue, Jan 26, 2010 at 12:33 PM, Pyun YongHyeon
On Tue, Jan 26, 2010 at 12:36:22PM -0800, Jack Vogel wrote:
Great, if you can get the changes to me quickly I'd like to incorporate
them.
Unfortunately I couldn't reproduce it on my box. I've tested both
IPv4 and IPv6 at the same time with netperf and it worked as
expected.
Reading the code
Can anyone clarify if I should be looking to disable TSO or TXCSUM, or both,
or does disabling either one somehow work around the problem? Thanks a lot.
On Mon, Jan 25, 2010 at 8:31 PM, Joshua Boyd boy...@jbip.net wrote:
I've been having a similar problem with my network dropping completely on
On Tue, Jan 26, 2010 at 11:09:45PM -0800, Nick Rogers wrote:
Can anyone clarify if I should be looking to disable TSO or TXCSUM, or both,
or does disabling either one somehow work around the problem? Thanks a lot.
On Mon, Jan 25, 2010 at 8:31 PM, Joshua Boyd boy...@jbip.net wrote:
I've
Hi,
have you tried turning off TCP Segmentation Offloading (net.inet.tcp.tso
sysctl)? That fixed performance issues with some em cards for me.
Lars
On 2010-1-25, at 5:47, Nick Rogers wrote:
I am having similar em interface problems with some of my production
machines running older intel
Hi,
have you tried turning off TCP Segmentation Offloading (net.inet.tcp.tso
sysctl)? That fixed performance issues with some em cards for me.
Lars
On 2010-1-25, at 5:47, Nick Rogers wrote:
I am having similar em interface problems with some of my production
machines running older intel
I have not tried toying with any tcp sysctl. I'm not having performance
problems so much as the interface just stops working entirely, which I would
think has nothing to do with the TCP stack when layer 2 is not functioning?
I'll give it a shot if I can. For the moment I have had to switch to a
On Mon, Jan 25, 2010 at 08:25:43AM -0800, Nick Rogers wrote:
I have not tried toying with any tcp sysctl. I'm not having performance
problems so much as the interface just stops working entirely, which I would
think has nothing to do with the TCP stack when layer 2 is not functioning?
I'm
On Mon, Jan 25, 2010 at 10:22 AM, Pyun YongHyeon pyu...@gmail.com wrote:
On Mon, Jan 25, 2010 at 08:25:43AM -0800, Nick Rogers wrote:
I have not tried toying with any tcp sysctl. I'm not having performance
problems so much as the interface just stops working entirely, which I
would
think
Hi,
On 2010-1-25, at 19:38, Nick Rogers wrote:
On Mon, Jan 25, 2010 at 10:22 AM, Pyun YongHyeon pyu...@gmail.com wrote:
I'm not sure you're seeing a checksum offload bug of em(4) but the
bug is easily reproducible in VLAN environments. If the issue is
gone when you disable TX checksum
I've been having a similar problem with my network dropping completely on my
8-STABLE gateway/firewall/fileserver. My setup is a little different, as I
have re0 and ral0 bridged for LAN, and em0 for WAN. I've just turned off TX
checksum offloading to see if that makes any difference.
On Mon, Jan
I am having similar em interface problems with some of my production
machines running older intel 2-port cards, since upgrading from 7.2-RELEASE
to 8.0-RELEASE. The problem is basically, everything works fine, but
periodically the interface hangs (tcpdump shows no frames). A reboot or an
ifconfig
Hiroki Sato wrote:
Thank you! I have investigated some more details. First, I got
something wrong with the affected FreeBSD versions; one I tried was
8.0-STABLE, not 8.0-RELEASE. So I started to try 8.0R. A summary of
chips and releases I tried so far is now the following:
Jack Vogel jfvo...@gmail.com wrote
in 2a41acea0912052327t7830f85aw5b4b581ab3f09...@mail.gmail.com:
jf The 82573, when onboard (LOM) is usually special, it is used by system
jf management
jf firmware. Go to the system BIOS and turn off management, see if that
jf eliminates the
jf periodic hang.
Hiroki Sato h...@freebsd.org wrote
in 20091203.182931.129751456@allbsd.org:
hr And another thing, I noticed a box with 82573E and 82573L sometimes
hr got stuck after upgrading to 8.0-STABLE. It has moderate network
hr load (average 5-10Mbps) on both NICs. It worked for a day or two and
On Dec 5, 2009, at 4:40 AM, Hiroki Sato h...@freebsd.org wrote:
Hiroki Sato h...@freebsd.org wrote
in 20091203.182931.129751456@allbsd.org:
hr And another thing, I noticed a box with 82573E and 82573L
sometimes
hr got stuck after upgrading to 8.0-STABLE. It has moderate network
hr
John Nielsen j...@jnielsen.net wrote
in 1e3c66ea-a6d3-44d7-b28e-bf068fff1...@jnielsen.net:
jo On Dec 5, 2009, at 4:40 AM, Hiroki Sato h...@freebsd.org wrote:
jo
jo Hiroki Sato h...@freebsd.org wrote
jo in 20091203.182931.129751456@allbsd.org:
jo
jo hr And another thing, I noticed a box
The 82573, when onboard (LOM) is usually special, it is used by system
management
firmware. Go to the system BIOS and turn off management, see if that
eliminates the
periodic hang.
Jack
On Sat, Dec 5, 2009 at 9:27 PM, Hiroki Sato h...@freebsd.org wrote:
John Nielsen j...@jnielsen.net wrote
Hi Jack,
Jack Vogel jfvo...@gmail.com wrote
in 2a41acea0912021514r2d44dd33n4c364518d7fe1...@mail.gmail.com:
jf Update: the claim to be unable to install was hasty, I went in and looked
jf into myself and was able to get an install. Here's what I've found so far:
jf
jf First, the 82547EI will
We've run into a snag on this problem. The 82547 is a LOM only interface
and my validation engineer has only found two old systems that have it,
and neither of them will even install FreeBSD 8 they are so old :(
I might suggest that you continue using the 7.2 driver with that hardware
if it was
Update: the claim to be unable to install was hasty, I went in and looked
into myself and was able to get an install. Here's what I've found so far:
First, the 82547EI will fail due to Invalid Mac Address, so I guess you
hacked around this problem yourself? I had someone here test all
legacy
On 1 Dec 2009, at 12:05, Elliot Finley wrote:
On Mon, Nov 30, 2009 at 6:29 PM, Hiroki Sato h...@freebsd.org wrote:
Jack Vogel jfvo...@gmail.com wrote
in 2a41acea0911301119j1449be58y183f2fe1d1112...@mail.gmail.com:
jf I will look into this Hiroki, as time goes the older hardware does not
On Mon, Nov 30, 2009 at 6:29 PM, Hiroki Sato h...@freebsd.org wrote:
Jack Vogel jfvo...@gmail.com wrote
in 2a41acea0911301119j1449be58y183f2fe1d1112...@mail.gmail.com:
jf I will look into this Hiroki, as time goes the older hardware does not
jf always
jf get test cycles like one might
I will look into this Hiroki, as time goes the older hardware does not
always
get test cycles like one might wish.
Jack
On Mon, Nov 30, 2009 at 12:04 AM, Hiroki Sato h...@freebsd.org wrote:
Hi,
I noticed that network connection of one of my boxes got
significantly slow just after
Jack Vogel jfvo...@gmail.com wrote
in 2a41acea0911301119j1449be58y183f2fe1d1112...@mail.gmail.com:
jf I will look into this Hiroki, as time goes the older hardware does not
jf always
jf get test cycles like one might wish.
Thanks! Please let me know if you need more information.
-- Hiroki
42 matches
Mail list logo
