Date: Tue, 25 May 1999 03:09:41 -0700 (PDT) From: Nicole Harrington <nicole@nmhtech.com> To: Andrew <mynet@uq.net.au> Cc: freebsd-stable@FreeBSD.ORG, Sergey <serge69@nym.alias.net> Subject: kernel panic in 3.2 WAS Re: [Q] How stable is FreeBSD 3.X ? Message-ID: <XFMail.990525030941.nicole@nmhtech.com> In-Reply-To: <037201bea67f$697957d0$1e8e22cb@upstairs>
index | next in thread | previous in thread | raw e-mail
On 25-May-99 My Secret Spies Reported That Andrew wrote:
> A friend of mine who runs a web hosting and anonymous ftp
> server has been running 3.1 Release for about 2 months without
> even so much as a reboot . The box is on a 100mbit connection
> at a data center. He also has a shell service on the same box.
> The box recently set a record for the amount
> of data served from any client at the data center. The second closest
> client which has a whole room full of SGI and SUN machines was
> only using about half as much data.
>
> The machine is a P2-450 with x3 16 GIG IBM ide drives
> and 512 meg ram.
>
> He has just changed another box in a different country to FreeBSD
> 3.2 release from Solaris 2.7 ( x86 ) because of problems. It is now
> running 3.2 Release and everything seams great. Solaris 2.7 dosent
> like ide drives over 8 gig which isnt good considering IBM make 22 gig
> IDE drives now.
>
> Andrew
I too agree that 3.1 was Very stable and 3.2 for most things seems to be OK so
far as I have used it for many things at the ISP I work for. However I have
come across a reproducable problem with 3.2. just as Sergey has spoken about,
that does not seem to occur in 3.1.
I am testing the new FreeBSD port of the Inktomi caching server. The size of
the processes that are used can grow quite large and are multithreaded.
I have found that if I set MAXDSIZ and DFLDSIZ too small (like 512*1024*1024) I
can make the server page fault and reboot by making it work hard. (IE make the
process grow)
SO far a setting of (2*1024*1024*1024) for both seems to be quite stable under
.any load, but it seems unsettling that rather than kill a process that is
demanding too much memory, the kernel page faults. Especially since the process
runs as a user process not as a system process.
I am no expert on these things, but I welcome the assistance of anyone willing
to help identify the root of this problem to make FreeBSD more stable. Flames
and put downs about a lack of detail or knowlege like I have seen so far, please
send to the linux list of choice to save us both some time please. I use
FreeBSD as it is a professional OS with mostly professional people willing to
lend a hand.
Thanks
BTW Sergey, I realize that you may be frustrated, however sending messages that
are the next best thing to flame bait is not welcome. If you want assistance,
ask for it. Offline more information can be shared and the outcome shared with
the list.
Nicole
>
> ----- Original Message -----
> From: Sergey <serge69@nym.alias.net>
> To: <freebsd-stable@FreeBSD.ORG>
> Sent: Tuesday, May 25, 1999 3:37 PM
> Subject: Re: [Q] How stable is FreeBSD 3.X ?
>
>
>> Hi!
>>
>> I've checked this out on good hardware. And now can CLAIM that
>> 3.1-R *really* have kernel problems on FreeBSD's "classic" configuration.
>> This bug causes TERRIBLE instability - panic in 24 hours. Even Microsoft's
>> OSes gives significantly better results
>>
>>
>>
>> This is mourning day for me - I CAN'T believe in stability of RELEASES
>> any more...
>>
>>
>> With best regards, Sergey.
>>
>>
|\ __ /| (`\
| o_o |__ ) )
// \\
nicole@nmhtech.com | http://www.webweaver.net/
webmistress@dangermouse.org | http://www.dangermouse.org
-------------------------(((---(((-----------------------
- Powered by Coka Cola and FreeBSD -
- Strong enough for a man - But made for a Woman -
- I'm not ADD - I'm just Multithreaded -
----------------------------------------------------------
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.990525030941.nicole>