Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.

Dismiss

freebsd-net Digest, Vol 363, Issue 5

3 views

Skip to first unread message

freebsd-n...@freebsd.org

unread,

Mar 19, 2010, 8:00:23 AM3/19/10

to freeb...@freebsd.org

Send freebsd-net mailing list submissions to
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. zero copy feature (Alexander Bubnov)
2. Re: PF + BRIDGE + PFSYNC causes system freezing (Giulio Ferro)
3. Re: PF + BRIDGE + PFSYNC causes system freezing (Max Laier)
4. Re: kern/144844: [netgraph] souce in svn in 8/stable branch
different from shipped source - causing PPP errors with mpd (G B)
5. Re: kern/144808: xbox 360 unable to connect to ath in hostap
mode (rpa...@FreeBSD.org)
6. Re: PF + BRIDGE + PFSYNC causes system freezing (Giulio Ferro)
7. Re: PF + BRIDGE + PFSYNC causes system freezing (Max Laier)
8. Bug in tcp_output? (Chris Harrer)
9. Re: PF + BRIDGE + PFSYNC causes system freezing (Giulio Ferro)
10. RE: kern/134658: [bce] bce driver fails on PowerEdge m610
blade. (David Christensen)
11. Re: kern/134658: [bce] bce driver fails on PowerEdge m610
blade. (yon...@FreeBSD.org)
12. Re: kern/139761: [bce] bce driver on IBM HS22 [No PHY found
on Child MII bus] (yon...@FreeBSD.org)
13. Re: kern/140970: [bce] The two NetXtreme II BCM5709S NICs on
our HP Bl460c G1 Blade can't be accessed on FreeBSD 7.2 and 8
[regression] (yon...@FreeBSD.org)
14. Re: Running rtadvd or DHCPv6 server via if_bridge interface
(Stefan Bethke)
15. Re: Running rtadvd or DHCPv6 server via if_bridge interface
(Andrew Thompson)
16. Re: kern/134658: [bce] bce driver fails on PowerEdge m610
blade. (Hugo Koji Kobayashi)
17. Re: kern/135836: commit references a PR (dfilter service)
18. Re: kern/140684: commit references a PR (dfilter service)
19. Re: kern/135836: [bce] bce BCM5709 Watchdog after warm boot -
ok after cold boot (yon...@FreeBSD.org)
20. Re: kern/140684: [bce] Broadcom NetXtreme II BCM5709
1000Base-T - fail after soft reboot (yon...@FreeBSD.org)
21. Re: Software TKIP group rekeying and phase1 issue (Adrian Chadd)
22. Re: kern/144844: [netgraph] souce in svn in 8/stable branch
different from shipped source - causing PPP errors with mpd
(bru...@FreeBSD.org)
23. Re: kern/144564: lltable grows too much (b...@FreeBSD.org)
24. nfsv4 client/server protocol prob err=10020 (Martin Laabs)
25. Is this correct? (Ermal Lu?i)

----------------------------------------------------------------------

Message: 1
Date: Thu, 18 Mar 2010 16:08:12 +0300
From: Alexander Bubnov <alexande...@gmail.com>
Subject: zero copy feature
To: freeb...@freebsd.org
Message-ID:
<c3e287ff1003180608p5ac...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

Hello all!
I am sorry if I send this to incorrect mailist, but from HandBook I read:
freebsd-net Networking discussion and TCP/IP source code
My question related to this topic, so I have sent it to you.

I and my friends would like to study net programming in details using for
this purpose FreeBSD as this OS implements some unique features from other
ones. Moreover FreeBSD did net improvements not long ago.
One of a feature we are interested in is subj. But unfortunately there is no
much documentation about this, so we can only suggests usage of zero-copy by
man zero_copy or zero_copy sockets.
Can you please clarify one moment in zero_copy?

How I understand receiving.

Server side worked through TCP.
char*p=valloc(...);//I allocate some buffer by page aligned
...
int sd = accept(...);
...
read(sd,p,...);//trying to read

Buffer which I passed to read is supposed to used by kernel to copy TCP
payload to me avoiding its own socket buffer, another words my buffer
(pointed by p variable) which is passed to read is socket buffer in case
zero copy.

Question: Before accept returns descriptor to me the server can receive some
data. Where will be this data stored? Inside NIC cache? Or inside kernel
buffer which will be replaced by my buffer from read() later?

--
/BR, Alexander

------------------------------

Message: 2
Date: Thu, 18 Mar 2010 15:04:06 +0100
From: Giulio Ferro <au...@zirakzigil.org>
Subject: Re: PF + BRIDGE + PFSYNC causes system freezing
To: Max Laier <m...@love2party.net>
Cc: "freeb...@freebsd.org" <freeb...@freebsd.org>, Greg Hennessy
<Greg.H...@nviz.net>, freeb...@freebsd.org
Message-ID: <4BA232D6...@zirakzigil.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

On 17.03.2010 18:00, Max Laier wrote:
> Can you enable WITNESS and compile in DDB. Make sure to report any LORs
>>> and once the system freezes try to enter the debugger and get ps and
>>> locks information.
>>>
>>> show allchains
>>> show alllocks
>>> ps
>>>
>>> After that you can try to "call doadump" so you get the information in
>>> the coredump and don't have to transcribe it manually.
>>>
>>> Thanks,
>>> Max
>>>
>> Sorry, I'm not really an expert of this, but how can I enter the debugger
>> if the system has frozen?
>>
> Ctrl+Alt+ESC (in default configuration).
> _______________________________________________
>

I've added this to the kernel

option KDB
option WITNESS
option WITNESS_KDB
option DDB

Now it can't even boot properly. It stops when it tries to configure
networking:
uma_zalloc_arg: zone "256" with the following non-sleepable locks held:
exclusive rw ifnet_rw (ifnet_rw) r = 0 (0xffffffff80e31b20) locked @
/usr/src/sys/net/if.c:414

show allchains
<no result>

show alllocks
exclusive rw ifnet_rw (ifnet_rw) r = 0 (0xffffffff80e31b20) locked @
/usr/src/sys/net/if.c:414
exclusive sx ifnet_sx (ifnet_sx) r = 0 (0xffffffff80e31b40) locked @
/usr/src/sys/net/if.c:414

ps
<returns a lot of stuff. tell me to search something in particular>

call doadump
Cannot dump. Device not defined or unavailable

Hope it helps...

------------------------------

Message: 3
Date: Thu, 18 Mar 2010 15:26:00 +0100
From: Max Laier <m...@love2party.net>
Subject: Re: PF + BRIDGE + PFSYNC causes system freezing
To: freeb...@freebsd.org
Cc: Giulio Ferro <au...@zirakzigil.org>, Greg Hennessy
<Greg.H...@nviz.net>, freeb...@freebsd.org
Message-ID: <20100318152...@love2party.net>
Content-Type: Text/Plain; charset="iso-8859-1"

