Hiroki Sato wrote
in <20091220.053757.230970486@allbsd.org>:
hr> Jack Vogel 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> firmware. Go to the syste
On Fri, Jan 29, 2010 at 5:43 PM, Jack Vogel 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 kern/138392.
___
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 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
> i
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 regar
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 wrote:
> Does any of th
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 h
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 AM
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 >
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
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 sub
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 wrote:
>
> > I've been having
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 wrote:
> I've been having a similar problem with my network dropping completely on
> my
> 8-STABLE
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
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 wrote:
> On Tu
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
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 hardwar
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 myse
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?
Regard
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 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 wrote:
>
> > Is it ad
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 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
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 wrote:
> I've been having a similar pro
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 2
Hi,
On 2010-1-25, at 19:38, Nick Rogers wrote:
>> On Mon, Jan 25, 2010 at 10:22 AM, Pyun YongHyeon 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 offloading, see
On Mon, Jan 25, 2010 at 10:22 AM, Pyun YongHyeon 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 has nothi
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
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
di
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 2-
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 2-
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 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.
Well, I
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 wrote:
> John Nielsen wrote
> in <1e3c66ea-a6d3-44d7-b28e-bf0
John Nielsen wrote
in <1e3c66ea-a6d3-44d7-b28e-bf068fff1...@jnielsen.net>:
jo> On Dec 5, 2009, at 4:40 AM, Hiroki Sato wrote:
jo>
jo> > Hiroki Sato wrote
jo> > in <20091203.182931.129751456@allbsd.org>:
jo> >
jo> > hr> And another thing, I noticed a box with 82573E and 82573L
jo> > somet
On Dec 5, 2009, at 4:40 AM, Hiroki Sato wrote:
Hiroki Sato 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 b
Hiroki Sato 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
hr> then g
Hi Jack,
Jack Vogel 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 fail due to I
On 1 Dec 2009, at 12:05, Elliot Finley wrote:
> On Mon, Nov 30, 2009 at 6:29 PM, Hiroki Sato wrote:
> Jack Vogel 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
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 adap
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 wo
On Mon, Nov 30, 2009 at 6:29 PM, Hiroki Sato wrote:
> Jack Vogel 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.
>
>
Here's some more
Jack Vogel 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
pgp3TYQPpOkM
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 wrote:
> Hi,
>
> I noticed that network connection of one of my boxes got
> significantly slow just after upgrading it to 8.0R
Hi,
I noticed that network connection of one of my boxes got
significantly slow just after upgrading it to 8.0R. The box has an
em0 (82547EI) and worked fine with 7.2R.
The symptoms are:
- A ping to a host on the same LAN takes 990ms RTT, it reduces
gradually to around 1ms, and then it
43 matches
Mail list logo
