headers
Jun-ichiro itojun Hagino | 1 Sep 2003 02:57

PF status

	in case people are wondering what have happend to PF-on-netbsd:

	i'm still awaiting kjc to update/clarify PF/ALTQ api portion.  other
	than that there's no major issue - PF-on-netbsd is working fine
	on my home router.

itojun
Permalink | Reply | 6 comments |
headers
Jon Olsson | 1 Sep 2003 09:52
Picon
Picon

Re: PF status

On Mon, Sep 01, 2003 at 09:57:56AM +0900, Jun-ichiro itojun Hagino wrote:
> 	in case people are wondering what have happend to PF-on-netbsd:
> 
> 	i'm still awaiting kjc to update/clarify PF/ALTQ api portion.  other
> 	than that there's no major issue - PF-on-netbsd is working fine
> 	on my home router.

Are there any up-to-date patches up for testing it? And do they include
the userland tools?

Cheers,
Jon

> 
> itojun
Permalink | Reply | 3 comments |
headers
Greg A. Woods | 1 Sep 2003 21:32
X-Face
Favicon

Re: kern/16346: pcn driver panics on startup in IBM PC/325

After reading various changes and commit-logs to some similar drivers I
took a bit of implied advice from another fix and read the DP83840 data
sheet to see if I could see any obvious reasons why the MII would fail
to attach when link was already established but would work just fine if
unplugged during boot.

One thing did indeed jump out at me:

	Driver code should wait 500us following a software reset before
	allowing further serial MII operations with the DP83840A.

A quick glance at the PHY_RESET() routine used for this particular MII
device (the default one) reveals that the driver tries immediately to
read the reset bit instead of first waiting as suggested.

I haven't had time to try the following rather conservative (timing wise
and given it is to the generic PHY_RESET()) patch (since I'm still using
this system as my main $HOME server and need some planning to schedule a
reboot), but maybe someone with more experience with the MII drivers and
maybe this device in particular can let me know if I'm headed in the
right direction or not before I do get to testing it.

Index: sys/dev/mii/mii_physubr.c
===================================================================
RCS file: /cvs/master/m-NetBSD/main/src/sys/dev/mii/mii_physubr.c,v
retrieving revision 1.33
diff -c -c -r1.33 mii_physubr.c
*** mii_physubr.c	12 May 2002 21:39:46 -0000	1.33
--- mii_physubr.c	1 Sep 2003 19:10:35 -0000
***************
(Continue reading)

Permalink | Reply | 501 comments |
headers
Stephen Borrill | 2 Sep 2003 10:41
Picon
Favicon

bge0 doesn't like to autodetect gigabit

I've noticed that IBM servers with onboard Broadcom gigabit ethernet seem
to have issues when connected to gigabit switches. I've tried Netgear and
HP switches and on both, I've had to hardwire the switch and server to
1Gbps to get them to talk Gb otherwise they negotiate 100Mbps. It also
seems that this must be done in the right order otherwise the server
hardware needs resetting to get any connection, i.e. it was veyr easy to
get into a state when even setting both ends to auto didn't work. I have a
hunch (as yet unconfirmed) that it is still possible for the driver to
'jam'. By comparison, the wm driver just works when connected to the same
switches. This is using 1.6.1, is -current improved?

In addition, when running at 1000baseT everytime you do anything to the
interface (even just a ifconfig -a) it reports "bge0: gigabit link
up" twice to the console. This can rapidly fill up the dmesg buffer and
gives the impression to users that it previously wasn't (i.e. the
connection is going up and down). The source indicates that this are just
printed pretty much any time bge_tick() is called.

--

-- 
Stephen
Permalink | Reply | 6 comments |
headers
Bryan Vyhmeister | 2 Sep 2003 10:52

Re: bge0 doesn't like to autodetect gigabit

> I've noticed that IBM servers with onboard Broadcom gigabit ethernet
seem
> to have issues when connected to gigabit switches. I've tried Netgear
and
> HP switches and on both, I've had to hardwire the switch and server to
> 1Gbps to get them to talk Gb otherwise they negotiate 100Mbps. It also
> seems that this must be done in the right order otherwise the server
> hardware needs resetting to get any connection, i.e. it was veyr easy
to
> get into a state when even setting both ends to auto didn't work. I
have a
> hunch (as yet unconfirmed) that it is still possible for the driver to
> 'jam'. By comparison, the wm driver just works when connected to the
same
> switches. This is using 1.6.1, is -current improved?
> 
> In addition, when running at 1000baseT everytime you do anything to
the
> interface (even just a ifconfig -a) it reports "bge0: gigabit link
> up" twice to the console. This can rapidly fill up the dmesg buffer
and
> gives the impression to users that it previously wasn't (i.e. the
> connection is going up and down). The source indicates that this are
just
> printed pretty much any time bge_tick() is called.
> 