On Thursday 18 March 2010 15:04:06 Giulio Ferro wrote:
> On 17.03.2010 18:00, Max Laier wrote:
> > Can you enable WITNESS and compile in DDB. Make sure to report any LORs
> >
> >>> and once the system freezes try to enter the debugger and get ps and
> >>> locks information.
> >>>
> >>> show allchains
> >>> show alllocks
> >>> ps
> >>>
> >>> After that you can try to "call doadump" so you get the information in
> >>> the coredump and don't have to transcribe it manually.
> >>>
> >>> Thanks,
> >>> Max
> >>
> >> Sorry, I'm not really an expert of this, but how can I enter the
> >> debugger if the system has frozen?
> >
> > Ctrl+Alt+ESC (in default configuration).
> > _______________________________________________
>
> I've added this to the kernel
>
> option KDB
> option WITNESS
> option WITNESS_KDB

remove WITNESS_KDB, it's not what you want.

> option DDB
>
>
> Now it can't even boot properly. It stops when it tries to configure
> networking:
> uma_zalloc_arg: zone "256" with the following non-sleepable locks held:
> exclusive rw ifnet_rw (ifnet_rw) r = 0 (0xffffffff80e31b20) locked @
> /usr/src/sys/net/if.c:414

a "bt" would help in this case to see where the bad alloc is.

> show allchains
> <no result>
>
> show alllocks
> exclusive rw ifnet_rw (ifnet_rw) r = 0 (0xffffffff80e31b20) locked @
> /usr/src/sys/net/if.c:414
> exclusive sx ifnet_sx (ifnet_sx) r = 0 (0xffffffff80e31b40) locked @
> /usr/src/sys/net/if.c:414
>
> ps
> <returns a lot of stuff. tell me to search something in particular>
>
> call doadump
> Cannot dump. Device not defined or unavailable

define "dumpdev" in rc.conf to a swap partition with enough space or call
dumpon(8).

Thanks,
Max

------------------------------

Message: 4
Date: Thu, 18 Mar 2010 15:00:15 GMT
From: G B <gno...@gmail.com>
Subject: Re: kern/144844: [netgraph] souce in svn in 8/stable branch
different from shipped source - causing PPP errors with mpd
To: freeb...@FreeBSD.org
Message-ID: <201003181500....@freefall.freebsd.org>

The following reply was made to PR kern/144844; it has been noted by GNATS.

From: G B <gno...@gmail.com>
To: bug-fo...@FreeBSD.org
Cc:
Subject: Re: kern/144844: [netgraph] souce in svn in 8/stable branch different
from shipped source - causing PPP errors with mpd
Date: Thu, 18 Mar 2010 21:29:36 +0700

Sorry, I just realized I was looking at the ng_ppp.h file in my
sources. Cancel this PR.

However, mpd5 ppp still doesn't work, but I've filed a bug with the mpd project.

Thanks,
Gabriel

------------------------------

Message: 5
Date: Thu, 18 Mar 2010 16:01:44 GMT
From: rpa...@FreeBSD.org
Subject: Re: kern/144808: xbox 360 unable to connect to ath in hostap
mode
To: ja...@stnlabs.com, rpa...@FreeBSD.org, freeb...@FreeBSD.org
Message-ID: <201003181601....@freefall.freebsd.org>

Synopsis: xbox 360 unable to connect to ath in hostap mode

State-Changed-From-To: open->closed
State-Changed-By: rpaulo
State-Changed-When: Thu Mar 18 16:01:24 UTC 2010
State-Changed-Why:
Problem fixed by issuing 'ifconfig wlan0 country US'.

http://www.freebsd.org/cgi/query-pr.cgi?pr=144808

------------------------------

Message: 6
Date: Thu, 18 Mar 2010 17:39:29 +0100
From: Giulio Ferro <au...@zirakzigil.org>
Subject: Re: PF + BRIDGE + PFSYNC causes system freezing
To: Max Laier <m...@love2party.net>
Cc: freeb...@freebsd.org, Greg Hennessy <Greg.H...@nviz.net>,
freeb...@freebsd.org
Message-ID: <4BA25741...@zirakzigil.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

On 18.03.2010 15:26, Max Laier wrote:

Ok, it's happened again...
and once the system freezes try to enter the debugger and get ps and
>>>>> locks information.
>>>>>
>>>>> show allchains
>>>>>

No result

>>>>> show alllocks
>>>>>

Process 4483 (sshd) thread 0xffffff0002ded3a0 (100159)
exclusive sx so_rcv_sx (so_rcv_sx) r = 0 (0xffffff0002c79b98) locked @
/usr/src/sys/kern/uipc_sockbuf.c:148
Process 12 (intr) thread 0xffffff000242b3a0 (100028)
exclusive sleep mutex if_bridge (if_bridge) r = 0 (0xffffff000282d018)
locked @ /usr/src/sys/modules/if_bridge/../../net/if_bridge.c:2162
Process 12 (intr) thread 0xffffff00023d3ae0 (100021)
exclusive slepp mutex Giant (Giant) r = 1 (0xffffffff80c6f660) locked @
/usr/src/sys/dev/usb/usb_transfer.c:3009
Process 12 (intr) thread 0xffffff00022603a0 (1000007)
exclusive sleep mutex carp_if (carp_if) r = 0 (0xffffff0002730360)
locked @ /usr/src/sys/netinet/ip_carp.c:881

>>>>> ps
>>>>>
>>>>>

This yields a lot of lines, tell me if you want me to report something
special

> a "bt" would help in this case to see where the bad alloc is.
>
>

Tracing pid 12 tid 100021 td 0xffffff00023d3ae0
kdb_enter() at kdb_enter+0x3d
...

Thank for your interest.

------------------------------

Message: 7
Date: Thu, 18 Mar 2010 20:35:56 +0100
From: Max Laier <m...@love2party.net>
Subject: Re: PF + BRIDGE + PFSYNC causes system freezing
To: Giulio Ferro <au...@zirakzigil.org>
Cc: freeb...@freebsd.org, Greg Hennessy <Greg.H...@nviz.net>,
freeb...@freebsd.org
Message-ID: <20100318203...@love2party.net>
Content-Type: Text/Plain; charset="iso-8859-1"

On Thursday 18 March 2010 17:39:29 Giulio Ferro wrote:
> On 18.03.2010 15:26, Max Laier wrote:
>
> Ok, it's happened again...
> and once the system freezes try to enter the debugger and get ps and
>
> >>>>> locks information.
> >>>>>
> >>>>> show allchains
>
> No result

Okay ... so it looks like this is a live lock (not a deadlock) and it's
probably caused by relooping packets. Now we "only" have to find the culprit
for the loop ...

can you share your setup details, again? The simpler the better.

