The following reply was made to PR kern/118975; it has been noted by GNATS.
From: Benjamin Close <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
Cc:
Subject: Re: kern/118975: [bge] [patch] Broadcom 5906 not handled by FreeBSD
Date: Wed, 02 Jan 2008 18:42:34 +1030
The -Current port
On Jan 1, 2008 9:32 PM, Dag-Erling Smørgrav <[EMAIL PROTECTED]> wrote:
> "Sepherosa Ziehau" <[EMAIL PROTECTED]> writes:
> > I don't whether following thingies will fix your problem:
> > [...]
>
> Can you provide a diff?
http://people.freebsd.org/~sephe/rt2560_test.diff
Hope it will have some effe
On Jan 2, 2008 10:38 AM, Weongyo Jeong <[EMAIL PROTECTED]> wrote:
>
> > Even with these in place in dfly, I still have strange TX performance
> > regression in sta mode (drop from 20Mb/s to 3Mb/s under very well
> > condition) on certain hardwares after 20sec~30sec TCP_STREAM netperf
> > testing; d
Alfred Perlstein wrote:
* Julian Elischer <[EMAIL PROTECTED]> [071212 15:13] wrote:
Alfred Perlstein wrote:
try using "instance".
"Oh I'm going to use the FOO routing instance."
what do Juniper call it?
"Instance" and "vrf".
VRF is the same thing we call it at Cisco :-)
R
--
Randall
i seem to be loggin massive errors on an ath in hostap mode with
only two wireless clients.
mtu is set low as the tun0 ppoe over ntt B Flets on vr0 recommends
it. wireless on the two clients is set to mtu of 1454 too.
seeking pointers on how to debug.
randy
---
# netstat -i
NameMtu Networ
"Sepherosa Ziehau" <[EMAIL PROTECTED]> writes:
> http://people.freebsd.org/~sephe/rt2560_test.diff
Thank you, I'll try that.
Could you explain what the RT2560_BBP_BUSY loop is about?
DES
--
Dag-Erling Smørgrav - [EMAIL PROTECTED]
___
freebsd-net@freeb
"Sepherosa Ziehau" <[EMAIL PROTECTED]> writes:
> http://people.freebsd.org/~sephe/rt2560_test.diff
>
> Hope it will have some effect.
I built a new kernel with the patch applied, and it seems to help,
though it's a bit early to say for sure.
DES
--
Dag-Erling Smørgrav - [EMAIL PROTECTED]
___
Tiffany Snyder wrote:
Hi Andre,
are those numbers for small (64 bytes) packets? Good job on pushing
the base numbers higher on the same HW.
Yes, 64 bytes. Haven't measured lately, but I assume PCI-E hardware
instead of PCI-X could push quite some more.
What piqued my attentio
Andre Oppermann wrote:
So far the PPS rate limit has primarily been the cache miss penalties
on the packet access. Multiple CPUs can help here of course for bi-
directional traffic. Hardware based packet header cache prefetching as
done by some embedded MIPS based network processors at least do
Bruce M. Simpson wrote:
Andre Oppermann wrote:
So far the PPS rate limit has primarily been the cache miss penalties
on the packet access. Multiple CPUs can help here of course for bi-
directional traffic. Hardware based packet header cache prefetching as
done by some embedded MIPS based netwo
On Jan 3, 2008 12:16 AM, Dag-Erling Smørgrav <[EMAIL PROTECTED]> wrote:
> "Sepherosa Ziehau" <[EMAIL PROTECTED]> writes:
> > http://people.freebsd.org/~sephe/rt2560_test.diff
>
> Thank you, I'll try that.
>
> Could you explain what the RT2560_BBP_BUSY loop is about?
bbp read involves one write to
There are two early returns in unp_connect() that need to re-acquire the
UNP global lock before returning. This program will trigger a panic on
a WITNESS-enabled system. I tested on the December snapshot of
CURRENT-8.0, but the same problem occurs in RELENG_7.
#include
#include
#include
#incl
12 matches
Mail list logo
