personally I use the netgraph bridging code and I think (though I'm biased)
that you should look at using htat rather than the hardwired bridging
code that it was derived from.
Now that I've read up on it I can tell you you and and Archie have every
right to be biased =)
I've had a netgraph
Hi!
Attached is the patch for RELENG_4. It works but I don't like
how it pollutes the Makefile.inc1. Anyone with a better idea?
On Tue, Dec 12, 2000 at 09:43:55AM -0800, Marcel Moolenaar wrote:
Ruslan Ermilov wrote:
Let me rephrase the question: Did you modify the manpages to get it
On Wed, 24 Jan 2001, Matt Dillon wrote:
:On Sun, 21 Jan 2001, Matt Dillon wrote:
:
: Concentrate on making the general network stack (aka TCP) and
: filesystems SMP aware. Leave NFS alone for now. Please.
:
:If I understand correctly another item on the wishlist is TI-RPC
:(so
On Wed, 24 Jan 2001, Julian Elischer wrote:
...
my dc cards. No problems so far - as long as I don't use DUMMYNET with it.
I really wish I could use DUMMYNET as I need to put bandwidth limits on a
few of the computers on my network.
...
Rate limitting is one thing that isn't there
On Thu, Jan 25, 2001 at 02:40:22PM +0100, Ronald van der Pol wrote:
On Wed, 24 Jan 2001, Matt Dillon wrote:
(I have cc-ed [EMAIL PROTECTED])
This came up about half a year ago in the KAME snap mailing list.
I think the conclusion was: a migration from "old" RPC to TI-RPC
is a
On Wed, 24 Jan 2001, Maxim Sobolev wrote:
It's not a very accurate estimate, as the magic can be in the distfile
itself, i.e. properly written configure script or makefile may know
that FreeBSD need a -pthread and -D_THREAD_SAFE.
For some unknown reason, math.h needs _REENTRANT in
Hi all,
I have been working with Nicholas Souchu to fix a few issues with the
parallel port zip, especially the zip+ (250 meg version).
I know this is deprecated hardware, but I would like to know if it helps.
The driver should now work correctly in PS2 transfer mode, which in theory
should be
I don't think this is within the KAME-project scope. On NetBSD, the
NetBSD crowd has done this almost a year ago (I believe) and NFS over
IPv6 works just great on NetBSD. I'd guess FreeBSD could borrow a lot
from the NetBSD work, reducing the major-ness of the task?
The above is
On Thu, 25 Jan 2001 [EMAIL PROTECTED] wrote:
I don't think this is within the KAME-project scope. On NetBSD, the
NetBSD crowd has done this almost a year ago (I believe) and NFS over
IPv6 works just great on NetBSD. I'd guess FreeBSD could borrow a lot
from the NetBSD work, reducing the
In your previous mail you wrote:
It is not impossible to support IPv6 NFS without switching to TI-RPC,
INRIA IPv6 has the code (IIRC).
= this code was ported to FreeBSD 4.2. I'll give more details as soon as
I am back to my office (ie. next week).
However, if you
The above is correct. NetBSD NFS-over-IPv6 (actually RPC over IPv6)
is TI-RPC based, and it was done by NetBSD guys not KAME guys.
Sorry, I was not clear. The question about moving towards TI-RPC was
directed to freebsd-current. Just out of interest. No critisism intended.
Since I currently have high workload, I dont have time to port it to 4.x or
5-CURRENT...
Conclusion: volunteer required for this work... and I can consult him/her.
Shouldn't be too hard. I'll gladly volunteer for this project.
Quick question for the netgraph guru's. I haven't looked
I came across an embarrassing comparison last night-
FreeBSD NFS clients (well, i386) stop writing files at 4GB.
Solaris, with O_LARGEFILE options in the open arguments, does not.
Does anyone here know what FreeBSD ought to be doing about this?
Or have I missed something? There is no
In the last episode (Jan 25), Matthew Jacob said:
I came across an embarrassing comparison last night-
FreeBSD NFS clients (well, i386) stop writing files at 4GB.
Solaris, with O_LARGEFILE options in the open arguments, does not.
Does anyone here know what FreeBSD ought to be doing
On Thu, 25 Jan 2001, Dan Nelson wrote:
In the last episode (Jan 25), Matthew Jacob said:
I came across an embarrassing comparison last night-
FreeBSD NFS clients (well, i386) stop writing files at 4GB.
Solaris, with O_LARGEFILE options in the open arguments, does not.
Does
In the last episode (Jan 25), Matthew Jacob said:
On Thu, 25 Jan 2001, Dan Nelson wrote:
Make sure you're using NFSv3 mounts (should be the default, but if not,
add "nfsv3" to the options column in fstab). I cross-mount FreeBSD,
Tru64, and Solaris boxes via NFS and can access large files
To be fair, I should say that the server is a 'specical' box.
But an lmdd writing to a file in 250GB partition that I started from Solaris
last night is still going. The NetBSD FreeBSD writes both stopped at 4GB. I
suppose it still could be the server, but, well, it's hard to sell against
On Thu, 25 Jan 2001, Dan Nelson wrote:
In the last episode (Jan 25), Matthew Jacob said:
On Thu, 25 Jan 2001, Dan Nelson wrote:
Make sure you're using NFSv3 mounts (should be the default, but if not,
add "nfsv3" to the options column in fstab). I cross-mount FreeBSD,
Tru64, and
* Matthew Jacob [EMAIL PROTECTED] [010125 09:18] wrote:
On Thu, 25 Jan 2001, Dan Nelson wrote:
In the last episode (Jan 25), Matthew Jacob said:
On Thu, 25 Jan 2001, Dan Nelson wrote:
Make sure you're using NFSv3 mounts (should be the default, but if not,
add "nfsv3" to the
Rogier R. Mulhuijzen writes:
But from my list of wishes I'd say the first 3 are gone. All that's left is
spanning tree. I'm probably going to need this pretty soon, so once more
I'm asking if anyone is working on it. If not I'll start on it.
Do you have references for how to do this? As I
Rogier R. Mulhuijzen writes:
Quick question for the netgraph guru's. I haven't looked yet, but is there
an explanation of the NG_ macros I see used in the netgraph nodes' code?
Yes, but it's not documented :) Actually the daemonnews article does
document these somewhat.
The main ones are
But I won't let it go! I was hoping to replace my Solaris box with either
FreeBSD or NetBSD as my main home directory server. FreeBSD 4.2 panics part
way through the first LADDIS runs I was using to test it with and I can't get
NetBSD to start as a LADDIS client (I hadn't got the auth
"Rogier R. Mulhuijzen" wrote:
FYI:
Full source CVSupped on the 18th or 19th
Panic came about when I did a 'ls' in ngctl(8).
Kernel config attached, gdb of core follows below:
This GDB was configured as "i386-unknown-freebsd"...
IdlePTD 5300224
initial pcb at 31c4e0
panicstr:
Hi,
But from my list of wishes I'd say the first 3 are gone. All that's left
is
spanning tree. I'm probably going to need this pretty soon, so once more
I'm asking if anyone is working on it. If not I'll start on it.
Do you have references for how to do this? As I understand it, there
Matthew Jacob writes:
I came across an embarrassing comparison last night-
FreeBSD NFS clients (well, i386) stop writing files at 4GB.
Solaris, with O_LARGEFILE options in the open arguments, does not.
Does anyone here know what FreeBSD ought to be doing about this?
Or have
On Thu, 25 Jan 2001, Andrew Gallatin wrote:
Matthew Jacob writes:
I came across an embarrassing comparison last night-
FreeBSD NFS clients (well, i386) stop writing files at 4GB.
Solaris, with O_LARGEFILE options in the open arguments, does not.
Does anyone here
"Rogier R. Mulhuijzen" wrote:
personally I use the netgraph bridging code and I think (though I'm biased)
that you should look at using htat rather than the hardwired bridging
code that it was derived from.
Now that I've read up on it I can tell you you and and Archie have every
right to
Matthew Jacob writes:
Same code compiled on Solaris is happy.
Perhaps there's some braindamage in it. I'm afraid of something like:
#ifdef Solaris
typedef filefoo u_int64_t;
#else
typedef filefoo u_int32_t;
#endif
;)
Drew
To Unsubscribe: send mail to [EMAIL PROTECTED]
with
Matthew Jacob writes:
Same code compiled on Solaris is happy.
Perhaps there's some braindamage in it. I'm afraid of something like:
#ifdef Solaris
typedef filefoo u_int64_t;
#else
typedef filefoo u_int32_t;
#endif
I'll try with dd then,... let y'all know...
To
Hi,
Alfred Perlstein and I have ported TI-RPC to FreeBSD Current. You can find
the latest snapshot here:
http://www.attic.ch/rpc.diff_01114001.tgz
Patches and bugfixes are welcome.
Martin
Martin Blapp, [EMAIL PROTECTED]
Improware AG, UNIX
[I don't know why -current is CC'd this is clearly about -stable]
Ruslan Ermilov wrote:
Attached is the patch for RELENG_4. It works but I don't like
how it pollutes the Makefile.inc1. Anyone with a better idea?
Allow me to sidetrack for a moment:
I just ugraded a machine from 4.1 to
Archie Cobbs wrote:
Rogier R. Mulhuijzen writes:
Also, a quick question for you netgraph guys. Why is it that ng_one2many
send a packet only out of one hook? I can see use for an algorithm that
sends packets from the 'one' hook to all the 'many' hooks (that are up) and
keep the
* Martin Blapp [EMAIL PROTECTED] [010125 11:07] wrote:
Hi,
Alfred Perlstein and I have ported TI-RPC to FreeBSD Current. You can find
the latest snapshot here:
http://www.attic.ch/rpc.diff_01114001.tgz
Patches and bugfixes are welcome.
Can you post a summary of how you've done it
Ok so I have tried the settings in
teh loader conf..
I have:
#autoboot_delay="10"# Delay in seconds before autobooting
#console="vidconsole" # Set the current console
currdev="disk1s1a" # Set the current device
module_path="/boot/kernel;/boot/modules"
this would be a REALLY easy node to write...maybe your first?
(see how 'ng_tee' works and ng_one2many, and
write one that does something in between.
I was thinking adding an algorithm to one2many.
DocWilco
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe
At 09:37 25-1-01 -0800, Archie Cobbs wrote:
Rogier R. Mulhuijzen writes:
But from my list of wishes I'd say the first 3 are gone. All that's
left is
spanning tree. I'm probably going to need this pretty soon, so once more
I'm asking if anyone is working on it. If not I'll start on it.
Do
Ok so I have tried the settings in
teh loader conf..
I have:
#autoboot_delay="10"# Delay in seconds before autobooting
#console="vidconsole" # Set the current console
currdev="disk1s1a" # Set the current device
module_path="/boot/kernel;/boot/modules"
knowing NFS in general far better than *BSD in specific, I would guess the best
thing to do (if you suspect server/client communication anomaly) is to grab a
snoop/tcpdump of the failure. I'm trying to think of a clever way to cause the
failure immediately, so you're not tracing 4GB of writes...
* Nathan Parrish [EMAIL PROTECTED] [010125 13:19] wrote:
knowing NFS in general far better than *BSD in specific, I would guess the best
thing to do (if you suspect server/client communication anomaly) is to grab a
snoop/tcpdump of the failure. I'm trying to think of a clever way to cause the
Rogier R. Mulhuijzen writes:
Hmm.. you could also get that affect using log2(n) ng_tee(4) nodes..
I don't see how though. Lets say I link only to left, right and left2right.
Now when data enters left it will go to both right and left2right. When
data enters right it goes to left. But when
"Rogier R. Mulhuijzen" wrote:
At 09:37 25-1-01 -0800, Archie Cobbs wrote:
Rogier R. Mulhuijzen writes:
But from my list of wishes I'd say the first 3 are gone. All that's
left is
spanning tree. I'm probably going to need this pretty soon, so once more
I'm asking if anyone is
knowing NFS in general far better than *BSD in specific, I would guess the best
thing to do (if you suspect server/client communication anomaly) is to grab a
snoop/tcpdump of the failure. I'm trying to think of a clever way to cause the
failure immediately, so you're not tracing 4GB of
What I want to know is can I just link tap0.upper to a new bridge hook? It
seems to me that is the case.
yes I believe so..
you can hook as many interfaces as you want to the bridge node.
(but you probably don't want to BRIDGE to your cable modem, but to ROUTE
to it )
Don't worry =)
I
"Rogier R. Mulhuijzen" wrote:
What I want to know is can I just link tap0.upper to a new bridge hook? It
seems to me that is the case.
yes I believe so..
you can hook as many interfaces as you want to the bridge node.
(but you probably don't want to BRIDGE to your cable modem, but to
Mike Smith wrote:
Ok so I have tried the settings in
teh loader conf..
I have:
#autoboot_delay="10"# Delay in seconds before autobooting
#console="vidconsole" # Set the current console
currdev="disk1s1a" # Set the current device
If you mean "it loads the kernel from the wrong place", that's one thing.
If you mean "it mounts / from the wrong filesystem", then you should be
aware that the loader reads /etc/fstab, and the kernel will mount
whatever you've put in there.
Just curious, but isn't there a checken-and-egg
Hello.
I tried make buildworld after cvsuped my source and it failed in perl
area.
I remove PERL_THREADED=true and tried again and it failed.
=== usr.bin/kdump
cc -O -pipe -march=pentium -I/usr/src/usr.bin/kdump/../ktrace
-I/usr/src/usr.bin/kdump/../.. -I/usr/obj/usr/src/i386/usr/include -c
At 25 Jan 2001 19:08:14 GMT,
Martin Blapp wrote:
http://www.attic.ch/rpc.diff_01114001.tgz
I cannot fetch it. Gone into attic? :-)
--
Jun Kuriyama [EMAIL PROTECTED] // IMG SRC, Inc.
[EMAIL PROTECTED] // FreeBSD Project
To Unsubscribe: send mail to [EMAIL PROTECTED]
with
Hi, I'll place a new version tomorrow on the server.
be patient untill then.
Martin
Martin Blapp, [EMAIL PROTECTED]
Improware AG, UNIX solution and service provider
Zurlindenstrasse 29, 4133 Pratteln, Switzerland
Phone: +41 79 370 26 05, Fax:
VLF-incapable utilities. (on a related note, is there a need for
vlfread()/vlfwrite() in the BSD's, or is VLF support native in the read/write
calls?
The standard off_t is 64 bits in all of the BSDs.
--
... every activity meets with opposition, everyone who acts has his
rivals and
#autoboot_delay="10"# Delay in seconds before autobooting
#console="vidconsole" # Set the current console
currdev="disk1s1a" # Set the current device
module_path="/boot/kernel;/boot/modules"# Set the module search path
If you mean "it loads the kernel from the wrong place", that's one thing.
If you mean "it mounts / from the wrong filesystem", then you should be
aware that the loader reads /etc/fstab, and the kernel will mount
whatever you've put in there.
Just curious, but isn't there a
Hello,
'make buildworld' failed while trying to comple sysinstall:
cc -O -pipe -Wall -I/usr/src/usr.sbin/sysinstall/../../gnu/lib/libdialog -I.
-I/usr/obj/usr/src/i386/usr/include -c /usr/src/usr.sbin/sysinstall/keymap.c
In file included from /usr/src/usr.sbin/sysinstall/keymap.c:40:
One of my current machines here are running PPPoE..
for some reason, it will some times become extramly lag of its PPPoE
connection. (for example, from 25ns ping time become 2500ns ping
time). And will back to normal in few mins..
However, i do not see the same problem on my 4.2 stable system.
Hi
I see no perl failure below...
M
Hello.
I tried make buildworld after cvsuped my source and it failed in perl
area.
I remove PERL_THREADED=true and tried again and it failed.
=== usr.bin/kdump
cc -O -pipe -march=pentium -I/usr/src/usr.bin/kdump/../ktrace
On 22-Jan-01 Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED], John Hay
write
s:
But while you're at it, migrate to md(4) instead of vn(4), it does
vn(4) will be deprecated RSN. mdconfig(8) configures the md(4) devices
So why not change the release process to use md instead of
56 matches
Mail list logo