freebsd-net Digest, Vol 183, Issue 2
freebsd-n...@freebsd.org
freeb...@freebsd.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.freebsd.org/mailman/listinfo/freebsd-net
or, via email, send a message with subject or body 'help' to
freebsd-n...@freebsd.org
You can reach the person managing the list at
freebsd-...@freebsd.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of freebsd-net digest..."
Today's Topics:
1. Re: Rapid link state changes on bge(4) interface (Paul Schmehl)
2. Re: Rapid link state changes on bge(4) interface (Ilya Nikitin)
3. Re: odd TCP rtt/retransmit timeout issue... (Dan Nelson)
4. Re: odd TCP rtt/retransmit timeout issue... (John-Mark Gurney)
5. Re: Rapid link state changes on bge(4) interface (Paul Schmehl)
6. Re: odd TCP rtt/retransmit timeout issue... (John-Mark Gurney)
7. Re: Rapid link state changes on bge(4) interface (Ilya Nikitin)
8. RE: TSO patch for current (sivakumar...@wipro.com)
9. IPMI & portrange (Danny Braniss)
10. Re: TSO patch for current (Andre Oppermann)
----------------------------------------------------------------------
Message: 1
Date: Mon, 25 Sep 2006 09:51:48 -0500
From: Paul Schmehl <pa...@utdallas.edu>
Subject: Re: Rapid link state changes on bge(4) interface
To: freeb...@freebsd.org
Message-ID: <B6B85999BF0B...@utd59514.utdallas.edu>
Content-Type: text/plain; charset="us-ascii"
--On Monday, September 25, 2006 10:51:54 +0400 Ilya Nikitin
<ilya_n...@migtel.ru> wrote:
>> On 9/21/06, Gleb Smirnoff <gle...@freebsd.org> wrote:
>
>>
>> No change. The link state is still floating.
>>
>> /S
>
> I've solved this problem by using bge drivers from 6.2-BETA1. There
> aren't bge flapping now !!!
>
Which driver version is that? I had to update the if_bce.c file from
version 0.9.5 to 0.9.6 to correct a problem with the NIC ceasing to pass
traffic and requiring a reboot to restore connectivity. (I'm running 6.1
RELEASE.)
Is this a newer version?
Paul Schmehl (pa...@utdallas.edu)
Adjunct Information Security Officer
The University of Texas at Dallas
http://www.utdallas.edu/ir/security/
------------------------------
Message: 2
Date: Mon, 25 Sep 2006 19:20:22 +0400
From: Ilya Nikitin <ilya_n...@migtel.ru>
Subject: Re: Rapid link state changes on bge(4) interface
To: freeb...@freebsd.org
Cc: pa...@utdallas.edu
Message-ID: <200609251920.22...@migtel.ru>
Content-Type: text/plain; charset="koi8-r"
>
> Which driver version is that? I had to update the if_bce.c file from
> version 0.9.5 to 0.9.6 to correct a problem with the NIC ceasing to pass
> traffic and requiring a reboot to restore connectivity. (I'm running 6.1
> RELEASE.)
>
> Is this a newer version?
Yes, it's strongly newer:
if_bge.c version: 1.91.2.17 2006/09/07
if_bge.h version: 1.36.2.7 2006/08/10
--------------------------------------------------------------------
Ilya Nikitin, System administrator, Mig-Telecom
tel. +7 495 775 7676
------------------------------
Message: 3
Date: Mon, 25 Sep 2006 10:46:59 -0500
From: Dan Nelson <dne...@allantgroup.com>
Subject: Re: odd TCP rtt/retransmit timeout issue...
To: cur...@FreeBSD.org, n...@FreeBSD.org, Andre Oppermann
<an...@FreeBSD.org>, moh...@FreeBSD.org
Message-ID: <20060925154...@dan.emsphone.com>
Content-Type: text/plain; charset=us-ascii
In the last episode (Sep 25), John-Mark Gurney said:
> I was brining up another interface that I just added to /etc/rc.conf
> and ran the command /etc/rc.d/netif start to initalize it... But
> then my connection never came back.... I found that the shell was
> still active as I could type commands like sleep 5, and another
> session's w would see sleep 5 run on the session... even filling up
> the send-q w/ 32k of data didn't get the HEAD box to send any data to
> the client...
>
> With the help of silby, I managed to find that the t_rxtcur value in
> the tcpcb was getting a very large value. The session that hung had
> a retransmit timeout of 19 days... This led us to find that the
> TCPT_RANGESET macro was letting very large tvmin values override the
> more sane tvmax values due to an extra else. I have added that so we
> shouldn't see any more multi day timeouts, but we still apparently
> have a problem where the rtt value calculated is wildly incorrect...
>
> It appears that each connection will get a different "random" rtt
> values... From a few connections to my machine:
> (kgdb) print ((struct tcpcb *)0xc3a34af8)->t_rxtcur
> $3 = 64000
> (kgdb) print ((struct tcpcb *)0xc3a3457c)->t_rxtcur
> $6 = 1662654093
> (kgdb) print ((struct tcpcb *)0xc3a343a8)->t_rxtcur
> $12 = 1358
> (kgdb) print ((struct tcpcb *)0xc3a9e1d4)->t_rxtcur
> $17 = 203
> (kgdb) print ((struct tcpcb *)0xc3a9e000)->t_rxtcur
> $19 = 284155863
Do you have net.inet.tcp.inflight.enable=1 ? You might be hitting
something related to kern/75122. You'll want to pull the raw gnats
repository file to read it; the query-pr.cgi web interface doesn't
parse the file right and it loses all the replies.
--
Dan Nelson
dne...@allantgroup.com
------------------------------
Message: 4
Date: Mon, 25 Sep 2006 08:56:58 -0700
From: John-Mark Gurney <gurn...@resnet.uoregon.edu>
Subject: Re: odd TCP rtt/retransmit timeout issue...
To: Dan Nelson <dne...@allantgroup.com>
Cc: moh...@FreeBSD.org, Andre Oppermann <an...@FreeBSD.org>,
cur...@FreeBSD.org, n...@FreeBSD.org
Message-ID: <20060925155...@funkthat.com>
Content-Type: text/plain; charset=us-ascii
Dan Nelson wrote this message on Mon, Sep 25, 2006 at 10:46 -0500:
> In the last episode (Sep 25), John-Mark Gurney said:
> > I was brining up another interface that I just added to /etc/rc.conf
> > and ran the command /etc/rc.d/netif start to initalize it... But
> > then my connection never came back.... I found that the shell was
> > still active as I could type commands like sleep 5, and another
> > session's w would see sleep 5 run on the session... even filling up
> > the send-q w/ 32k of data didn't get the HEAD box to send any data to
> > the client...
> >
> > With the help of silby, I managed to find that the t_rxtcur value in
> > the tcpcb was getting a very large value. The session that hung had
> > a retransmit timeout of 19 days... This led us to find that the
> > TCPT_RANGESET macro was letting very large tvmin values override the
> > more sane tvmax values due to an extra else. I have added that so we
> > shouldn't see any more multi day timeouts, but we still apparently
> > have a problem where the rtt value calculated is wildly incorrect...
> >
> > It appears that each connection will get a different "random" rtt
> > values... From a few connections to my machine:
> > (kgdb) print ((struct tcpcb *)0xc3a34af8)->t_rxtcur
> > $3 = 64000
> > (kgdb) print ((struct tcpcb *)0xc3a3457c)->t_rxtcur
> > $6 = 1662654093
> > (kgdb) print ((struct tcpcb *)0xc3a343a8)->t_rxtcur
> > $12 = 1358
> > (kgdb) print ((struct tcpcb *)0xc3a9e1d4)->t_rxtcur
> > $17 = 203
> > (kgdb) print ((struct tcpcb *)0xc3a9e000)->t_rxtcur
> > $19 = 284155863
>
> Do you have net.inet.tcp.inflight.enable=1 ? You might be hitting
Yes.
> something related to kern/75122. You'll want to pull the raw gnats
> repository file to read it; the query-pr.cgi web interface doesn't
> parse the file right and it loses all the replies.
Doesn't look like it... I just disabled inflight, and my first connection
got:
(kgdb) print ((struct tcpcb *)0xc3a4857c)->t_rxtcur
$1 = 921479340
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
------------------------------
Message: 5
Date: Mon, 25 Sep 2006 11:20:13 -0500
From: Paul Schmehl <pa...@utdallas.edu>
Subject: Re: Rapid link state changes on bge(4) interface
To: freeb...@freebsd.org
Message-ID: <B80C86369759...@utd59514.utdallas.edu>
Content-Type: text/plain; charset="us-ascii"
--On Monday, September 25, 2006 19:20:22 +0400 Ilya Nikitin
<ilya_n...@migtel.ru> wrote:
>>
>> Which driver version is that? I had to update the if_bce.c file from
>> version 0.9.5 to 0.9.6 to correct a problem with the NIC ceasing to pass
>> traffic and requiring a reboot to restore connectivity. (I'm running 6.1
>> RELEASE.)
>>
>> Is this a newer version?
>
> Yes, it's strongly newer:
>
> if_bge.c version: 1.91.2.17 2006/09/07
> if_bge.h version: 1.36.2.7 2006/08/10
>
That's the development branch. I'm talking about the driver version.
Inside the if_bce.c file, you will find this:
/****************************************************************************/
/* BCE Driver Version
*/
/****************************************************************************/
char bce_driver_version[] = "v0.9.6";
Is that the version you installed?
Paul Schmehl (pa...@utdallas.edu)
Adjunct Information Security Officer
The University of Texas at Dallas
http://www.utdallas.edu/ir/security/
------------------------------
Message: 6
Date: Mon, 25 Sep 2006 19:17:29 -0700
From: John-Mark Gurney <gurn...@resnet.uoregon.edu>
Subject: Re: odd TCP rtt/retransmit timeout issue...
To: cur...@FreeBSD.org, n...@FreeBSD.org, Andre Oppermann
<an...@FreeBSD.org>, moh...@FreeBSD.org
Message-ID: <20060926021...@funkthat.com>
Content-Type: text/plain; charset=us-ascii
John-Mark Gurney wrote this message on Mon, Sep 25, 2006 at 02:57 -0700:
> Anyone want to track down why we are getting such large values in
> there? I'll try to back track farther to see how old this issue is..
Managed to track it down:
jmg 2006-09-26 01:21:47 UTC
FreeBSD src repository
Modified files:
sys/netinet tcp_input.c
Log:
fix calculating to_tsecr... This prevents the rtt calculations from
going all wonky...
Revision Changes Path
1.309 +1 -1 src/sys/netinet/tcp_input.c
~12 days old for those who need to figure out if they need to upgrade
or not...
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
------------------------------
Message: 7
Date: Tue, 26 Sep 2006 10:25:48 +0400
From: Ilya Nikitin <ilya_n...@migtel.ru>
Subject: Re: Rapid link state changes on bge(4) interface
To: freeb...@freebsd.org
Message-ID: <200609261025.48...@migtel.ru>
Content-Type: text/plain; charset="koi8-r"
> That's the development branch. I'm talking about the driver version.
> Inside the if_bce.c file, you will find this:
>
> /**************************************************************************
>**/ /* BCE Driver Version
> */
> /**************************************************************************
>**/ char bce_driver_version[] = "v0.9.6";
>
> Is that the version you installed?
>
Sorry, I'm not a developer and I can do mistakes:
BCE Driver Version is older than your one:
bce_driver_version[] = "v0.9.5";
But I should remark, that previous brach was about bge driver (not bce)
Best regards,
--------------------------------------------------------------------
Ilya Nikitin, System administrator Mig-Telecom, Russia
tel. +7 495 775 7676
------------------------------
Message: 8
Date: Tue, 26 Sep 2006 12:43:31 +0530
From: <sivakumar...@wipro.com>
Subject: RE: TSO patch for current
To: <jfv...@gmail.com>, <freeb...@freebsd.org>,
<freebsd...@freebsd.org>
Message-ID:
<956E7FA2615F3B4595F...@blr-m3-msg.wipro.com>
Content-Type: text/plain; charset="us-ascii"
Is the TSO patch is checked in to the current?
Thanks,
~Siva
-----Original Message-----
From: owner-fr...@freebsd.org
[mailto:owner-fr...@freebsd.org] On Behalf Of Jack Vogel
Sent: Saturday, September 02, 2006 4:21 AM
To: freebsd-net; freebsd-current
Subject: RFC: TSO patch for current
This is a patch for the stack and the em driver to enable TSO
on CURRENT. Previously I had problems getting it to work, but
this is functional.
I should note that CURRENT is being a pain right now, when
I comment out em in the config the kernel panics coming up,
so I had to substitute this code into the tree. Rather bizarre :)
I have this functionality running on a 6.1 based system, and
our test group is already testing against that driver, so far
things are looking good.
I have designed it so the driver can continue to be built
without support. There is also a sysctl in the stack code
so you can set net.inet.tcp.tso_enable on or off and
compare.
I know there may be some refinements to add in, but I
would like to get this into CURRENT as a start.
Comments?
Jack
The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments.
WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.
------------------------------
Message: 9
Date: Tue, 26 Sep 2006 10:33:47 +0300
From: Danny Braniss <da...@cs.huji.ac.il>
Subject: IPMI & portrange
To: freeb...@freebsd.org
Message-ID: <E1GS7Rr-...@cs1.cs.huji.ac.il>
Content-Type: text/plain; charset=us-ascii
Hi,
This keeps bitting me every other upgrade, IPMI on some
hosts, if enabled, will steal packets to port 623 or 664, so
the current solution is either set net.inet.ip.portrange.lowlast
to 664, (for some reason this does not seem to work if done via
loader.conf) or change it in sys/netinet/in.h.
So, is there some way to blacklist some ports, instead
of increasing portrange.lowlast?
danny
------------------------------
Message: 10
Date: Tue, 26 Sep 2006 10:28:01 +0200
From: Andre Oppermann <an...@freebsd.org>
Subject: Re: TSO patch for current
To: sivakumar...@wipro.com
Cc: freeb...@freebsd.org, freebsd...@freebsd.org,
jfv...@gmail.com
Message-ID: <4518E491...@freebsd.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
sivakumar...@wipro.com wrote:
> Is the TSO patch is checked in to the current?
Yes, but a different one.
--
Andre
> Thanks,
> ~Siva
>
> -----Original Message-----
> From: owner-fr...@freebsd.org
> [mailto:owner-fr...@freebsd.org] On Behalf Of Jack Vogel
> Sent: Saturday, September 02, 2006 4:21 AM
> To: freebsd-net; freebsd-current
> Subject: RFC: TSO patch for current
>
> This is a patch for the stack and the em driver to enable TSO
> on CURRENT. Previously I had problems getting it to work, but
> this is functional.
>
> I should note that CURRENT is being a pain right now, when
> I comment out em in the config the kernel panics coming up,
> so I had to substitute this code into the tree. Rather bizarre :)
>
> I have this functionality running on a 6.1 based system, and
> our test group is already testing against that driver, so far
> things are looking good.
>
> I have designed it so the driver can continue to be built
> without support. There is also a sysctl in the stack code
> so you can set net.inet.tcp.tso_enable on or off and
> compare.
>
> I know there may be some refinements to add in, but I
> would like to get this into CURRENT as a start.
>
> Comments?
>
> Jack
>
>
> The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments.
>
>
> WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.
>
>
> www.wipro.com
> _______________________________________________
> freeb...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net...@freebsd.org"
>
>
------------------------------
End of freebsd-net Digest, Vol 183, Issue 2
*******************************************