You have received the alternative text version of an HTML message. Please click
below to access the web version of the message:
View an HTML version of this message:
http://ganderdirectagency.bm23.com/public/?q=preview_message&fn=Link&t=1&ssid=14987&id=5u0yc3x10ebszn4giim106df6d8gh&id2=j4ql1cc
On 28 May 2010, at 11:23, Lassi Tuura wrote:
> Hi,
>
> I have a system on which I've installed FreeBSD 8.0-RELEASE, then later
> 8.0-STABLE 201004 (amd64).
>
> Under heavy disk load the system freezes totally: screen goes blank and it
> loses all connection outside world - network, keyboard, etc
Hi,
I have a system on which I've installed FreeBSD 8.0-RELEASE, then later
8.0-STABLE 201004 (amd64).
Under heavy disk load the system freezes totally: screen goes blank and it
loses all connection outside world - network, keyboard, etc. won't work.
Sometimes the screen gets filled with stripes
On Wed, May 19, 2010 at 00:26, Jack Vogel wrote:
> Hmmm, this is odd, I'm sure that was tested by my validation engineer.
> Tell me what the hardware looks like, ie what the 1G link partner is
> and I'll have him check into it... it SHOULD work.
It's plugged in to an Extreme Networks gigabit swit
On 5/28/10 3:54 AM, Giulio Ferro wrote:
On 28.05.2010 07:46, Giulio Ferro wrote:
Would it be a good idea to try netgraph bridge?
Or the underlying implementation is the same as in if_bridge?
netgraph bridging (see /usr/share/examples/netgraph) is a completely
different implimentation with diff
On 5/27/10 10:07 PM, Vladislav V. Prodan wrote:
9.0-CURRENT #0: Sun Apr 11 23:26:21 EEST 2010 amd64
net.my_fibnum: 0
net.add_addr_allfibs: 1
net.fibs: 3
# netstat -rn | grep default
default XXX.XXX.XXX.254 UGS 0 37594940 tun1
default 2001:5c0:1400:b::27e8 UGS gif0
# setfib 1 netstat -rn | grep
So it seems the problem is buggy hardware that incorrectly reports
that is has a copper PHY instead of an internal serdes. For whatever
reason this didn't matter to the old driver, but the new driver is
tripping over the problem. *sigh*
___
freebsd-net@
Hi all,
I have four heavy load mysql database servers which system is 8.0-release
got "panic: rtqkill route really not free" this week. We have a gateway
set up by OpenBSD have a icmp route redirect function between two subnets,
I suspect the FreeBSD panic at trying to delete routes sent from th
Hmm, I wonder if possible culprit is this:
Process 12 (intr) thread 0xff00022693e0 (100016)
exclusive sleep mutex Giant (Giant) r = 1 (0x80c93dc0)
locked @ /usr/src/sys/dev/usb/usb_transfer.c:3023
Is the usb device used as main harddrive for the system, and have you
tried other u
On Friday 28 May 2010 07:46:07 Giulio Ferro wrote:
> Months ago I reported a system freezing whenever bridge was used
> with pf. This still happens now in 8.1 prerelease: after several minutes
> to hours
> that the bridge is active the system becomes unresponsive.
as I told you last time your repo
On 28.05.2010 07:46, Giulio Ferro wrote:
Would it be a good idea to try netgraph bridge?
Or the underlying implementation is the same as in if_bridge?
Months ago I reported a system freezing whenever bridge was used
with pf. This still happens now in 8.1 prerelease: after several
minutes to h
Hi,
I am testing the implementation of link aggregation on FreeBSD 8.1
PRE-RELEASE and I see to be getting a problem with the bce interface.
I am using an HP DL 380 G6 with 4 Ethernet interfaces.
If I configure the cards individually, I can reach other devices on the
network. When I enable link
On 28.05.2010 07:46, Giulio Ferro wrote:
I've also tried to disable all filtering:
net.link.bridge.pfil_onlyip=0
net.link.bridge.pfil_member=0
net.link.bridge.pfil_bridge=0
net.link.bridge.pfil_local_phys=0
net.link.bridge.ipfw=0
net.link.bridge.ipfw_arp=0
But to no avail. It always freezes...
The following reply was made to PR kern/146845; it has been noted by GNATS.
From: Mikolaj Golub
To: "Lavrentiev\, Anton \(NIH\/NLM\/NCBI\) \[C\]"
Cc: "Robert N. M. Watson" , freebsd-net@FreeBSD.org,
bug-follo...@freebsd.org
Subject: Re: kern/146845: [libc] close(2) returns error 54 (connection
On Fri, 28 May 2010 04:40:03 GMT Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote:
LA> IMHO, it is not, unfortunately, a solution: it seems to clear ECONNRESET
LA> blindly and w/o distinguishing the situation when the remote end closes
the
LA> connection prematurely (i.e. before acknowledging a
15 matches
Mail list logo
