This is actually very very interesting to me. Flashing the BIOS
*shouldn't* matter, but this is now the second (unrelated) incident
I've heard where it does in very odd ways.
No- on this- thank *you*. It's a path I would have not have thought to
take and try and now will.
On 10/10/06, [EMAIL
Garance A Drosihn napsal/wrote, On 10/12/06 04:09:
Your 4.x system is not doing to die when we EOL 4.x. We're only
This is an open-source project. If it really is as easy to support
4.x with security fixes as you think it is, then you (all of you
Yes, I'm ready to self-support the 4.x
One of my servers is colocated in a place on a different continent - which is
why I haven't been able to upgrade it beyond RELENG_4. Google turns up a
binary upgrade as the only way I can get to RELENG_6. Is this still the case
(because the logistics on arranging that are ... interesting) or is
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Questions regarding IPv6 may not belong here, but I take my chances
anyway.
Subsection 5.3 of RFC 2462 states that:
``A node forms a link-local address whenever an interface becomes
enabled [...]''
One of the events listed in
On Wed, Oct 11, 2006 at 03:43:07PM -0400, Ernest Natiello wrote:
E Hello,
E I have 4 HP Proliant DL360's (1u) which panic/reboot often (minimum
E 1x month), but in a seemingly inconsistent manner. As per other
E suggestions, ipf was replaced with pf, an Intel pro 100 was added, the
E BGE
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 12 Oct 2006 11:12+0200, Trond Endrestøl wrote:
Second, the link-layer address is not recreated when I do an
^^
Sorry, I meant the link-local address.
Can I set additional link-local addresses on the vlan interfaces
Hello, Stable!
Do anyone have running RELENG_6 branch on old Intel SMP boards? I have two
of them: SCB2 and SDS2. Both are on RELENG_4_11 today. Thinking on proposed
EoL of RELENG_4 branch I'v tryed to move one of them (SCB2) onto 6.1-RELEASE.
That was very problematic - ethernet
Kevin,
On Wed, Oct 11, 2006 at 11:21:27AM -0500, Kevin Kramer wrote:
K here is a picture of a panic i get on a Dell Precision 390 booting
K 6.2-beta2_amd64. hope this helps.
K
K http://users.centtech.com/~kramer/broadcom/bge_prec390.jpg
Well, although the message above is about bge(4)
On Wed, Oct 11, 2006 at 01:22:57PM -0400, Mikhail Teterin wrote:
GCC would not fix the bug described in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29390
because the compiler is of an unsupported version (they only support 4.x now).
Yet, the problem is rather real and hits when the
This is a known problem. It is fixed in HEAD, but unfortunately it
isn't mergeable to RELENG_6. The problem isn't related to either pf,
ipf or NIC drivers.
This is a little alarming - because what you seem to be saying is that
if you have DL360's then you need to either run current, or accept
On Thu, Oct 12, 2006 at 11:03:36AM +0100, Pete French wrote:
P This is a known problem. It is fixed in HEAD, but unfortunately it
P isn't mergeable to RELENG_6. The problem isn't related to either pf,
P ipf or NIC drivers.
P
P This is a little alarming - because what you seem to be saying is
Sergey N. Voronkov wrote:
Hello, Stable!
Do anyone have running RELENG_6 branch on old Intel SMP boards? I have two
of them: SCB2 and SDS2. Both are on RELENG_4_11 today. Thinking on proposed
EoL of RELENG_4 branch I'v tryed to move one of them (SCB2) onto 6.1-RELEASE.
That was very problematic
On 2006.10.12 10:59:18 +0300, Patrick Okui wrote:
One of my servers is colocated in a place on a different continent - which is
why I haven't been able to upgrade it beyond RELENG_4. Google turns up a
binary upgrade as the only way I can get to RELENG_6. Is this still the case
(because the
On Thu, 12 Oct 2006, Dan Lukes wrote:
But, maybe for my poor knowledge of english, you misunderstand the
point of my think.
Your English is quite good, actually. :)
The main problem is - 6.x is still not competitive replacement for
4.x. I'm NOT speaking about old unsupported hardware - I
Hi list,
On Wed, Oct 11, 2006 at 03:15:25PM -0700, Doug Barton wrote:
In order to facilitate this effort, I'd like to suggest that a new
mailing list be created, freebsd-releng4. That would allow the
interested folks to get together, pool resources, and decide what is
possible.
I am all
Doug Barton wrote:
The main problem is - 6.x is still not competitive replacement for
4.x. I'm NOT speaking about old unsupported hardware - I speaked about
performance in some situation and believe in it's stability.
I think saying that it's a worse replacement is a bit too broad.
Hi,
I started experimenting with carp, in order to replace
freevrrpd stuff we are currently using.
I'm running quite recent version of RELENG_6 (compiled
this week).
I was able to configure carp ok, but for some odd reason the
interface goes down by itself shortly after it has been configured.
On Thursday 12 October 2006 05:47, you wrote:
Do you have any tips? (Like running with ACPI disabled ond so on).
You could try setting kern.hz=100 in /boot/loader.conf. It lowers system
overhead, especially on SMP systems.
- Pieter
___
Ari Suutari wrote:
Hi,
I started experimenting with carp, in order to replace
freevrrpd stuff we are currently using.
I'm running quite recent version of RELENG_6 (compiled
this week).
I was able to configure carp ok, but for some odd reason the
interface goes down by itself shortly after it
Hi,
Tom Judge wrote:
I have seen similar problems when the carp multicast (224.0.0.18)
traffic was not allowed to be transmitted to the network due to a
firewall configuration problem.
Firewall wasn't enabled at this point, I wanted to keep things
as simple as possible during
I'll try that, but we received a response from David C. and few weeks
ago (on another thread) that the BCE driver should be picking up this
NIC. The latest 6.1 stable does not panic with the NIC disabled in the BIOS.
Gleb Smirnoff wrote:
Kevin,
On Wed, Oct 11, 2006 at 11:21:27AM -0500,
On Thu, Oct 12, 2006 at 01:21:16PM +0200, Pieter de Goeje wrote:
On Thursday 12 October 2006 05:47, you wrote:
Do you have any tips? (Like running with ACPI disabled ond so on).
You could try setting kern.hz=100 in /boot/loader.conf. It lowers system
overhead, especially on SMP systems.
Hi,
Reporting back after a few days with the patch. The connect and switching
between accesspoints work but there are still a few down/up events, about
once every two hours but that may have somthing to do with the dhcp cleint.
At the moment, the number of lease renewals match the number of
Kostik Belousov wrote:
On Wed, Oct 11, 2006 at 01:22:57PM -0400, Mikhail Teterin wrote:
GCC would not fix the bug described in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29390
because the compiler is of an unsupported version (they only support 4.x now).
Yet, the problem is rather
Yeah, the error is probably a PCI error coming from the chipset,
not a RAM error. Unfortunately, there are a lot of mystery reasons
why a PCI error might get triggered, and the message isn't enough
to say what exactly it is. However, one simple test you can to
is to disable the EISA device in
Quoting Dan Lukes [EMAIL PROTECTED] (from Thu, 12 Oct 2006 09:43:20 +0200):
[moved from security@ to [EMAIL PROTECTED]
The main problem is - 6.x is still not competitive replacement for
4.x. I'm NOT speaking about old unsupported hardware - I speaked about
performance in some situation
Just a lurker, and FreeBSD users since late 3.0...
Problem is performance and trust in stability. It's
money and hardware independent problem.
5.x has significant performance hit, so we can't count
it as competitive replacement for 4.x. 6.1 is second release
in 6.x tree.
Quoting Dan Lukes [EMAIL PROTECTED] (from Thu, 12 Oct 2006 12:40:48 +0200):
I'm using 6-STABLE (and 5-STABLE previously) on some unimportant
computers and I'm reposting observered problems (mostly with offer of
patch).
The trick is to make some noise and get the attention of a
On Oct 11, 2006, at 11:47 PM, Sergey N. Voronkov wrote:
Do you have any tips? (Like running with ACPI disabled ond so on).
my favorite trick on installing 6.x is to disable acpi timer, but I
only do that if the machine hangs after probing the devices.
otherwise it has booted up and
On Oct 11, 2006, at 6:36 PM, Paul Allen wrote:
I think the most likely path of success is, as you say, to make the
4.x
userland more like 6.x.
For anyone who really wishes to stick to freebsd 4.x for performance,
we should refer them to dragonflybsd, which seems to be taking this
Hello,
I am using FreeBSD-6.2-PRERELEASE and when I ping to outside IP address get
below result.
gk# ping y.y.y.y
PING y.y.y.y (y.y.y.y): 56 data bytes
64 bytes from y.y.y.y: icmp_seq=0 ttl=43 time=482.571 ms
64 bytes from y.y.y.y: icmp_seq=0 ttl=43 time=482.934 ms (DUP!)
64 bytes from y.y.y.y:
On Oct 11, 2006, at 6:42 PM, Dan Lukes wrote:
5.x has significant performance hit, so we can't count it as
competitive replacement for 4.x. 6.1 is second release in 6.x tree.
6.0 has stability problem. The 6.1 is sufficiently stable on
average use, but it still has problems in edge
--- Alexander Leidinger [EMAIL PROTECTED]
wrote:
Quoting Dan Lukes [EMAIL PROTECTED] (from Thu, 12
Oct 2006 09:43:20 +0200):
[moved from security@ to [EMAIL PROTECTED]
The main problem is - 6.x is still not
competitive replacement for
4.x. I'm NOT speaking about old unsupported
Hi,
The DUP means that ping received two replies to one enquiry - the
icmp_sequence number is duplicated.
In my case it was mistake in wifi configuration...
Jaromir Dvoracek
On 12. Oct (Thursday) 2006 at 22:05:30, Balgansuren Batsukh wrote:
Hello,
I am using FreeBSD-6.2-PRERELEASE and
In response to Balgansuren Batsukh [EMAIL PROTECTED]:
Hello,
I am using FreeBSD-6.2-PRERELEASE and when I ping to outside IP address get
below result.
gk# ping y.y.y.y
PING y.y.y.y (y.y.y.y): 56 data bytes
64 bytes from y.y.y.y: icmp_seq=0 ttl=43 time=482.571 ms
64 bytes from y.y.y.y:
On Tue, Oct 10, 2006 at 02:53:15PM -0400, Bill Moran wrote:
In response to Doug Ambrisko [EMAIL PROTECTED]:
John Baldwin writes:
| On Tuesday 10 October 2006 08:54, Bill Moran wrote:
| In response to Doug Ambrisko [EMAIL PROTECTED]:
| Bruno Ducrot writes:
| | On Wed, Oct 04, 2006
Hi all,
I rent a small server based on a VIA C7 on which I installed a
6.2-PRERELEASE as of today (see dmesg and kernconf attached). It runs
fairly well but I wonder if it couldn't be faster.
According to padlock(4) man page, crypto hardware support is available
by adding padlock, crypto and
In response to Bruno Ducrot [EMAIL PROTECTED]:
On Tue, Oct 10, 2006 at 02:53:15PM -0400, Bill Moran wrote:
In response to Doug Ambrisko [EMAIL PROTECTED]:
John Baldwin writes:
| On Tuesday 10 October 2006 08:54, Bill Moran wrote:
| In response to Doug Ambrisko [EMAIL PROTECTED]:
There is no line for EISA in the GENERIC config file, nor can I find it
in device.hints.
The markings on the chip say it is a BCM5754, but it's being recognized
as BCM5787. I currently have the machine at the db prompt if someone
can walk me through getting valuable information.
Hello,
Thank you very much for all of the help. I am trying to understand
this issue, as it has been plaguing me for quite some time.
So, extrapolating from the below kgdb output, am I to assume that
the process causing the error is tcpserver? And should I further infer
that tcpserver
Matthieu Michaud wrote:
I rent a small server based on a VIA C7 on which I installed a
6.2-PRERELEASE as of today (see dmesg and kernconf attached). It runs
fairly well but I wonder if it couldn't be faster.
According to padlock(4) man page, crypto hardware support is available
by
On Thu, Oct 12, 2006 at 11:18:03AM -0400, Ernest Natiello wrote:
E Hello,
E Thank you very much for all of the help. I am trying to understand
E this issue, as it has been plaguing me for quite some time.
E So, extrapolating from the below kgdb output, am I to assume that
E the process
Le 12 oct. 06 à 17:00, Bill Moran a écrit :
In response to Bruno Ducrot [EMAIL PROTECTED]:
The device_printf() function take too much time I think, so you
get the same
behaviour as the DELAY().
True. Problem is that I considered that possibility, and removed the
device_printf(), rebuild
On Thu 12 Oct 07:19, Danial Thom wrote:
[...]
Maybe its just time for the entire FreeBSD team
to come out of its world of delusion and come to
terms with what every real-life user of FreeBSD
knows: In how ever many years of development,
there is still no good reason to use anything
other
here we go:
(kgdb) frame 7
#7 0xc072191d in ip_ctloutput (so=0x1, sopt=0xe9226c90)
at /usr/src/sys/netinet/ip_output.c:1184
1184INP_LOCK(inp);
(kgdb) p *sopt
$1 = {sopt_dir = SOPT_SET, sopt_level = 0, sopt_name = 1, sopt_val =
0x0,
sopt_valsize = 0, sopt_td =
In response to Olivier Mueller [EMAIL PROTECTED]:
I would be happy to test help, I also have a PE1950 around waiting for
this problem to be solved to go in production. I would just need to
have
the patch. (I'll check the list archive later, I just joined
freebsd-stable today)
There
Le 12 oct. 06 à 18:03, Bill Moran a écrit :
There isn't really a patch per-se. Just a bunch of recommendations
on where to put extra debugging information. You'll find it in the
archives.
ok thanks, I'll check.
Btw, it would be nice if the patched if_bce.c could also be
integrated
into
At 11:37 AM 10/12/2006, Oliver Fromme wrote:
Matthieu Michaud wrote:
I rent a small server based on a VIA C7 on which I installed a
6.2-PRERELEASE as of today (see dmesg and kernconf attached). It runs
fairly well but I wonder if it couldn't be faster.
According to padlock(4) man page,
On Wed, Oct 11, 2006 at 01:13:27PM +0200, Oliver Fromme wrote:
Heinrich Rebehn wrote:
[i386 vs. amd64]
Overhead ?? Would this mean that the 64 bit version will run slower?
It depends. Most applications will run somewhat faster,
but there are cases where you might get a small
Danial Thom wrote:
The right thing to do is to port the SATA support
and new NIC support back to 4.x and support both.
4.x is far superior on a Uniprocessor system and
FreeBSD-5+ may be an entire re-write away from
ever being any good at MP. Come to terms with it,
PLEASE, because it is the case
On 10/12/06, Dan Lukes [EMAIL PROTECTED] wrote:
Danial Thom wrote:
The right thing to do is to port the SATA support
and new NIC support back to 4.x and support both.
4.x is far superior on a Uniprocessor system and
FreeBSD-5+ may be an entire re-write away from
ever being any good at MP.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29390
четвер 12 жовтень 2006 05:54, Kostik Belousov написав:
Thread model: posix
gcc version 3.4.6 [FreeBSD] 20060305
opt/gcc-3.4.6 is the stock version of the 3.4.6 built directly from the FSF
sources (relatively long time ago).
Well, if
On Thu, 12 Oct 2006 07:19:30 -0700 (PDT)
Danial Thom [EMAIL PROTECTED] wrote:
Maybe its just time for the entire FreeBSD team
to come out of its world of delusion and come to
terms with what every real-life user of FreeBSD
knows: In how ever many years of development,
there is still no good
On Thu, Oct 12, 2006 at 05:20:03PM +0100, Mike Bristow wrote:
On Wed, Oct 11, 2006 at 01:13:27PM +0200, Oliver Fromme wrote:
Heinrich Rebehn wrote:
[i386 vs. amd64]
Overhead ?? Would this mean that the 64 bit version will run slower?
It depends. Most applications will run
Doug Barton [EMAIL PROTECTED] wrote:
I have just one remaining question, does what you said
apply to the new Intel Core 2 Duo chips as well?
It should apply to every machine that's supported by
FreeBSD/amd64, i.e. any processor that supports AMD64
or EM64T (as intel calls it).
Best regards
Scott Long wrote:
Bill Moran wrote:
I've copied many of the people who I've been working with directly on
this issue.
Can anyone provide a status update on these problems? Discussion seems
to have stopped since Oct 5.
Any new patches to test?
I'm actively working on fixing the driver
Tom Judge wrote:
Scott Long wrote:
Bill Moran wrote:
I've copied many of the people who I've been working with directly on
this issue.
Can anyone provide a status update on these problems? Discussion seems
to have stopped since Oct 5.
Any new patches to test?
I'm actively working on
Ari Suutari [EMAIL PROTECTED] writes:
carp0: flags=49UP,LOOPBACK,RUNNING mtu 1500
inet 192.168.5.59 netmask 0xff00
carp: BACKUP vhid 55 advbase 1 advskew 0
+ sleep 5
+ ifconfig carp0
carp0: flags=8LOOPBACK mtu 1500
carp: INIT vhid 55 advbase 1 advskew 0
See,
On Thursday 12 October 2006 09:53 am, Oliver Fromme wrote:
Doug Barton [EMAIL PROTECTED] wrote:
I have just one remaining question, does what you said
apply to the new Intel Core 2 Duo chips as well?
It should apply to every machine that's supported by
FreeBSD/amd64, i.e. any processor
ML Date: Wed, 11 Oct 2006 06:41:10 -0500
ML From: Mark Linimon
ML We are currently trying to support 4 major CVS branches.
Ughh.
Perhaps work on 7 should have been delayed until 5 and 6 were able to
woo people away from 4 -- or at least not leave valid reasons for people
wanting to stay
KK Date: Wed, 11 Oct 2006 18:46:54 -0400
KK From: Kris Kennaway
KK The 4.x support policy was announced some time ago and may be found
KK here:
policy != justification
Eddy
--
Everquick Internet - http://www.everquick.net/
A division of Brotsman Dreger, Inc. - http://www.brotsman.com/
Please do not feed the trolls.
-Kip
On Thu, 12 Oct 2006, Danial Thom wrote:
--- Alexander Leidinger [EMAIL PROTECTED]
wrote:
Quoting Dan Lukes [EMAIL PROTECTED] (from Thu, 12
Oct 2006 09:43:20 +0200):
[moved from security@ to [EMAIL PROTECTED]
The
Hi,
ML We are currently trying to support 4 major CVS branches.
EBD Perhaps work on 7 should have been delayed until 5 and 6 were able to
EBD woo people away from 4 -- or at least not leave valid reasons for
RBD people
Eeehm, afaik 5 is an interim for 6, so 5 should be stopped. I know plenty
On Thu, Oct 12, 2006 at 12:36:42PM -0400, Mikhail Teterin wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29390
четвер 12 жовтень 2006 05:54, Kostik Belousov написав:
Thread model: posix
gcc version 3.4.6 [FreeBSD] 20060305
opt/gcc-3.4.6 is the stock version of the 3.4.6 built
Doesn't the increased number of registers available when running amd64
really, really help when compared with the traditionally register-starved
i386?
Yes, it seems to - evereything soemone else said about context switch
verhead and compiles is true of course, but the FreeBSD compiler seems
On Thu, Oct 12, 2006 at 09:59:10AM -0400, Vivek Khera wrote:
On Oct 11, 2006, at 6:36 PM, Paul Allen wrote:
I think the most likely path of success is, as you say, to make the
4.x
userland more like 6.x.
For anyone who really wishes to stick to freebsd 4.x for performance,
we
On Thu, Oct 12, 2006 at 05:43:01PM +, Edward B. DREGER wrote:
KK Date: Wed, 11 Oct 2006 18:46:54 -0400
KK From: Kris Kennaway
KK The 4.x support policy was announced some time ago and may be found
KK here:
policy != justification
Yes, and the justification has also been discussed
In response to Olivier Mueller [EMAIL PROTECTED]:
Btw, it would be nice if the patched if_bce.c could also be integrated
into the cvs (http://yogurt.org/FreeBSD/if_bce.c). At the moment (beg.
of the week) I still had to patch the source tree by hand to keep the
network
interface working
On Thu, 2006-10-12 at 15:16 -0400, Bill Moran wrote:
In response to Olivier Mueller [EMAIL PROTECTED]:
Btw, it would be nice if the patched if_bce.c could also be integrated
into the cvs (http://yogurt.org/FreeBSD/if_bce.c). At the moment (beg.
of the week) I still had to patch the
On Oct 12, 2006, at 1:20 PM, Marko Lerota wrote:
I think the interface didn't get sync from other carp interface,
so it doesn't know that he is the MASTER or BACKUP, and because
of that goes into the INIT state.
Shouldn't it then move to MASTER since the other server could
possibly be
Doug Barton napsal/wrote, On 10/12/06 21:06:
The odds are pretty close to 100% that things will run better with 6.x
than with 5.x. Many fixes that have been MFC'ed to 6.x have not and will
not be ported to 5.x.
It's better to explicitly ask for MFC to selected branches when
submitting PR.
--- Dan Lukes [EMAIL PROTECTED] wrote:
Danial Thom wrote:
The right thing to do is to port the SATA
support
and new NIC support back to 4.x and support
both.
4.x is far superior on a Uniprocessor system
and
FreeBSD-5+ may be an entire re-write away
from
ever being any good at MP.
Hi all
I've very strange problem with my NFS server.
This server running 6-Stable Last update (after crash :-( ) 23 september.
I've very strange problem, after some days I got this kind of message on
syslog
nfs kernel: Connection attempt to TCP MY_NFS_IP_ADDR:111 from
Hello!
We (pfSense developers) have noticed an interesting problem where
userland stops functioning under high packet forwarding workloads.
Userland applications such as sshd and lighttpd freeze but userland
resumes after the network load eases.
We tested with both PF enabled and disabled and
-Original Message-
From: [EMAIL PROTECTED] [mailto:owner-freebsd-
[EMAIL PROTECTED] On Behalf Of Olivier Mueller
Sent: Thursday, October 12, 2006 3:30 PM
To: [EMAIL PROTECTED]
Subject: Re: Dell 1950 does not properly respond to reboot and
shutdown -p
On Thu, 2006-10-12 at 15:16
At 05:00 PM 10/12/2006, Albert Shih wrote:
The server have all NIC in polling mode because without this flag the NIC
disapear (em0 watchdog etc...)
Today the only solution I've found is ... reboot the server :-(
I would try and disable polling and then try the patch in
On Oct 12, 2006, at 2:11 PM, Scott Ullrich wrote:
We (pfSense developers) have noticed an interesting problem where
userland stops functioning under high packet forwarding workloads.
Userland applications such as sshd and lighttpd freeze but userland
resumes after the network load eases.
[
Vivek Khera [EMAIL PROTECTED] writes:
On Oct 12, 2006, at 1:20 PM, Marko Lerota wrote:
I think the interface didn't get sync from other carp interface,
so it doesn't know that he is the MASTER or BACKUP, and because
of that goes into the INIT state.
Shouldn't it then move to MASTER since
Hi there.
We have a very interesting Embebed FreeBSD base system using
Netgraph, BGP, Voip over IP (SER and Asterisk), PF, Remote Desktop Client
(netboot), VLANs, Q-in-Q Vlan, VPN, L2tp, pptp, Xmail, Dhcp server, Wireless
etc.. All the setting and config files are created by a central
Marko Lerota [EMAIL PROTECTED] writes:
Shouldn't it then move to MASTER since the other server could
possibly be dead?
Yes, but if interface had _never_ received any pfsync packet,
and sysctl is set to net.inet.carp.preempt=0 ?
Maybe it's because of that. Don't know really. Documentation
I am running a RELENG_6 from yesterday on amd64 and the VIA PATA
controller is being detected as GENERIC ATA, from dmesg:
atapci0: GENERIC ATA controller port
0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfc00-0xfc0f at device 15.0 on pci0
uname -a:
FreeBSD 6.2-PRERELEASE FreeBSD 6.2-PRERELEASE #0: Wed
On Thu, 12 Oct 2006 15:02:45 +0200
O. Hartmann [EMAIL PROTECTED] wrote:
Well, I hope this bug has been sent by heaven and speeds up swapping
system compiler of FreeBSD 6.X to 4.1 or 4.X :-)
___
freebsd-stable@freebsd.org mailing list
On 10/12/06, Chuck Swiger [EMAIL PROTECTED] wrote:
On Oct 12, 2006, at 2:11 PM, Scott Ullrich wrote:
We (pfSense developers) have noticed an interesting problem where
userland stops functioning under high packet forwarding workloads.
Userland applications such as sshd and lighttpd freeze but
On Thu, 12 Oct 2006, KAYVEN RIESE wrote:
i'm sorry if i was cranky. i'm going to be more RTFM-y now.
On Wed, 11 Oct 2006, KAYVEN RIESE wrote:
i finally started rtfm-ing and i am feeling concerned..
first of all..
/usr/local/mico/BUGS looks alarming
be solved in later releases. Please
On Thu, 12 Oct 2006, KAYVEN RIESE wrote:
is this a bad thing?
cat Makefile
# Makefile for a little mico client that reads random numbers from a
# Corba-server. See client.cc for details.
all: .depend client
include /usr/local/mico/MakeVars
INSTALL_DIR = random
INSTALL_SRCS=
On Thu, 12 Oct 2006, KAYVEN RIESE wrote:
is this a bad thing?
cat Makefile
# Makefile for a little mico client that reads random numbers from a
# Corba-server. See client.cc for details.
all: .depend client
include /usr/local/mico/MakeVars
INSTALL_DIR = random
INSTALL_SRCS=
On Thu, 12 Oct 2006, KAYVEN RIESE wrote:
i was sitting here saving about 20/150 freeBSD-devel emails
i got in the past day and a half and i am copying the
dingy about bench when suddenly bench decided to spit something
else out at me..i thought it had finished. i guess i better
do a ps and
On Thu, 12 Oct 2006, KAYVEN RIESE wrote:
h.. i needed to configure right, huh?
i don't think i did anything {:} heh
is it README in /usr/local/mico ?
oh wait..
u know what i did was
pkg_add -r mico
that's all. freeBSD is real kewl that way. maybe i should
build all my demos in
a little info for the past slew of mee doing mico on freeBSD
gcc --version
gcc (GCC) 3.4.4 [FreeBSD] 20050518
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A
Password:
bsd# cd /usr/local/mico/demo/generic
bsd# gmake
echo '# Module dependencies' .depend
/usr/local/mico/./admin/mkdepend -I. -I../../include -O2 -Wall
-D_REENTRANT -D_
THREAD_SAFE -O *.c *.cc .depend
c++ -I. -I../../include -O2 -Wall -D_REENTRANT -D_THREAD_SAFE -O -c
client
#bsd is the root prompt
bsd# run_test
run_test: Command not found.
bsd# ./run_test
/libexec/ld-elf.so.1: Shared object libmicoir2.3.12.so not found,
required by ird
/libexec/ld-elf.so.1: Shared object libmicoir2.3.12.so not found,
required by idl
/libexec/ld-elf.so.1: Shared object
On Fri, Oct 13, 2006 at 11:31:53AM +1300, Marcos Biscaysaqu wrote:
Hi there.
We have a very interesting Embebed FreeBSD base system using
Netgraph, BGP, Voip over IP (SER and Asterisk), PF, Remote Desktop Client
(netboot), VLANs, Q-in-Q Vlan, VPN, L2tp, pptp, Xmail, Dhcp server,
On Thu, 12 Oct 2006, KAYVEN RIESE wrote:
i'm running freeBSD. umm..
On Thu, 12 Oct 2006, Kris Kennaway wrote:
What relevance does this have to FreeBSD-stable?
kris
/libexec/ld-elf.so.1: Shared object libmico2.3.12.so not found, required by
server
bsd# ./client
/libexec/ld-elf.so.1:
On Thu, Oct 12, 2006 at 09:59:10AM -0400, Vivek Khera wrote:
For anyone who really wishes to stick to FreeBSD 4.x for performance,
we should refer them to dragonflybsd, which seems to be taking this
approach. It was forked from FreeBSD 4.8 and seems to pretty modern
in userland.
Hi,
On Fri, 13 Oct 2006, Bernd Walter wrote:
We have a very interesting Embebed FreeBSD base system using
Netgraph, BGP, Voip over IP (SER and Asterisk), PF, Remote Desktop Client
(netboot), VLANs, Q-in-Q Vlan, VPN, L2tp, pptp, Xmail, Dhcp server, Wireless
etc.. All the
On 10/12/06, Chuck Swiger [EMAIL PROTECTED] wrote:
On Oct 12, 2006, at 2:11 PM, Scott Ullrich wrote:
We (pfSense developers) have noticed an interesting problem where
userland stops functioning under high packet forwarding workloads.
Userland applications such as sshd and lighttpd freeze but
On 10/13/06, Mark Linimon [EMAIL PROTECTED] wrote:
DragonFly has made substantial rewrites/changes since the fork from
FreeBSD.
I think to assume that there are no regressions in either stability,
speed,
or support may be naive.
Has anyone tried benchmarking DragonflyBSD against FreeBSD 5.x
Hi,
Vivek Khera wrote:
On Oct 12, 2006, at 1:20 PM, Marko Lerota wrote:
I think the interface didn't get sync from other carp interface,
so it doesn't know that he is the MASTER or BACKUP, and because
of that goes into the INIT state.
Shouldn't it then move to MASTER since the other server
Hi,
Marko Lerota wrote:
I meant:
Maybe first they have to talk to each other and say:
OK, I will be the master first, and you wait. And if I don't send
you any more sync packets, then you should be in charge :)
I have been using freevrrpd for quite a long time now and
I
On Thu, Oct 12, 2006 at 11:59:00PM +0100, Dominic Bishop wrote:
I am running a RELENG_6 from yesterday on amd64 and the VIA PATA
controller is being detected as GENERIC ATA, from dmesg:
atapci0: GENERIC ATA controller port
0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfc00-0xfc0f at device 15.0 on
100 matches
Mail list logo