I have experienced the exact same problem except I am using a Supermicro
X5SS8-GM motherboard which has an onboard bge(4) interface. I have not
been able to get it to work with gigabit at all. I have been using
(Continue reading)

Permalink | Reply | 5 comments |
headers
itojun | 2 Sep 2003 11:17

Re: PF status

>> 	in case people are wondering what have happend to PF-on-netbsd:
>> 
>> 	i'm still awaiting kjc to update/clarify PF/ALTQ api portion.  other
>> 	than that there's no major issue - PF-on-netbsd is working fine
>> 	on my home router.
>
>Are there any up-to-date patches up for testing it? And do they include
>the userland tools?

	will roll a tarball.  please hold.

itojun
Permalink | Reply | 2 comments |
headers
itojun | 2 Sep 2003 12:23

Re: ipsec pcb/socket passing

>>	ftp://ftp.itojun.org/pub/netbsd-20030828-inet6hash.diff.gz
>>
>>	i'm running it on my important machines (email servers, routers)
>>	with no problem.  i would like to commit this, so comments please.
>
>I will merge it into the fast-ipsec I have tonight (I need to back out
>the similar common prefix I added, first) and give more detailed
>feedback (based on how it fits into fast-ipsec) within 36 hours.

	any comments?

itojun
Permalink | Reply | 0 comments |
headers
Jonathan Stone | 2 Sep 2003 18:59
Picon

Re: bge0 doesn't like to autodetect gigabit


In message <r02000100-1026-C3A32494DD2211D79B49000393D5E5DA <at> [10.0.1.30]>Bryan Vyhmeister writ
es
>> I've noticed that IBM servers with onboard Broadcom gigabit ethernet
>seem
>> to have issues when connected to gigabit switches. I've tried Netgear
>and

What kind of bge? Are these the same onboard 5703 on IBM servers for
which Matt Thomas(?)  added support, or something else again?

>> connection is going up and down). The source indicates that this are
>just
>> printed pretty much any time bge_tick() is called.

IIRC, that message (and calling bge_tick for link events) is allegedly
a workaround for a hardware bug/misfeature on the bcm5700 chip: the
hardware link-state FSM is broken and has to be checked in software.
The driver should not be taking that path at all for a 5701 or newer.

>I have experienced the exact same problem except I am using a Supermicro
>X5SS8-GM motherboard which has an onboard bge(4) interface. I have not
>been able to get it to work with gigabit at all. 

That's what you would get if the driver is not applying the correct
PHY/DSP patch for your particular hardware revision. What rev does the
driver claim, and what are the acutal PCI register values?

>I have been using
>Linksys switches. I tried this in 1.6.1 and also -current and it does
(Continue reading)

Permalink | Reply | 4 comments |
headers
Matthias Scheler | 2 Sep 2003 19:56
Picon
Favicon

Re: NAT and general network problems

In article <20030806101003.GA2516 <at> antioche.lip6.fr>,
	Manuel Bouyer <bouyer <at> antioche.lip6.fr> writes:
> No, I think he's just hitting the hard limit on NAT stats compiled in the
> kernel, which is pretty low (I think it's 127)

It must be higher. I've seen ten times more NAT connections on my firewall
when I'm using MLdonkey. But I'm not using two P2P clients at the same time.

	Kind regards

--

-- 
Matthias Scheler                                  http://scheler.de/~matthias/
Permalink | Reply | 1 comment |
headers
Bill Studenmund | 2 Sep 2003 21:42
Picon

Re: pulling in net80211/ from FreeBSD

On Sat, 30 Aug 2003, Jun-ichiro itojun Hagino wrote:

> > Just in case I am on crack, here's my plan.  First, copy the net80211/
> > sources from FreeBSD into my NetBSD tree, and add a net80211/Makefile:
>
> 	i guess "cvs import src/sys/net80211 FREEBSD datestamp" instead of
> 	"cvs add" will makes it easier for you to integrate future changes
> 	from freebsd.

Agreed. Then you just cvs add the Makefile you described.

Take care,

Bill
Permalink | Reply | 0 comments |

Gmane