Hi,
I have a recent Supermicro board (Super X7DWT
Intel 5400 chipset) with two onboard NICs - Intel (ESB2/Gilgal) 82563EB
Dual-Port Gigabit Ethernet Controller
Usually boot up looks like this:
em0: Intel(R) PRO/1000 Network Connection Version - 6.7.3 port
0x3000-0x301f mem
*Originally posted to [EMAIL PROTECTED] mailing list but moved
here. Original may be found at
http://www.nabble.com/FreeBSD-7.0-RC1-syncache-problems-under-high-load-to14977783.html#a14981104
I am running web polygraph against a FreeBSD7.0-RC1 squid server and
experiencing problems. I have run
Hi Andrew,
Someone else has already reported this to me and in fact he is testing
a shared code
fix to see if it resolves it. I will be updating the driver if it does.
Jack
On Jan 20, 2008 12:32 AM, Andrew Snow [EMAIL PROTECTED] wrote:
Hi,
I have a recent Supermicro board (Super X7DWT
The following reply was made to PR kern/112654; it has been noted by GNATS.
From: Marius Strobl [EMAIL PROTECTED]
To: Nagy Keve [EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED]
Cc:
Subject: Re: kern/112654: [pcn] Kernel panic upon if_pcn module load on a
Netfinity 5000
Date:
I figured out the real source of the problem. Turns out Bell went and
screwed up the lantern test mappings on my connections, and dropped
the profile on one of them to 3 megabits (which I didn't know because
the lantern was mis-mapped). So I've spent the last several weeks
racking my brains trying
Old Synopsis: ng_netflow can consume large sums of memory if export hook isn't
connected
New Synopsis: [ng_netflow] ng_netflow can consume large sums of memory if
export hook isn't connected
Responsible-Changed-From-To: freebsd-bugs-freebsd-net
Responsible-Changed-By: linimon
On Sun, 20 Jan 2008, s3raphi wrote:
I am running web polygraph against a FreeBSD7.0-RC1 squid server and
experiencing problems. I have run the same test against the same hardware on
FreeBSD 6.1 without issue. This seems to be specific to FreeBSD 7.
The problem is related to the number of
At Thu, 17 Jan 2008 15:06:19 -0500,
randall wrote:
[EMAIL PROTECTED] wrote:
Howdy,
At my current gig we find that the network interface locks up if we
subject it to a high rate of multicast traffic. Since the whole
purpose of this box is to do multicast (it absorbs a feed of data
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Andre Oppermann wrote:
The first cut is now at //depot/projects/tcp_reass/ however I made
a mistake when creating the branch and now the code is in the same
changeset as the branching itself. Doesn't make it easy to do a
diff. Have to see how I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello, I was looking through the archive, and I came across the ath0
Ierrs thread - and I am facing a similar issue.
A little background...
The machine is a 1ghz Athlon, with 640MB of ram. There is a vr0 device,
a de0 device, and sis0 device and
10 matches
Mail list logo