>> KAME team really needs your suggestions on how to integrate crypto
>> part. In case of NetBSD/KAME integration, we did like this:
>> - place IPsec core part and AH part into cvs.netbsd.org (in US)
>> - place ESP part and crypto algorithms (DES, Blowfish and whatever
>>
[EMAIL PROTECTED] (Alfred Perlstein) writes:
> 1) file descriptor passing (described in Unix Network Programming Vol I)
Or just read recv(2), search for SCM_RIGHTS.
> 2) shared address fork (should be on http://lt.tar.com)
Or just read rfork(2), and you don't need to share the address space.
> KAME team really needs your suggestions on how to integrate crypto
> part. In case of NetBSD/KAME integration, we did like this:
> - place IPsec core part and AH part into cvs.netbsd.org (in US)
> - place ESP part and crypto algorithms (DES, Blowfish and whatever
>
On Mon, 30 Aug 1999 12:26:06 CST, Warner Losh wrote:
> : On LITTLE_ENDIAN machines?
>
> Endian shouldn't matter.
Yup, it was the kind of stupid comment someone who doesn't actually know
what's going on would make. ;-)
I hadn't cottoned on to the notion of using an array.
Thanks,
Sheldon.
> :
> :cvsuped 18 aug 1999 00:35 MSD
> :
>
> I would definitely update it, but that may not be your problem.
>
> If you could email your mount setup (df output) and your kernel
> configuration (dmesg output) I would appreciate it.
>
> If you are running softupdates, try turning i
> >I'll be very happy to work with you on this one.
>
> Does it make sense to make src/crypto/sys for kernel code?
> (for IPsec we need crypto code *in kernel*).
I wonder...
There was a contrib/sys (where softupdates went), and that got moved
to sys/contrib.
Perhaps something simil
> Does it make sense to make src/crypto/sys for kernel code?
> (for IPsec we need crypto code *in kernel*).
I'd say it makes a lot of sense.
- Jordan
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
>> KAME team really needs your suggestions on how to integrate crypto
>> part. In case of NetBSD/KAME integration, we did like this:
>> - place IPsec core part and AH part into cvs.netbsd.org (in US)
>> - place ESP part and crypto algorithms (DES, Blowfish and whatever
>>
> KAME team really needs your suggestions on how to integrate crypto
> part. In case of NetBSD/KAME integration, we did like this:
> - place IPsec core part and AH part into cvs.netbsd.org (in US)
> - place ESP part and crypto algorithms (DES, Blowfish and whatever
>
> :
> :cvsuped 18 aug 1999 00:35 MSD
> :
>
> I would definitely update it, but that may not be your problem.
>
> If you could email your mount setup (df output) and your kernel
> configuration (dmesg output) I would appreciate it.
>
> If you are running softupdates, try turning
On Mon, 30 Aug 1999, Eric Floerchinger wrote:
> I have two NCR system 3430's (P-66 MCA) and two NCR system 3432's
> (486/66 MCA) with NCR SCSI cards (can't remember the chipset offhand).
> I'll try out this kernel as soon as I get some time... I want to find
> some sort of free UNIX that'll work
On Mon, 30 Aug 1999, Kris Kirby wrote:
> I dug up my stash of MCA stuff and came up with the following cards: A
> Token ring card (IBM), a NICps/2 Model PC3000 (82586 powered, 10Base-5
> only), and a Etherlink/MC. Where is this kernel at? :-) Somebody got a
> URL?
http://www.jurai.net/~win
On Mon, 30 Aug 1999, Eric Floerchinger wrote:
> I have two NCR system 3430's (P-66 MCA) and two NCR system 3432's
> (486/66 MCA) with NCR SCSI cards (can't remember the chipset offhand).
> I'll try out this kernel as soon as I get some time... I want to find
> some sort of free UNIX that'll wor
On Mon, 30 Aug 1999, Kris Kirby wrote:
> I dug up my stash of MCA stuff and came up with the following cards: A
> Token ring card (IBM), a NICps/2 Model PC3000 (82586 powered, 10Base-5
> only), and a Etherlink/MC. Where is this kernel at? :-) Somebody got a
> URL?
http://www.jurai.net/~wi
On Sun, 29 Aug 1999, Wes Peters wrote:
> > Trying to model the IA64 would have been a Manhattan Project sized task.
>
> But they've had PLENTY of time. HP had the 64-bit architecture defined
> and a simulator underway in 1994, when Intel joined the project. The
> Merced, which is a specific chi
On Sun, 29 Aug 1999, Wes Peters wrote:
> > Trying to model the IA64 would have been a Manhattan Project sized task.
>
> But they've had PLENTY of time. HP had the 64-bit architecture defined
> and a simulator underway in 1994, when Intel joined the project. The
> Merced, which is a specific ch
Ray Hyatt Jr. wrote:
>
> I have a few PS/2's (Mod 95 and Mod 80's) in my pile of junk,
> I'll see what I can do about getting them booted with this new kernel.
> A bunch of "typical" cards too (Serial, ethernet, token ring, SCSI, etc)
>
I dug up my stash of MCA stuff and came up with the followi
I heard that, some of you, got confused by recent news about
additional NetBSD-core guys (me).
The above fact does not change anything about KAME-FreeBSD
relationship (I can only speak for KAME side though), because:
- KAME project's goal is to provide IPv6/
Ray Hyatt Jr. wrote:
>
> I have a few PS/2's (Mod 95 and Mod 80's) in my pile of junk,
> I'll see what I can do about getting them booted with this new kernel.
> A bunch of "typical" cards too (Serial, ethernet, token ring, SCSI, etc)
>
I dug up my stash of MCA stuff and came up with the follow
hi, i was reading some of the mailing list archives to get an answer to
'why dont icmp echo requests get passed to the raw sockets', and now that
i have the answer i was wondering... is there a way to tell the kernel NOT
to process echo/timestamp/mask requests and instead pass those to the raw
sock
I heard that, some of you, got confused by recent news about
additional NetBSD-core guys (me).
The above fact does not change anything about KAME-FreeBSD
relationship (I can only speak for KAME side though), because:
- KAME project's goal is to provide IPv6
On Mon, 30 Aug 1999, David O'Brien wrote:
> > I've had a week-end away from a keyboard to think about this. The only
> > reason we have to use case statements for case-insensitive variable
> > testing is because sh(1) doesn't offer any upper/lower case handling
>
> Also so that common settings ca
> I've had a week-end away from a keyboard to think about this. The only
> reason we have to use case statements for case-insensitive variable
> testing is because sh(1) doesn't offer any upper/lower case handling
Also so that common settings can be added. Besides "yes" and "no" there
could be ot
hi, i was reading some of the mailing list archives to get an answer to
'why dont icmp echo requests get passed to the raw sockets', and now that
i have the answer i was wondering... is there a way to tell the kernel NOT
to process echo/timestamp/mask requests and instead pass those to the raw
soc
On Mon, 30 Aug 1999, David O'Brien wrote:
> > I've had a week-end away from a keyboard to think about this. The only
> > reason we have to use case statements for case-insensitive variable
> > testing is because sh(1) doesn't offer any upper/lower case handling
>
> Also so that common settings c
On Tue, 31 Aug 1999, John Birrell wrote:
> On Mon, Aug 30, 1999 at 09:13:58AM -0700, Doug wrote:
> > I've seen quite a few reports of this lately, and while this fixes it,
> > it
> > shouldn't be necessary, should it? Has something changed in the 'make
> > upgrade' target recently?
>
> `mak
> I've had a week-end away from a keyboard to think about this. The only
> reason we have to use case statements for case-insensitive variable
> testing is because sh(1) doesn't offer any upper/lower case handling
Also so that common settings can be added. Besides "yes" and "no" there
could be o
On Tue, 31 Aug 1999, John Birrell wrote:
> On Mon, Aug 30, 1999 at 09:13:58AM -0700, Doug wrote:
> > I've seen quite a few reports of this lately, and while this fixes it, it
> > shouldn't be necessary, should it? Has something changed in the 'make
> > upgrade' target recently?
>
> `make' h
On Mon, Aug 30, 1999 at 09:13:58AM -0700, Doug wrote:
> I've seen quite a few reports of this lately, and while this fixes it,
> it
> shouldn't be necessary, should it? Has something changed in the 'make
> upgrade' target recently?
`make' has changed.
--
John Birrell - j...@cimlogic.com.
I'm running natd on a FreeBSD 3.2 router at home which
receives internet service via a cable modem and provides
translation for a host on the back-end of a 10bT ethernet
LAN. The LAN is configured with the 192.168.1/24 address
space.
I'm using the "non-firewall" setting in
/etc/rc.firewa
On Mon, Aug 30, 1999 at 09:13:58AM -0700, Doug wrote:
> I've seen quite a few reports of this lately, and while this fixes it, it
> shouldn't be necessary, should it? Has something changed in the 'make
> upgrade' target recently?
`make' has changed.
--
John Birrell - [EMAIL PROTECTED]; [
you don't need a -k either..
that's for core-files
On Mon, 30 Aug 1999, Zhihui Zhang wrote:
> >
> > On Mon, 30 Aug 1999, Zhihui Zhang wrote:
> >
> > > (3) On machine A, go to the compile directory:
> > >
> > > #gdb -g kernel.debug
> >
> > -g?
> >
> This is a typo. It should be "gdb -k kern
I'm running natd on a FreeBSD 3.2 router at home which
receives internet service via a cable modem and provides
translation for a host on the back-end of a 10bT ethernet
LAN. The LAN is configured with the 192.168.1/24 address
space.
I'm using the "non-firewall" setting in
/etc/rc.firew
>
> On Mon, 30 Aug 1999, Zhihui Zhang wrote:
>
> > (3) On machine A, go to the compile directory:
> >
> > #gdb -g kernel.debug
>
> -g?
>
This is a typo. It should be "gdb -k kernel.debug". I have just posted
another message pointing out my mistakes. Thanks for your response.
-Zhihui
To
On Mon, 30 Aug 1999, Zhihui Zhang wrote:
>
> After reading the handbook and some postings in the mailing list archive.
> I still can not make remote debugging work. I basically did the following
> on FreeBSD-current 4.0 (A is debugging machine, B is the target):
>
> (1) Build a debug kernel
you don't need a -k either..
that's for core-files
On Mon, 30 Aug 1999, Zhihui Zhang wrote:
> >
> > On Mon, 30 Aug 1999, Zhihui Zhang wrote:
> >
> > > (3) On machine A, go to the compile directory:
> > >
> > > #gdb -g kernel.debug
> >
> > -g?
> >
> This is a typo. It should be "gdb -k ker
On Mon, 30 Aug 1999, Zhihui Zhang wrote:
>
> After reading the handbook and some postings in the mailing list archive.
> I still can not make remote debugging work. I basically did the following
> on FreeBSD-current 4.0 (A is debugging machine, B is the target):
>
> (1) Build a debug kernel
After reading the handbook and some postings in the mailing list archive.
I still can not make remote debugging work. I basically did the following
on FreeBSD-current 4.0 (A is debugging machine, B is the target):
(1) Build a debug kernel (options DDB and BREAK_TO_DEBUGGER) on box A.
The sio f
In message <88584.936022...@axl.noc.iafrica.com> Sheldon Hearn writes:
:
:
: > The Linux trick I like to add is to have sigset_t always be the last
: > field in structures so that the impact of enlarging sigset_t is
: > minimal.
:
: On LITTLE_ENDIAN machines?
Endian shouldn't matter. An array
>
> On Mon, 30 Aug 1999, Zhihui Zhang wrote:
>
> > (3) On machine A, go to the compile directory:
> >
> > #gdb -g kernel.debug
>
> -g?
>
This is a typo. It should be "gdb -k kernel.debug". I have just posted
another message pointing out my mistakes. Thanks for your response.
-Zhihui
To
On Mon, 30 Aug 1999, Zhihui Zhang wrote:
>
> After reading the handbook and some postings in the mailing list archive.
> I still can not make remote debugging work. I basically did the following
> on FreeBSD-current 4.0 (A is debugging machine, B is the target):
>
> (1) Build a debug kerne
On Mon, 30 Aug 1999, Zhihui Zhang wrote:
>
> After reading the handbook and some postings in the mailing list archive.
> I still can not make remote debugging work. I basically did the following
> on FreeBSD-current 4.0 (A is debugging machine, B is the target):
>
> (1) Build a debug kernel
After reading the handbook and some postings in the mailing list archive.
I still can not make remote debugging work. I basically did the following
on FreeBSD-current 4.0 (A is debugging machine, B is the target):
(1) Build a debug kernel (options DDB and BREAK_TO_DEBUGGER) on box A.
The sio
In message <[EMAIL PROTECTED]> Sheldon Hearn writes:
:
:
: > The Linux trick I like to add is to have sigset_t always be the last
: > field in structures so that the impact of enlarging sigset_t is
: > minimal.
:
: On LITTLE_ENDIAN machines?
Endian shouldn't matter. An array at the end of a s
:
:cvsuped 18 aug 1999 00:35 MSD
:
I would definitely update it, but that may not be your problem.
If you could email your mount setup (df output) and your kernel
configuration (dmesg output) I would appreciate it.
If you are running softupdates, try turning it off (but I doubt t
I've seen quite a few reports of this lately, and while this fixes it,
it
shouldn't be necessary, should it? Has something changed in the 'make
upgrade' target recently?
Doug
"Andy V. Oleynik" wrote:
>
> Crist, I had latly same sort of things.
> Fix is to define in ur /etc/make.conf MA
Marcel Moolenaar wrote:
>
> [cc'd to David E. Cross (cro...@cs.rpi.edu) and James Raynard
> (jrayn...@freebsd.org)]
>
> I'm thinking about extending the number of signals. I like your thoughts
> and opinions.
>
> Basicly what I'm going to do is rewrite the signalling code to use a new
> sigset_t
I have a few PS/2's (Mod 95 and Mod 80's) in my pile of junk,
I'll see what I can do about getting them booted with this new kernel.
A bunch of "typical" cards too (Serial, ethernet, token ring, SCSI, etc)
win...@jurai.net was seen typing:
> On Sat, 28 Aug 1999, Peter Wemm wrote:
> > Good stuff
At 12:52 PM +0930 8/28/99, Greg Lehey wrote:
FreeBSD is one of the few operating systems which doesn't have
kernel-level locking. If we want to emulate other systems correctly,
we *must* have advisory locking. This includes SCO UNIX, System V.4
and Linux. I suspect it also includes Microsoft.
:
:cvsuped 18 aug 1999 00:35 MSD
:
I would definitely update it, but that may not be your problem.
If you could email your mount setup (df output) and your kernel
configuration (dmesg output) I would appreciate it.
If you are running softupdates, try turning it off (but I doubt
I've seen quite a few reports of this lately, and while this fixes it, it
shouldn't be necessary, should it? Has something changed in the 'make
upgrade' target recently?
Doug
"Andy V. Oleynik" wrote:
>
> Crist, I had latly same sort of things.
> Fix is to define in ur /etc/make.conf MA
Marcel Moolenaar wrote:
>
> [cc'd to David E. Cross ([EMAIL PROTECTED]) and James Raynard
> ([EMAIL PROTECTED])]
>
> I'm thinking about extending the number of signals. I like your thoughts
> and opinions.
>
> Basicly what I'm going to do is rewrite the signalling code to use a new
> sigset_t a
I have a few PS/2's (Mod 95 and Mod 80's) in my pile of junk,
I'll see what I can do about getting them booted with this new kernel.
A bunch of "typical" cards too (Serial, ethernet, token ring, SCSI, etc)
[EMAIL PROTECTED] was seen typing:
> On Sat, 28 Aug 1999, Peter Wemm wrote:
> > Good stu
> I suppose there already was a rather lengthy discussion about a "user"-option
> .
> I hope this sysctl-thing will make it into the mount-manpage, because if not,
> it might turn out to be a really FAQ :)
> --
> Volker Stolz * st...@pool.informatik.rwth-aachen.de * PGP
I provided a solution via
On Mon, 30 Aug 1999, Dodge Ram wrote:
> Hi,
>
> Have a question on whether it is possible to share
> file descriptors between two processes.
>
> The purpose is to have a stanby process take over when
> the primary process fails. The primary process creates/deletes
> socket connectio
At 12:52 PM +0930 8/28/99, Greg Lehey wrote:
>FreeBSD is one of the few operating systems which doesn't have
>kernel-level locking. If we want to emulate other systems correctly,
>we *must* have advisory locking. This includes SCO UNIX, System V.4
>and Linux. I suspect it also includes Microsof
Hi,
Have a question on whether it is possible to share
file descriptors between two processes.
The purpose is to have a stanby process take over when
the primary process fails. The primary process creates/deletes
socket connections at run time. Forking does not scale well when
th
Sheldon Hearn wrote:
>
> On Mon, 30 Aug 1999 15:55:56 +0200, Marcel Moolenaar wrote:
>
> > The Linux trick I like to add is to have sigset_t always be the last
> > field in structures so that the impact of enlarging sigset_t is
> > minimal.
>
> On LITTLE_ENDIAN machines?
Both NetBSD and Linux d
Hi,
Have a question on whether it is possible to share
file descriptors between two processes.
The purpose is to have a stanby process take over when
the primary process fails. The primary process creates/deletes
socket connections at run time. Forking does not scale well when
th
On Mon, 30 Aug 1999 15:55:56 +0200, Marcel Moolenaar wrote:
> The Linux trick I like to add is to have sigset_t always be the last
> field in structures so that the impact of enlarging sigset_t is
> minimal.
On LITTLE_ENDIAN machines?
Cia,
Sheldon.
To Unsubscribe: send mail to majord...@free
> I suppose there already was a rather lengthy discussion about a "user"-option
> .
> I hope this sysctl-thing will make it into the mount-manpage, because if not,
> it might turn out to be a really FAQ :)
> --
> Volker Stolz * [EMAIL PROTECTED] * PGP
I provided a solution via send-pr (bin/11031
On Mon, 30 Aug 1999, Dodge Ram wrote:
> Hi,
>
> Have a question on whether it is possible to share
> file descriptors between two processes.
>
> The purpose is to have a stanby process take over when
> the primary process fails. The primary process creates/deletes
> socket connecti
Nick Hibma wrote:
>
> > Basicly what I'm going to do is rewrite the signalling code to use a new
> > sigset_t and provide new syscalls to use it. The current syscalls convert
> > between the current and the new types for compatibility. I think I'm going
> > to borrow a thought or two from Linu
Hi,
Have a question on whether it is possible to share
file descriptors between two processes.
The purpose is to have a stanby process take over when
the primary process fails. The primary process creates/deletes
socket connections at run time. Forking does not scale well when
th
Sheldon Hearn wrote:
>
> On Mon, 30 Aug 1999 15:55:56 +0200, Marcel Moolenaar wrote:
>
> > The Linux trick I like to add is to have sigset_t always be the last
> > field in structures so that the impact of enlarging sigset_t is
> > minimal.
>
> On LITTLE_ENDIAN machines?
Both NetBSD and Linux
g...@lemis.com (Greg Lehey) writes:
> All systems which do more than one thing at a time need file locking
> at some time or another. Since it involves cooperation between
> potentially unrelated processes, it's an obvious kernel function. Any
> "solution" requiring cooperation between processe
Hi,
Have a question on whether it is possible to share
file descriptors between two processes.
The purpose is to have a stanby process take over when
the primary process fails. The primary process creates/deletes
socket connections at run time. Forking does not scale well when
th
> Basicly what I'm going to do is rewrite the signalling code to use a new
> sigset_t and provide new syscalls to use it. The current syscalls convert
> between the current and the new types for compatibility. I think I'm going
> to borrow a thought or two from Linux which allows further incre
On Mon, 30 Aug 1999 15:55:56 +0200, Marcel Moolenaar wrote:
> The Linux trick I like to add is to have sigset_t always be the last
> field in structures so that the impact of enlarging sigset_t is
> minimal.
On LITTLE_ENDIAN machines?
Cia,
Sheldon.
To Unsubscribe: send mail to [EMAIL PROTEC
I suppose there already was a rather lengthy discussion about a "user"-option.
I hope this sysctl-thing will make it into the mount-manpage, because if not,
it might turn out to be a really FAQ :)
--
Volker Stolz * st...@pool.informatik.rwth-aachen.de * PGP
To Unsubscribe: send mail to majord...
Nick Hibma wrote:
>
> > Basicly what I'm going to do is rewrite the signalling code to use a new
> > sigset_t and provide new syscalls to use it. The current syscalls convert
> > between the current and the new types for compatibility. I think I'm going
> > to borrow a thought or two from Lin
[cc'd to David E. Cross (cro...@cs.rpi.edu) and James Raynard
(jrayn...@freebsd.org)]
I'm thinking about extending the number of signals. I like your thoughts
and opinions.
Why more than 32 signals?
Primarily because Linux now uses more than 32 signals and I'm going to run
into trouble in the Li
[EMAIL PROTECTED] (Greg Lehey) writes:
> All systems which do more than one thing at a time need file locking
> at some time or another. Since it involves cooperation between
> potentially unrelated processes, it's an obvious kernel function. Any
> "solution" requiring cooperation between proc
> Basicly what I'm going to do is rewrite the signalling code to use a new
> sigset_t and provide new syscalls to use it. The current syscalls convert
> between the current and the new types for compatibility. I think I'm going
> to borrow a thought or two from Linux which allows further incr
I suppose there already was a rather lengthy discussion about a "user"-option.
I hope this sysctl-thing will make it into the mount-manpage, because if not,
it might turn out to be a really FAQ :)
--
Volker Stolz * [EMAIL PROTECTED] * PGP
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "uns
[cc'd to David E. Cross ([EMAIL PROTECTED]) and James Raynard
([EMAIL PROTECTED])]
I'm thinking about extending the number of signals. I like your thoughts
and opinions.
Why more than 32 signals?
Primarily because Linux now uses more than 32 signals and I'm going to run
into trouble in the Linu
wi works fine as furnished with 3.2-stable.
Jim Flowers
#4 ISP on C|NET, #1 in Ohio
On Sat, 28 Aug 1999, Randy Bush wrote:
>
> day? for me and a bunch of others it happens immediately. we have never
> been able to get wlp or wi going since 3.x.
>
> randy, running -release+pao
>
To Unsubs
Hello All .
I have a questuon - how much may be this things :
options SHMALL=1025
options "SHMMAX=(SHMMAXPGS*PAGE_SIZE+1)"
options SHMMAXPGS=1025
options SHMMIN=2
options SHMMNI=33
options SHMS
wi works fine as furnished with 3.2-stable.
Jim Flowers <[EMAIL PROTECTED]>
#4 ISP on C|NET, #1 in Ohio
On Sat, 28 Aug 1999, Randy Bush wrote:
>
> day? for me and a bunch of others it happens immediately. we have never
> been able to get wlp or wi going since 3.x.
>
> randy, running -releas
Hello All .
I have a questuon - how much may be this things :
options SHMALL=1025
options "SHMMAX=(SHMMAXPGS*PAGE_SIZE+1)"
options SHMMAXPGS=1025
options SHMMIN=2
options SHMMNI=33
options SHM
On Sat, 28 Aug 1999 16:46:11 MST, Doug wrote:
> Hoping I'm running out of nits,
:-)
Hi Doug,
I've had a week-end away from a keyboard to think about this. The only
reason we have to use case statements for case-insensitive variable
testing is because sh(1) doesn't offer any upper/lower case h
> > we use hightly loaded nfsv3/udp server with 5 fbsd nfs client
> > all with 3.2-stable
>
> The most typical cause for these crashes is hardware-induced memory
> corruption, caused by bad memory, a faulty or misconfigured motherboard
> or an overclocked CPU. Are you performing any computation
>
> :we use hightly loaded nfsv3/udp server with 5 fbsd nfs client
> :all with 3.2-stable
> :
>
> Exactly how recent are your kernel sources / kernel build? There have
> been a significant number of fixes to NFS in the last few weeks.
cvsuped 18 aug 1999 00:35 MSD
>
>
On Sat, 28 Aug 1999 16:46:11 MST, Doug wrote:
> Hoping I'm running out of nits,
:-)
Hi Doug,
I've had a week-end away from a keyboard to think about this. The only
reason we have to use case statements for case-insensitive variable
testing is because sh(1) doesn't offer any upper/lower case
> > we use hightly loaded nfsv3/udp server with 5 fbsd nfs client
> > all with 3.2-stable
>
> The most typical cause for these crashes is hardware-induced memory
> corruption, caused by bad memory, a faulty or misconfigured motherboard
> or an overclocked CPU. Are you performing any computatio
:we use hightly loaded nfsv3/udp server with 5 fbsd nfs client
:all with 3.2-stable
:
Exactly how recent are your kernel sources / kernel build? There have
been a significant number of fixes to NFS in the last few weeks.
-Matt
To Unsubscribe: se
> we use hightly loaded nfsv3/udp server with 5 fbsd nfs client
> all with 3.2-stable
The most typical cause for these crashes is hardware-induced memory
corruption, caused by bad memory, a faulty or misconfigured motherboard
or an overclocked CPU. Are you performing any computational work on
87 matches
Mail list logo
