On Mon, Jan 03, 2000 at 08:29:00PM -0800, Ronald F. Guilmette wrote:
>
> >> >Question 1: What is the reason for FreeBSD to differ from other platforms
> >> >and not follow the IEEE standard by default?
> >> >(Please forgive me if this is an ignorant question.)
[...]
> >That's actually a trick que
I am complete new in FreeBSD. I collect FreeBSD3.3 two CD's from one of
my friend but he not
use this OS. So please help me to install FBSD3.3 . Please inform how
to make partition and boot.
I have 2 harddisk both 6.4 GB. One for Redhat 6.1, SuSE and another
harddisk i like to use FreeBSD(
In message <[EMAIL PROTECTED]>, you wrote:
>
>"Ronald F. Guilmette" <[EMAIL PROTECTED]> writes:
>
>> >Question 1: What is the reason for FreeBSD to differ from other platforms
>> >and not follow the IEEE standard by default?
>> >(Please forgive me if this is an ignorant question.)
>>
>> No, its
In message <[EMAIL PROTECTED]>,
Markus Holmberg <[EMAIL PROTECTED]> wrote:
>IEEE Std 754-1985 (Section 7, paragraph 1) is:
>
>``The default response to an exception shall be to proceed
> without a trap.''
>
>(end quote)
>
>When checking with a simple C program and fpgetmask() I
After browsing the archives of this list searching for information on
SIGFPE issues in FreeBSD I believe I have learnt the following:
From:
http://www.FreeBSD.org/cgi/getmsg.cgi?fetch=903527+906405+/usr/local/www/db/text/1999/freebsd-hackers/19991226.freebsd-hackers
IEEE Std 754-1985 (Section 7
Title: RE: Repeated softupdates panics in 3.3-STABLE
A "pending ops" panic can be induced in fairly short order by running the SMTP performance tests that come with Postfix. Specifically, run smtpstone/smtp-source running many parallel deliveries into a Postfix mail daemon setup running on th
:Well, in Keith's case the locking-against-myself panic is not the
:cause, but the effect of the 'softdep_fsync: pending ops' panic
:that occured just before it.
:
:I've never seeing a pending ops panic before, this is going to be
:one for Kirk to track down. Be sure to keep
:On 03/01 16:29, Keith Stevenson wrote:
:
:> It looks like I may have spoken too soon when I mentioned that I had no
:> problems with softupdates on my postfix based mail server. I have now had
:> two panics in the last month with a panicstr of "softdep_lock: locking
:> against myself". I though
On 03/01 16:29, Keith Stevenson wrote:
> It looks like I may have spoken too soon when I mentioned that I had no
> problems with softupdates on my postfix based mail server. I have now had
> two panics in the last month with a panicstr of "softdep_lock: locking
> against myself". I thought that
Attached is a minor patch to sys/sys/time.h which fixes a mismatch
between the declaration and definition of the getnano{up,}time routines.
The mismatch definately doesn't hurt anything. I only noticed because I
am trying to write man pages for this family of routines. Anyway, if a
committed is
(Matt: I've cc'd you since you seem to have taken an interest in softupdates.
If you would prefer that I not cc you directly in the future, let me know and
it won't happen again.)
I'm posting to -hackers, since my last post of this type to stable didn't seem
to attract any attention.
It looks l
In article <[EMAIL PROTECTED]> you
write:
>> The best fix I've thought of thus far (other than async I/O, which I
>> understand isn't ready for prime time) would be to have a number of kernel
>
>Speaking of AIO, which I would really like to use if possible, how
>actively maintained is it? The cop
On Mon, 3 Jan 2000, Kelly Yancey wrote:
>
> Scanning through sys/kern_clock.c it looks like getmicrotime is
> preferable to microtime since only getmicrotime accounts for
> tco_method (set via the kern.timecounter sysctl). The same is true with
> getnanotime vs nanotime, etc.
> However, I've
Nicolas Souchu wrote:
> Hi there!
>
> FOR ANYBODY THAT USES ZIP/PRINTER/PLIP ON THE PARALLEL PORT UNDER -current
>
> A major ppbus(4) release is available for beta-testing.
Good work! Now plip, which has been broken for ages, works perfectly - no more
lockups, spontaneous reboots, panics, etc! T
On Mon, 3 Jan 2000, Wes Peters wrote:
> Kip Macy wrote:
> >
> > >
> > > The best fix I've thought of thus far (other than async I/O, which I
> > > understand isn't ready for prime time) would be to have a number of kernel
> >
> > Speaking of AIO, which I would really like to use if possible,
Kip Macy wrote:
>
> >
> > The best fix I've thought of thus far (other than async I/O, which I
> > understand isn't ready for prime time) would be to have a number of kernel
>
> Speaking of AIO, which I would really like to use if possible, how
> actively maintained is it? The copyright on vfs_a
>
> The best fix I've thought of thus far (other than async I/O, which I
> understand isn't ready for prime time) would be to have a number of kernel
Speaking of AIO, which I would really like to use if possible, how
actively maintained is it? The copyright on vfs_aio.c is 1997, suggesting
to me
Kip Macy <[EMAIL PROTECTED]> wrote:
> The words "POSIX threads" only describes the API. It says nothing about
> the implementation. On FreeBSD they are non-preemptive user level threads
> (your main was never yielding so the thread you launched did not get any
> time). On Linux they are processes
>
> FreeBSD's ping(8) is not a program that should be used for teaching C
> coding, threaded or not :-)
I am inclined to agree. Programs that could cause DOS attacks are not a
good way to start one's education. My point was merely that the problem
was not insurmountable without raising the thr
In <[EMAIL PROTECTED]>, Kip Macy wrote:
> What is wrong with malloc, then free? The stack size of threads on FreeBSD
> is not that big, but there is no need to be declaring large auto
> variables. Don't get me wrong, I have blown the stack on FreeBSD, and a
> number of other OSs as well, but dyna
What is wrong with malloc, then free? The stack size of threads on FreeBSD
is not that big, but there is no need to be declaring large auto
variables. Don't get me wrong, I have blown the stack on FreeBSD, and a
number of other OSs as well, but dynamic allocation has fixed it in all
cases.
In <001301bf5540$66b72610$0201a8c0@blade>, Steffen Merkel wrote:
> int ping(struct in_addr *ipaddress){
> int s; /* socket handle for socket()*/
> int ident = getpid() & 0x; /* to ident ICMP message */
> int hlen; /* Header length */
> struct sockaddr_in *to; /* used to prepare tohost
Scanning through sys/kern_clock.c it looks like getmicrotime is
preferable to microtime since only getmicrotime accounts for
tco_method (set via the kern.timecounter sysctl). The same is true with
getnanotime vs nanotime, etc.
However, I've noticed a good bit of kernel code is still calling
m
Dear Sirs, Madam
I am Nguyen Manh Tho, from Vietnam. I would like to
know if there is any way to convert the mailling
system
from WinNT server using Nestcape software to Free BSD
mailling system using sendmail software reserving all
data and accounts ? How can I do that ?
Other similar request i
Steffen Merkel wrote (on Jan 02):
> u_char outmessage[MAXPACKET]; /* message we send */
> u_char inmessage[MAXPACKET]; /* message we receive */
How big is MAXPACKET? This is all local scope stuff. You may not have
enough stack defined.
This really is C-101 type stuff.
Chris.
--
== [EMAIL P
25 matches
Mail list logo