> >>>>> show alllocks
>
> Process 4483 (sshd) thread 0xffffff0002ded3a0 (100159)
> exclusive sx so_rcv_sx (so_rcv_sx) r = 0 (0xffffff0002c79b98) locked @
> /usr/src/sys/kern/uipc_sockbuf.c:148
> Process 12 (intr) thread 0xffffff000242b3a0 (100028)
> exclusive sleep mutex if_bridge (if_bridge) r = 0 (0xffffff000282d018)
> locked @ /usr/src/sys/modules/if_bridge/../../net/if_bridge.c:2162
> Process 12 (intr) thread 0xffffff00023d3ae0 (100021)
> exclusive slepp mutex Giant (Giant) r = 1 (0xffffffff80c6f660) locked @
> /usr/src/sys/dev/usb/usb_transfer.c:3009
> Process 12 (intr) thread 0xffffff00022603a0 (1000007)
> exclusive sleep mutex carp_if (carp_if) r = 0 (0xffffff0002730360)
> locked @ /usr/src/sys/netinet/ip_carp.c:881
>
> >>>>> ps
>
> This yields a lot of lines, tell me if you want me to report something
> special
>
> > a "bt" would help in this case to see where the bad alloc is.
>
> Tracing pid 12 tid 100021 td 0xffffff00023d3ae0
> kdb_enter() at kdb_enter+0x3d
> ...
>
> Thank for your interest.
>
>
> !DSPAM:4ba25756174452108219161!
>

------------------------------

Message: 8
Date: Thu, 18 Mar 2010 16:19:53 -0400
From: "Chris Harrer" <cjha...@comcast.net>
Subject: Bug in tcp_output?
To: <freeb...@freebsd.org>
Message-ID: <006f01cac6d8$5fc03cb0$1f40b610$@net>
Content-Type: text/plain; charset="iso-8859-1"

Hi All,

In the following block of code, running on a x86_64 platform, I believe that
cwin should be declared as an int:

* If snd_nxt == snd_max and we have transmitted a FIN, the

* offset will be > 0 even if so_snd.sb_cc is 0, resulting in

* a negative length. This can also occur when TCP opens up

* its congestion window while receiving additional duplicate

* acks after fast-retransmit because TCP will reset snd_nxt

* to snd_max after the fast-retransmit.

* In the normal retransmit-FIN-only case, however, snd_nxt will

* be set to snd_una, the offset will be 0, and the length may

* wind up 0.

* If sack_rxmit is true we are retransmitting from the scoreboard

* in which case len is already set.

if (sack_rxmit == 0) {

if (sack_bytes_rxmt == 0)

len = ((long)ulmin(so->so_snd.sb_cc, sendwin) - off);

else {

long cwin; ß-- Should be an int

* We are inside of a SACK recovery episode and are

* sending new data, having retransmitted all the

* data possible in the scoreboard.

len = ((long)ulmin(so->so_snd.sb_cc, tp->snd_wnd)

- off);

* Don't remove this (len > 0) check !

* We explicitly check for len > 0 here (although it

* isn't really necessary), to work around a gcc

* optimization issue - to force gcc to compute

* len above. Without this check, the computation

* of len is bungled by the optimizer.

if (len > 0) {

cwin = tp->snd_cwnd -

(tp->snd_nxt - tp->sack_newdata) -

sack_bytes_rxmt;

if (cwin < 0)

cwin = 0;

len = lmin(len, cwin);

}

Consider the case where:

sack_rxmit = 0

sack_bytes_rxmt = 0x2238

off = 0

len =0xa19c

tp->snd_cwnd = 0x2238

tp->snd_nxt = 0xdd6d7974

tp->sack_newdata = 0xdd6d6858

In this case cwin evaluates to 0x00000000ffffe37c, which is not <0, but
instead huge. This causes the remaining data on the socket’s so->so_snd
buffer to be sent to the network causing more problems at the receiver which
is already dropping frames.

Thanks,

Chris

------------------------------

Message: 9
Date: Thu, 18 Mar 2010 21:37:54 +0100
From: Giulio Ferro <au...@zirakzigil.org>
Subject: Re: PF + BRIDGE + PFSYNC causes system freezing
To: Max Laier <m...@love2party.net>
Cc: freeb...@freebsd.org, Greg Hennessy <Greg.H...@nviz.net>,
freeb...@freebsd.org
Message-ID: <4BA28F22...@zirakzigil.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

On 18.03.2010 20:35, Max Laier wrote:

> Okay ... so it looks like this is a live lock (not a deadlock) and it's
> probably caused by relooping packets. Now we "only" have to find the culprit
> for the loop ...
>
> can you share your setup details, again? The simpler the better.
>
>

> uname -a
FreeBSD firewall-1.acme.com 8.0-STABLE FreeBSD 8.0-STABLE #2: Thu Mar 18
15:59:27 CET 2010 ro...@acme.com:/usr/obj/usr/src/sys/FIREWALL amd64

> cat /etc/sysctl.conf
net.inet.ip.forwarding=1
net.inet.ip.fastforwarding=1
net.inet.carp.preempt=1

Services running : sshd, named, inetd, ntpd, openvpn (tap), racoon,
pptp, asterisk

2 physical interfaces : bce0, bce1
11 vlan interfaces : vlan1, ..., vlan11 (vlandev bce1)
11 carp interfaces ; carp1, ..., carp11 (carp1 has 23 alias addresses)
1 bridge interfaces : bridge0 addm vlan35 (used by openvpn)
2 gif interfaces : gif0, gif1 (racoon / IPSEC)

8 static routes

pf packet filter : 12 rdr rules, 3 nat rules, set skip{lo0, bridge0}, 4
pass quick, block log all, about 30 pass keep state

This should be all.
I'm available for any test / patch...

Thanks.

------------------------------

Message: 10
Date: Thu, 18 Mar 2010 14:20:56 -0700
From: "David Christensen" <dav...@broadcom.com>
Subject: RE: kern/134658: [bce] bce driver fails on PowerEdge m610
blade.
To: "Herve Boulouis" <am...@aelita.org>, "freeb...@freebsd.org"
<freeb...@freebsd.org>
Cc: Oliver Fromme <ol...@lurza.secnetix.de>
Message-ID:
<5D267A3F22FD854F8F48B...@IRVEXCHCCR01.corp.ad.broadcom.com>

Content-Type: text/plain; charset=us-ascii

> >> Ooo!!
> >>
> >> Could you link me though to the patch Oliver, I don't seem to find
> >> any post on this thread between today and mid last year?
> >>
> >
> >Let's give more time to David. He can test my guess work and can
> >fix bugs in the patch. When all goes well he may commit the patch.
>
> (please keep me CC'ed as I'm not subscribed to -net)
>
> Hi,
>
> Is there any news about the patch ? I have a bunch of M610 I
> would like to install FreeBSD on :)

Just committed a patch to head written by pyunyh and verified by me.
Let me know if it works. I can get access to a M610 locally if you
run into problems.

Dave

------------------------------

Message: 11
Date: Thu, 18 Mar 2010 21:55:00 GMT
From: yon...@FreeBSD.org
Subject: Re: kern/134658: [bce] bce driver fails on PowerEdge m610
blade.
To: harald...@dell.com, yon...@FreeBSD.org,
freeb...@FreeBSD.org, yon...@FreeBSD.org
Message-ID: <201003182155....@freefall.freebsd.org>

Synopsis: [bce] bce driver fails on PowerEdge m610 blade.

State-Changed-From-To: open->patched
State-Changed-By: yongari
State-Changed-When: Thu Mar 18 21:54:05 UTC 2010
State-Changed-Why:
Patch committed to HEAD(r205299, r205300).

Responsible-Changed-From-To: freebsd-net->yongari
Responsible-Changed-By: yongari
Responsible-Changed-When: Thu Mar 18 21:54:05 UTC 2010
Responsible-Changed-Why:
Track.

http://www.freebsd.org/cgi/query-pr.cgi?pr=134658

------------------------------

Message: 12
Date: Thu, 18 Mar 2010 21:55:44 GMT
From: yon...@FreeBSD.org
Subject: Re: kern/139761: [bce] bce driver on IBM HS22 [No PHY found
on Child MII bus]
To: sebastia...@gmail.com, yon...@FreeBSD.org,
freeb...@FreeBSD.org, yon...@FreeBSD.org
Message-ID: <201003182155....@freefall.freebsd.org>

Synopsis: [bce] bce driver on IBM HS22 [No PHY found on Child MII bus]

State-Changed-From-To: open->patched
State-Changed-By: yongari
State-Changed-When: Thu Mar 18 21:55:10 UTC 2010
State-Changed-Why:
Patch committed to HEAD(r205299, r205300).

Responsible-Changed-From-To: freebsd-net->yongari
Responsible-Changed-By: yongari
Responsible-Changed-When: Thu Mar 18 21:55:10 UTC 2010
Responsible-Changed-Why:
Track.

http://www.freebsd.org/cgi/query-pr.cgi?pr=139761

------------------------------

Message: 13
Date: Thu, 18 Mar 2010 21:57:12 GMT
From: yon...@FreeBSD.org
Subject: Re: kern/140970: [bce] The two NetXtreme II BCM5709S NICs on
our HP Bl460c G1 Blade can't be accessed on FreeBSD 7.2 and 8
[regression]
To: kor...@itm.tum.de, yon...@FreeBSD.org, freeb...@FreeBSD.org,
yon...@FreeBSD.org
Message-ID: <201003182157....@freefall.freebsd.org>

Synopsis: [bce] The two NetXtreme II BCM5709S NICs on our HP Bl460c G1 Blade can't be accessed on FreeBSD 7.2 and 8 [regression]

State-Changed-From-To: open->patched
State-Changed-By: yongari
State-Changed-When: Thu Mar 18 21:56:45 UTC 2010
State-Changed-Why:
Patch committed to HEAD(r205299, r205300).

Responsible-Changed-From-To: freebsd-net->yongari
Responsible-Changed-By: yongari
Responsible-Changed-When: Thu Mar 18 21:56:45 UTC 2010
Responsible-Changed-Why:
Track.

http://www.freebsd.org/cgi/query-pr.cgi?pr=140970

------------------------------

Message: 14
Date: Thu, 18 Mar 2010 23:27:43 +0100
From: Stefan Bethke <s...@lassitu.de>
Subject: Re: Running rtadvd or DHCPv6 server via if_bridge interface
To: freeb...@freebsd.org
Cc: Andrew Thompson <tho...@FreeBSD.org>
Message-ID: <EFAF0399-1809-4902...@lassitu.de>
Content-Type: text/plain; charset=us-ascii

Am 11.12.2009 um 07:51 schrieb Chris Cowart:

> Bruce Cran wrote:
>> I have a router configured using if_bridge with a 4-port NIC that's
>> serving addresses over DHCP. I'd like to add in either rtadvd or
>> DHCPv6, but neither work because the bridge interface doesn't have an
>> IPv6 link-local address. Is there a way around this, or is it not
>> possible to serve IPv6 addresses over if_bridge interfaces?
>
> It's totally doable; you just have to assigned a link-local address to
> the bridge. There are some reasons why one isn't defined by default,
> which somebody more knowledgeable about the challenges in the
> implementation can highlight.
>
> Here's my configuration from rc.conf:
>
> ipv6_ifconfig_bridge0="2001:470:8337:10::1/64"
> ipv6_ifconfig_bridge0_alias0="fe80::2%bridge0 prefixlen 64"
>
> Once you're doing that, rtadvd will start doing the right thing.

I've just stumbled over this the first time.

I thought that best practice nowadays was to use the bridge interface for host communications, and leaving the physical interfaces unconfigured, so I'm a bit confused why if_bridge would not allow the auto-assignment of a link-local address.

If you have two or more bridged interfaces now, and you enable automatic assignment of link-local addresses, you already have multiple link-locals this way; having the bridge have one as well wouldn't make things worse (I think).

Slightly confused,
Stefan

--
Stefan Bethke <s...@lassitu.de> Fon +49 151 14070811

------------------------------

Message: 15
Date: Fri, 19 Mar 2010 13:00:40 +1300
From: Andrew Thompson <tho...@FreeBSD.org>
Subject: Re: Running rtadvd or DHCPv6 server via if_bridge interface
To: Stefan Bethke <s...@lassitu.de>
Cc: freeb...@freebsd.org
Message-ID: <20100319000...@citylink.fud.org.nz>
Content-Type: text/plain; charset=us-ascii

On Thu, Mar 18, 2010 at 11:27:43PM +0100, Stefan Bethke wrote:
> Am 11.12.2009 um 07:51 schrieb Chris Cowart:
>
> > Bruce Cran wrote:
> >> I have a router configured using if_bridge with a 4-port NIC that's
> >> serving addresses over DHCP. I'd like to add in either rtadvd or
> >> DHCPv6, but neither work because the bridge interface doesn't have an
> >> IPv6 link-local address. Is there a way around this, or is it not
> >> possible to serve IPv6 addresses over if_bridge interfaces?
> >
> > It's totally doable; you just have to assigned a link-local address to
> > the bridge. There are some reasons why one isn't defined by default,
> > which somebody more knowledgeable about the challenges in the
> > implementation can highlight.
> >
> > Here's my configuration from rc.conf:
> >
> > ipv6_ifconfig_bridge0="2001:470:8337:10::1/64"
> > ipv6_ifconfig_bridge0_alias0="fe80::2%bridge0 prefixlen 64"
> >
> > Once you're doing that, rtadvd will start doing the right thing.
>
> I've just stumbled over this the first time.
>
> I thought that best practice nowadays was to use the bridge interface for host communications, and leaving the physical interfaces unconfigured, so I'm a bit confused why if_bridge would not allow the auto-assignment of a link-local address.
>
> If you have two or more bridged interfaces now, and you enable automatic assignment of link-local addresses, you already have multiple link-locals this way; having the bridge have one as well wouldn't make things worse (I think).
>

http://svn.freebsd.org/viewvc/base?view=revision&revision=149829

"IPv6 auto-configuration is disabled. An IPv6 link-local address has a
link-local scope within one link, the spec is unclear for the bridge
case and it may cause scope violation."

That is the reason. I dont know if its still true but you would need to
find someone more familair with IPv6 to comment on it.

cheers,
Andrew

------------------------------

Message: 16
Date: Thu, 18 Mar 2010 21:01:32 -0300
From: Hugo Koji Kobayashi <ko...@registro.br>
Subject: Re: kern/134658: [bce] bce driver fails on PowerEdge m610
blade.
To: David Christensen <dav...@broadcom.com>
Cc: "freeb...@freebsd.org" <freeb...@freebsd.org>, Herve
Boulouis <am...@aelita.org>, Oliver Fromme <ol...@lurza.secnetix.de>
Message-ID: <20100319000...@registro.br>
Content-Type: text/plain; charset=us-ascii

On Thu, Mar 18, 2010 at 02:20:56PM -0700, David Christensen wrote:
> > >> Ooo!!
> > >>
> > >> Could you link me though to the patch Oliver, I don't seem to find
> > >> any post on this thread between today and mid last year?
> > >>
> > >
> > >Let's give more time to David. He can test my guess work and can
> > >fix bugs in the patch. When all goes well he may commit the patch.
> >
> > (please keep me CC'ed as I'm not subscribed to -net)
> >
> > Hi,
> >
> > Is there any news about the patch ? I have a bunch of M610 I
> > would like to install FreeBSD on :)
>
> Just committed a patch to head written by pyunyh and verified by me.
> Let me know if it works. I can get access to a M610 locally if you
> run into problems.

Copied r205299 and r205300 modified files to a releng8 install on a
m610 and now it works:

# uname -a
FreeBSD 8.0-STABLE FreeBSD 8.0-STABLE #2: Thu Mar 18 23:30:37 UTC 2010 root@:/usr/obj/usr/src/sys/GENERIC amd64

# dmesg | grep bce
bce0: <Broadcom NetXtreme II BCM5709 1000Base-SX (C0)> mem 0xda000000-0xdbffffff irq 36 at device 0.0 on pci1
miibus0: <MII bus> on bce0
bce0: Ethernet address: 00:26:b9:26:d6:40
bce0: [ITHREAD]
bce0: ASIC (0x57092000); Rev (C0); Bus (PCIe x4, 2.5Gbps); B/C (5.0.6); Flags (MSI|MFW); MFW (NCSI 2.0.3)
bce1: <Broadcom NetXtreme II BCM5709 1000Base-SX (C0)> mem 0xdc000000-0xddffffff irq 48 at device 0.1 on pci1
miibus1: <MII bus> on bce1
bce1: Ethernet address: 00:26:b9:26:d6:42
bce1: [ITHREAD]
bce1: ASIC (0x57092000); Rev (C0); Bus (PCIe x4, 2.5Gbps); B/C (5.0.6); Flags (MSI|MFW); MFW (NCSI 2.0.3)
bce0: link state changed to DOWN
bce0: link state changed to UP

# ifconfig
bce0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=401bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4>
ether 00:26:b9:26:d6:40
inet .......... netmask 0xfffffff0 broadcast ..........
media: Ethernet autoselect (1000baseSX <full-duplex>)
status: active
bce1: flags=8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=401bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4>
ether 00:26:b9:26:d6:42
media: Ethernet autoselect (1000baseSX <full-duplex>)
status: active
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
options=3<RXCSUM,TXCSUM>
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3
inet6 ::1 prefixlen 128
inet 127.0.0.1 netmask 0xff000000

Thanks a lot,
Hugo

------------------------------

Message: 17
Date: Fri, 19 Mar 2010 00:30:04 GMT
From: dfi...@FreeBSD.ORG (dfilter service)
Subject: Re: kern/135836: commit references a PR
To: freeb...@FreeBSD.org
Message-ID: <201003190030....@freefall.freebsd.org>

The following reply was made to PR kern/135836; it has been noted by GNATS.

From: dfi...@FreeBSD.ORG (dfilter service)
To: bug-fo...@FreeBSD.org
Cc:
Subject: Re: kern/135836: commit references a PR
Date: Fri, 19 Mar 2010 00:26:58 +0000 (UTC)

Author: yongari
Date: Fri Mar 19 00:26:45 2010
New Revision: 205303
URL: http://svn.freebsd.org/changeset/base/205303

Log:
MFC r202717:
- Added a workaround for NC-SI management firmware that would allow
frames to be accepted while the driver is resetting the hardware.
This failure is generally observed when broadcast frames are received
during driver load and will generate "Unable to write CTX memory"
errors.
- Small changes to driver flags display.

PR: kern/135836, kern/140684

Modified:
stable/8/sys/dev/bce/if_bce.c
stable/8/sys/dev/bce/if_bcereg.h
Directory Properties:
stable/8/sys/ (props changed)
stable/8/sys/amd64/include/xen/ (props changed)
stable/8/sys/cddl/contrib/opensolaris/ (props changed)
stable/8/sys/contrib/dev/acpica/ (props changed)
stable/8/sys/contrib/pf/ (props changed)
stable/8/sys/dev/xen/xenpci/ (props changed)

Modified: stable/8/sys/dev/bce/if_bce.c
==============================================================================
--- stable/8/sys/dev/bce/if_bce.c Fri Mar 19 00:19:55 2010 (r205302)
+++ stable/8/sys/dev/bce/if_bce.c Fri Mar 19 00:26:45 2010 (r205303)
@@ -371,6 +371,9 @@ static void bce_release_resources (struc
static int bce_fw_sync (struct bce_softc *, u32);
static void bce_load_rv2p_fw (struct bce_softc *, u32 *, u32, u32);
static void bce_load_cpu_fw (struct bce_softc *, struct cpu_reg *, struct fw_info *);
+static void bce_start_cpu (struct bce_softc *, struct cpu_reg *);
+static void bce_halt_cpu (struct bce_softc *, struct cpu_reg *);
+static void bce_start_rxp_cpu (struct bce_softc *);
static void bce_init_rxp_cpu (struct bce_softc *);
static void bce_init_txp_cpu (struct bce_softc *);
static void bce_init_tpat_cpu (struct bce_softc *);
@@ -603,9 +606,10 @@ bce_print_adapter_info(struct bce_softc
printf("B/C (%s); Flags (", sc->bce_bc_ver);

#ifdef BCE_JUMBO_HDRSPLIT
- printf("SPLT ");
+ printf("SPLT");
i++;
#endif
+
if (sc->bce_flags & BCE_USING_MSI_FLAG) {
if (i > 0) printf("|");
printf("MSI"); i++;
@@ -613,7 +617,7 @@ bce_print_adapter_info(struct bce_softc

if (sc->bce_flags & BCE_USING_MSIX_FLAG) {
if (i > 0) printf("|");
- printf("MSI-X "); i++;
+ printf("MSI-X"); i++;
}

if (sc->bce_phy_flags & BCE_PHY_2_5G_CAPABLE_FLAG) {
@@ -2976,6 +2980,7 @@ bce_dma_map_addr(void *arg, bus_dma_segm
/* |PG Buffers | none | none | none | none | */
/* |TX Buffers | none | none | none | none | */
/* |Chain Pages(1) | 4KiB | 4KiB | 4KiB | 4KiB | */
+/* |Context Memory | | | | | */
/* +-----------------+----------+----------+----------+----------+ */
/* */
/* (1) Must align with CPU page size (BCM_PAGE_SZIE). */
@@ -3665,15 +3670,10 @@ bce_load_cpu_fw(struct bce_softc *sc, st
struct fw_info *fw)
{
u32 offset;
- u32 val;

DBENTER(BCE_VERBOSE_RESET);

- /* Halt the CPU. */
- val = REG_RD_IND(sc, cpu_reg->mode);
- val |= cpu_reg->mode_value_halt;
- REG_WR_IND(sc, cpu_reg->mode, val);
- REG_WR_IND(sc, cpu_reg->state, cpu_reg->state_value_clear);
+ bce_halt_cpu(sc, cpu_reg);

/* Load the Text area. */
offset = cpu_reg->spad_base + (fw->text_addr - cpu_reg->mips_view_base);
@@ -3726,9 +3726,28 @@ bce_load_cpu_fw(struct bce_softc *sc, st
}
}

- /* Clear the pre-fetch instruction. */
- REG_WR_IND(sc, cpu_reg->inst, 0);
- REG_WR_IND(sc, cpu_reg->pc, fw->start_addr);
+ /* Clear the pre-fetch instruction and set the FW start address. */
+ REG_WR_IND(sc, cpu_reg->inst, 0);
+ REG_WR_IND(sc, cpu_reg->pc, fw->start_addr);
+
+ DBEXIT(BCE_VERBOSE_RESET);
+}
+
+
+/****************************************************************************/
+/* Starts the RISC processor. */
+/* */
+/* Assumes the CPU starting address has already been set. */
+/* */
+/* Returns: */
+/* Nothing. */
+/****************************************************************************/
+static void
+bce_start_cpu(struct bce_softc *sc, struct cpu_reg *cpu_reg)
+{
+ u32 val;
+
+ DBENTER(BCE_VERBOSE_RESET);

/* Start the CPU. */
val = REG_RD_IND(sc, cpu_reg->mode);
@@ -3741,6 +3760,62 @@ bce_load_cpu_fw(struct bce_softc *sc, st

/****************************************************************************/
+/* Halts the RISC processor. */
+/* */
+/* Returns: */
+/* Nothing. */
+/****************************************************************************/
+static void
+bce_halt_cpu(struct bce_softc *sc, struct cpu_reg *cpu_reg)
+{
+ u32 val;
+
+ DBENTER(BCE_VERBOSE_RESET);
+
+ /* Halt the CPU. */
+ val = REG_RD_IND(sc, cpu_reg->mode);
+ val |= cpu_reg->mode_value_halt;
+ REG_WR_IND(sc, cpu_reg->mode, val);
+ REG_WR_IND(sc, cpu_reg->state, cpu_reg->state_value_clear);
+
+ DBEXIT(BCE_VERBOSE_RESET);
+}
+
+
+/****************************************************************************/
+/* Initialize the RX CPU. */
+/* */
+/* Returns: */
+/* Nothing. */
+/****************************************************************************/
+static void
+bce_start_rxp_cpu(struct bce_softc *sc)
+{
+ struct cpu_reg cpu_reg;
+
+ DBENTER(BCE_VERBOSE_RESET);
+
+ cpu_reg.mode = BCE_RXP_CPU_MODE;
+ cpu_reg.mode_value_halt = BCE_RXP_CPU_MODE_SOFT_HALT;
+ cpu_reg.mode_value_sstep = BCE_RXP_CPU_MODE_STEP_ENA;
+ cpu_reg.state = BCE_RXP_CPU_STATE;
+ cpu_reg.state_value_clear = 0xffffff;
+ cpu_reg.gpr0 = BCE_RXP_CPU_REG_FILE;
+ cpu_reg.evmask = BCE_RXP_CPU_EVENT_MASK;
+ cpu_reg.pc = BCE_RXP_CPU_PROGRAM_COUNTER;
+ cpu_reg.inst = BCE_RXP_CPU_INSTRUCTION;
+ cpu_reg.bp = BCE_RXP_CPU_HW_BREAKPOINT;
+ cpu_reg.spad_base = BCE_RXP_SCRATCH;
+ cpu_reg.mips_view_base = 0x8000000;
+
+ DBPRINT(sc, BCE_INFO_RESET, "Starting RX firmware.\n");
+ bce_start_cpu(sc, &cpu_reg);
+
+ DBEXIT(BCE_VERBOSE_RESET);
+}
+
+
+/****************************************************************************/
/* Initialize the RX CPU. */
/* */
/* Returns: */
@@ -3833,6 +3908,8 @@ bce_init_rxp_cpu(struct bce_softc *sc)
DBPRINT(sc, BCE_INFO_RESET, "Loading RX firmware.\n");
bce_load_cpu_fw(sc, &cpu_reg, &fw);

+ /* Delay RXP start until initialization is complete. */
+
DBEXIT(BCE_VERBOSE_RESET);
}

@@ -3929,6 +4006,7 @@ bce_init_txp_cpu(struct bce_softc *sc)

DBPRINT(sc, BCE_INFO_RESET, "Loading TX firmware.\n");
bce_load_cpu_fw(sc, &cpu_reg, &fw);
+ bce_start_cpu(sc, &cpu_reg);

DBEXIT(BCE_VERBOSE_RESET);
}
@@ -4026,6 +4104,7 @@ bce_init_tpat_cpu(struct bce_softc *sc)

DBPRINT(sc, BCE_INFO_RESET, "Loading TPAT firmware.\n");
bce_load_cpu_fw(sc, &cpu_reg, &fw);
+ bce_start_cpu(sc, &cpu_reg);

DBEXIT(BCE_VERBOSE_RESET);
}
@@ -4123,6 +4202,7 @@ bce_init_cp_cpu(struct bce_softc *sc)

DBPRINT(sc, BCE_INFO_RESET, "Loading CP firmware.\n");
bce_load_cpu_fw(sc, &cpu_reg, &fw);
+ bce_start_cpu(sc, &cpu_reg);

DBEXIT(BCE_VERBOSE_RESET);
}
@@ -4220,6 +4300,7 @@ bce_init_com_cpu(struct bce_softc *sc)

DBPRINT(sc, BCE_INFO_RESET, "Loading COM firmware.\n");
bce_load_cpu_fw(sc, &cpu_reg, &fw);
+ bce_start_cpu(sc, &cpu_reg);

DBEXIT(BCE_VERBOSE_RESET);
}
@@ -4665,6 +4746,12 @@ bce_chipinit(struct bce_softc *sc)
/* Initialize the on-boards CPUs */
bce_init_cpus(sc);

+ /* Enable management frames (NC-SI) to flow to the MCP. */
+ if (sc->bce_flags & BCE_MFW_ENABLE_FLAG) {
+ val = REG_RD(sc, BCE_RPM_MGMT_PKT_CTRL) | BCE_RPM_MGMT_PKT_CTRL_MGMT_EN;
+ REG_WR(sc, BCE_RPM_MGMT_PKT_CTRL, val);
+ }
+
/* Prepare NVRAM for access. */
if (bce_init_nvram(sc)) {
rc = ENODEV;
@@ -4845,6 +4932,15 @@ bce_blockinit(struct bce_softc *sc)
/* Enable link state change interrupt generation. */
REG_WR(sc, BCE_HC_ATTN_BITS_ENABLE, STATUS_ATTN_BITS_LINK_STATE);

+ /* Enable the RXP. */
+ bce_start_rxp_cpu(sc);
+
+ /* Disable management frames (NC-SI) from flowing to the MCP. */
+ if (sc->bce_flags & BCE_MFW_ENABLE_FLAG) {
+ val = REG_RD(sc, BCE_RPM_MGMT_PKT_CTRL) & ~BCE_RPM_MGMT_PKT_CTRL_MGMT_EN;
+ REG_WR(sc, BCE_RPM_MGMT_PKT_CTRL, val);
+ }
+
/* Enable all remaining blocks in the MAC. */
if ((BCE_CHIP_NUM(sc) == BCE_CHIP_NUM_5709) ||
(BCE_CHIP_NUM(sc) == BCE_CHIP_NUM_5716))
@@ -5851,22 +5947,29 @@ bce_rx_intr(struct bce_softc *sc)
DBRUN(sc->debug_rx_mbuf_alloc--);
sc->free_rx_bd++;

- /*
- * Frames received on the NetXteme II are prepended with an
- * l2_fhdr structure which provides status information about
- * the received frame (including VLAN tags and checksum info).
- * The frames are also automatically adjusted to align the IP
- * header (i.e. two null bytes are inserted before the Ethernet
- * header). As a result the data DMA'd by the controller into
- * the mbuf is as follows:
- *
- * +---------+-----+---------------------+-----+
- * | l2_fhdr | pad | packet data | FCS |
- * +---------+-----+---------------------+-----+
- *
- * The l2_fhdr needs to be checked and skipped and the FCS needs
- * to be stripped before sending the packet up the stack.
- */
+ if(m0 == NULL) {
+ DBPRINT(sc, BCE_EXTREME_RECV, "%s(): Oops! Empty mbuf pointer "
+ "found in sc->rx_mbuf_ptr[0x%04X]!\n",
+ __FUNCTION__, sw_rx_cons_idx);
+ goto bce_rx_int_next_rx;
+ }
+
+ /*
+ * Frames received on the NetXteme II are prepended with an
+ * l2_fhdr structure which provides status information about
+ * the received frame (including VLAN tags and checksum info).
+ * The frames are also automatically adjusted to align the IP
+ * header (i.e. two null bytes are inserted before the Ethernet
+ * header). As a result the data DMA'd by the controller into
+ * the mbuf is as follows:
+ *
+ * +---------+-----+---------------------+-----+
+ * | l2_fhdr | pad | packet data | FCS |
+ * +---------+-----+---------------------+-----+
+ *
+ * The l2_fhdr needs to be checked and skipped and the FCS needs
+ * to be stripped before sending the packet up the stack.
+ */
l2fhdr = mtod(m0, struct l2_fhdr *);

/* Get the packet data + FCS length and the status. */
@@ -6387,6 +6490,7 @@ bce_init_locked(struct bce_softc *sc)

bce_ifmedia_upd_locked(ifp);

+ /* Let the OS know the driver is up and running. */
ifp->if_drv_flags |= IFF_DRV_RUNNING;
ifp->if_drv_flags &= ~IFF_DRV_OACTIVE;

@@ -10038,9 +10142,9 @@ bce_dump_bc_state(struct bce_softc *sc)
BCE_PRINTF("0x%08X - (0x%06X) state\n",
val, BCE_BC_STATE);

- val = bce_shmem_rd(sc, BCE_BC_CONDITION);
+ val = bce_shmem_rd(sc, BCE_BC_STATE_CONDITION);
BCE_PRINTF("0x%08X - (0x%06X) condition\n",
- val, BCE_BC_CONDITION);
+ val, BCE_BC_STATE_CONDITION);

val = bce_shmem_rd(sc, BCE_BC_STATE_DEBUG_CMD);
BCE_PRINTF("0x%08X - (0x%06X) debug_cmd\n",

Modified: stable/8/sys/dev/bce/if_bcereg.h
==============================================================================
--- stable/8/sys/dev/bce/if_bcereg.h Fri Mar 19 00:19:55 2010 (r205302)
+++ stable/8/sys/dev/bce/if_bcereg.h Fri Mar 19 00:26:45 2010 (r205303)
@@ -3715,6 +3715,10 @@ struct l2_fhdr {
#define BCE_RPM_CONFIG_SORT_VECT_VAL (0xfL<<4)
#define BCE_RPM_CONFIG_IGNORE_VLAN (1L<<31)

+#define BCE_RPM_MGMT_PKT_CTRL 0x0000180c
+#define BCE_RPM_MGMT_PKT_CTRL_MGMT_DISCARD_EN (1L<<30)
+#define BCE_RPM_MGMT_PKT_CTRL_MGMT_EN (1L<<31)
+
#define BCE_RPM_VLAN_MATCH0 0x00001810
#define BCE_RPM_VLAN_MATCH0_RPM_VLAN_MTCH0_VALUE (0xfffL<<0)

_______________________________________________
svn-s...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all...@freebsd.org"

------------------------------

Message: 18
Date: Fri, 19 Mar 2010 00:30:07 GMT
From: dfi...@FreeBSD.ORG (dfilter service)
Subject: Re: kern/140684: commit references a PR
To: freeb...@FreeBSD.org
Message-ID: <201003190030....@freefall.freebsd.org>

The following reply was made to PR kern/140684; it has been noted by GNATS.

From: dfi...@FreeBSD.ORG (dfilter service)
To: bug-fo...@FreeBSD.org
Cc:
Subject: Re: kern/140684: commit references a PR
Date: Fri, 19 Mar 2010 00:26:59 +0000 (UTC)

------------------------------

Message: 19
Date: Fri, 19 Mar 2010 00:32:53 GMT
From: yon...@FreeBSD.org
Subject: Re: kern/135836: [bce] bce BCM5709 Watchdog after warm boot -
ok after cold boot
To: rwil...@borderware.com, yon...@FreeBSD.org,
freeb...@FreeBSD.org, yon...@FreeBSD.org
Message-ID: <201003190032....@freefall.freebsd.org>

Synopsis: [bce] bce BCM5709 Watchdog after warm boot - ok after cold boot

State-Changed-From-To: open->closed
State-Changed-By: yongari
State-Changed-When: Fri Mar 19 00:30:39 UTC 2010
State-Changed-Why:
Patch MFCed from HEAD. If you can still reproduce the issue please let me
know.

Responsible-Changed-From-To: freebsd-net->yongari
Responsible-Changed-By: yongari
Responsible-Changed-When: Fri Mar 19 00:30:39 UTC 2010
Responsible-Changed-Why:
Track.

http://www.freebsd.org/cgi/query-pr.cgi?pr=135836

------------------------------

Message: 20
Date: Fri, 19 Mar 2010 00:33:53 GMT
From: yon...@FreeBSD.org
Subject: Re: kern/140684: [bce] Broadcom NetXtreme II BCM5709
1000Base-T - fail after soft reboot
To: mks...@adhost.com, yon...@FreeBSD.org, freeb...@FreeBSD.org,
yon...@FreeBSD.org
Message-ID: <201003190033....@freefall.freebsd.org>

Synopsis: [bce] Broadcom NetXtreme II BCM5709 1000Base-T - fail after soft reboot

State-Changed-From-To: open->closed
State-Changed-By: yongari
State-Changed-When: Fri Mar 19 00:33:06 UTC 2010
State-Changed-Why:
Patch MFCed from HEAD. If you can still reproduce the issue please let me
know.

Responsible-Changed-From-To: freebsd-net->yongari
Responsible-Changed-By: yongari
Responsible-Changed-When: Fri Mar 19 00:33:06 UTC 2010
Responsible-Changed-Why:
Track.

http://www.freebsd.org/cgi/query-pr.cgi?pr=140684

------------------------------

Message: 21
Date: Fri, 19 Mar 2010 15:33:30 +0800
From: Adrian Chadd <adr...@freebsd.org>
Subject: Re: Software TKIP group rekeying and phase1 issue
To: Bernhard Schmidt <bsch...@techwires.net>
Cc: freeb...@freebsd.org
Message-ID:
<d763ac661003190033r1fd...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

On 7 February 2010 06:39, Bernhard Schmidt <bsch...@techwires.net> wrote:

>> Have you looked at other implementations?
>
> Doing that for all keys is probably right, have to test that.
>
> I did look at other implementation, they do zero out (tkip_ctx *)ctx inside
> tkip_setkey() and restore part of its content from the key, which has the side
> effect that rx_phase1_done also zero. No one handles that case intentionally.

Did you get any further with this?

Adrian

------------------------------

Message: 22
Date: Fri, 19 Mar 2010 08:41:50 GMT
From: bru...@FreeBSD.org
Subject: Re: kern/144844: [netgraph] souce in svn in 8/stable branch
different from shipped source - causing PPP errors with mpd
To: gno...@gmail.com, bru...@FreeBSD.org, freeb...@FreeBSD.org
Message-ID: <201003190841....@freefall.freebsd.org>

Synopsis: [netgraph] souce in svn in 8/stable branch different from shipped source - causing PPP errors with mpd

State-Changed-From-To: open->closed
State-Changed-By: brucec
State-Changed-When: Fri Mar 19 08:39:37 UTC 2010
State-Changed-Why:
Closed at submitter's request.

http://www.freebsd.org/cgi/query-pr.cgi?pr=144844

------------------------------

Message: 23
Date: Fri, 19 Mar 2010 08:55:57 GMT
From: b...@FreeBSD.org
Subject: Re: kern/144564: lltable grows too much
To: da...@korolev-net.ru, b...@FreeBSD.org, freeb...@FreeBSD.org,
b...@FreeBSD.org
Message-ID: <201003190855....@freefall.freebsd.org>

Synopsis: lltable grows too much

State-Changed-From-To: open->analyzed
State-Changed-By: bz
State-Changed-When: Fri Mar 19 08:53:31 UTC 2010
State-Changed-Why:
The problem has actually crashed cluster machines (ipv6gw)
already with
panic: kmem_malloc(4096): kmem_map too small: 335544320 total allocated
as
db> show malloc
Type InUse MemUse Requests
lltable 963374 240540K 963374
and I have looked at this and have a patch.

Responsible-Changed-From-To: freebsd-net->bz
Responsible-Changed-By: bz
Responsible-Changed-When: Fri Mar 19 08:53:31 UTC 2010
Responsible-Changed-Why:
Take, been working on this and have a patch.

http://www.freebsd.org/cgi/query-pr.cgi?pr=144564

------------------------------

Message: 24
Date: Fri, 19 Mar 2010 10:07:02 +0100
From: Martin Laabs <mailin...@martinlaabs.de>
Subject: nfsv4 client/server protocol prob err=10020
To: freeb...@freebsd.org
Message-ID: <4BA33EB...@martinlaabs.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Hello,

I currently try to set up a nfsv4 network at home. I have a server which
acts as KDC and kerberos server (I know the security advices to not do
that) and also as NFSv4 server.
On the server I have the following lines in my rc.conf

#NFS stuff
rpcbind_enable="YES"
nfsv4_server_enable="YES"
nfsuserd_enable="YES"
mountd_enable="YES"
mountd_flags="-r"
gssd_enable="YES"

#kerberos
kerberos5_server_enable="YES"
kadmind5_server_enable="YES"

on the client:

nfsuserd_enable="YES"
nfscbd_enable="YES"

I also set vfs.usermount=1 to mount the nfs as regular user that has a
kerberos principal. Beside the user principal I also created a
nfs/pc.martinlaabs.de principal for the client and exported it to the
client krb5.keytab.

The exports at the server side contains:

V4: /usr/home -sec=krb5p pc.martinlaabs.de

As user on my client I run mount_nfs -o tcp,nfsv4,sec=krb5p server:/ mnt
which returns only a warning that mount can not update mounttab which is OK.
However - if I access the mnt directory I get the following error:

bash:~$ ls mnt
ls: mnt: Input/output error

In the system message buffer I find the following message:

nfsv4 client/server protocol prob err=10020

As far as I know error 10020 means NFS4ERR_NOFILEHANDLE. I sometimes also
get the following message:

nfscl: consider increasing kern.ipc.maxsockbuf

But increasing does not affect the 10020 error.

On the server I can not find any log entries.
Can anyone interpret the error message and/or tell me what to do to get the
nfs service working?

Thank you,
Martin Laabs

PS: I use ipv6 for the nfs/kerberos stuff only.

------------------------------

Message: 25
Date: Fri, 19 Mar 2010 12:53:58 +0100
From: Ermal Lu?i <ermal...@gmail.com>
Subject: Is this correct?
To: freebsd-net <freeb...@freebsd.org>
Cc: "Bjoern A. Zeeb" <b...@freebsd.org>
Message-ID:
<9a542da31003190453s1e7...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

Shouldn't this check be
if (m->m_len > sizeof (struct ip)) {
instead of
if (m->m_len < sizeof (struct ip)) {

in
http://fxr.watson.org/fxr/source/netipsec/ipsec.c?im=excerpts#L595

Regards,
--
Ermal

------------------------------

End of freebsd-net Digest, Vol 363, Issue 5
*******************************************

0 new messages