On Sat, 5 May 2001, Daniel Eischen wrote:
On Sat, 5 May 2001, Andrew Gallatin wrote:
Daniel Eischen writes:
OK, thanks. Here's my guess at what should be changed for the Linux
emulator. If this looks correct, I'll commit it.
Hmm, I wonder how linuxthreads works
On Mon, May 07, 2001 at 12:11:16AM -0600, Warner Losh wrote:
In message [EMAIL PROTECTED] Kris Kennaway writes:
: Check the archives, this is a FAQ with probably the usual answer.
Hint: the answer is in UPDATING.
Perhaps we could add Make sure you have loaded random.ko to the output ?
On Mon, 7 May 2001, Bruce Evans wrote:
On Sat, 5 May 2001, Daniel Eischen wrote:
On Sat, 5 May 2001, Andrew Gallatin wrote:
Daniel Eischen writes:
OK, thanks. Here's my guess at what should be changed for the Linux
emulator. If this looks correct, I'll commit it.
On Tue, May 01, 2001 at 02:13:05AM +0300, Tomi Vainio - Sun Finland - wrote:
Benjamin Close writes:
Is anyone looking into converting the Linux winmodem driver (
Lucent Technologies binary object file compiled together with the linux
kernel serial driver) into a freebsd device?
On Sun, 6 May 2001, Kris Kennaway wrote:
On Sat, May 05, 2001 at 02:37:07PM -0700, Dennis Glatting wrote:
I wrote a trivial program to fill vm and found I can reliably freeze my
system. It may not work on the first attempt, but certainly within three.
My command line is:
Dennis Glatting [EMAIL PROTECTED] writes:
I am intentionally testing at the limits to see what happens, usually
interesting things. :) In this case, the application is well behaved (in
the error proccesing sense): it'll exit, thus releasing its memory
resources, when the kernel reports a
On Monday 07 May 2001 08:10 am, Dag-Erling Smorgrav wrote:
Dennis Glatting [EMAIL PROTECTED] writes:
I am intentionally testing at the limits to see what happens,
usually interesting things. :) In this case, the application is
well behaved (in the error proccesing sense): it'll exit, thus
Dennis Glatting [EMAIL PROTECTED] writes:
On Monday 07 May 2001 08:10 am, Dag-Erling Smorgrav wrote:
malloc() will return NULL only if you hit a resource limit or exhaust
address space. There may or may not be memory (real or virtual)
available at that time.
Isn't memory exhaustion a
Hi,
Can't seem to find the no doubtedly obvious answer to the problem with
sshd after remaking world (today's -current with new openssh 2.9)
Trying to log in remotely results in:
May 7 17:37:45 tiggr /boot/kernel/kernel: May 7 17:37:45 tiggr
sshd[718]: fatal: PAM setcred failed[6]:
Peter Jeremy wrote:
Having built and installed -current from last Friday, I find that ssh*
is now reporting no RSA support in libssl and libcrypto. See ssl(8)
and will only talk SSH2. I couldn't find anything relevant in ssl(8).
I haven't specified WITH_RSA=NO anywhere and checking
In article
[EMAIL PROTECTED], Daniel
Eischen [EMAIL PROTECTED] wrote:
I think the only reason we used %fs instead of %gs was WINE. I
think Linux uses %gs for TSD, so if WINE were to ever depend on
linuxthreads, one of them would have to change.
At least on Red Hat 7.0 (glibc-2.1.92-14),
: The malloc() and calloc() functions return a pointer to
: the allocated memory if successful; otherwise a NULL
: pointer is returned and errno is set to ENOMEM.
:
:I assert memory exhaustion is would return unsuccessful on the
:malloc() call, no?
malloc() returns NULL if
In message [EMAIL PROTECTED] Jesper Skriver writes:
: On Mon, May 07, 2001 at 12:11:16AM -0600, Warner Losh wrote:
: In message [EMAIL PROTECTED] Kris Kennaway writes:
: : Check the archives, this is a FAQ with probably the usual answer.
:
: Hint: the answer is in UPDATING.
:
: Perhaps we
On Mon, 07 May 2001 09:55:44 MST, Matt Dillon wrote:
Theoretically the system is supposed to start killing large processes
when memory + swap gets full, but that code does not appear to be working
as well as it should at the moment.
I think that's all that Dennis was
Matt Dillon [EMAIL PROTECTED] writes:
This argument rears its head about once a year and usually turns into a
huge flame war.
Yes, I was going to mention that - search the archives for memory
overcommit and you'll find most of what I've already said in this
thread, and plenty I
On Mon, May 07, 2001 at 07:02:32PM +0200, Dag-Erling Smorgrav wrote:
Matt Dillon [EMAIL PROTECTED] writes:
This argument rears its head about once a year and usually turns into a
huge flame war.
Yes, I was going to mention that - search the archives for memory
overcommit and
:While that's a reasonable question when you're in a support role, I'd
:certainly like to hear whether FreeBSD freezes on memory exhaustion is
:something people should just live with or whether it's symptomatic of
:a bug that someone might one day want to fix but which folks should, for
:now,
Sheldon Hearn [EMAIL PROTECTED] writes:
I think DES was responding to that flame war, rather than to Dennis'
actual question.
Actually, I was responding to Dennis' incorrect assumptions about
FreeBSD's VM system, as exhibited by his code (which reflects the way
he *thinks* the VM system
On Mon, 7 May 2001, John Polstra wrote:
In article
[EMAIL PROTECTED], Daniel
Eischen [EMAIL PROTECTED] wrote:
I think the only reason we used %fs instead of %gs was WINE. I
think Linux uses %gs for TSD, so if WINE were to ever depend on
linuxthreads, one of them would have to change.
One surprising observation: If I disable APM in /boot/device.hints, my
machine suspends and resumes JUST FINE. The BIOS alone seems to be
able to suspend and awake the hardware behind FreeBSD's back. The
system only hangs if FreeBSD is involved in the process.
Hmm, I might try that.
On Sun, May 06, 2001 at 06:11:56AM +0200, Cyrille Lefevre wrote:
Question is, do we want to add this to our cp?
please, what is the difference between this :
cp -Ruv mozilla mozilla-test
and that :
cd mozzila; find . | cpio -pdm ../mozzila-test
Lets try another realistic example:
cp
On Mon, 7 May 2001, Matt Dillon wrote:
their hands of the whole affair. A production machine with 128M of ram
and 1G of swap is going to go down the tubes performance-wise long
before it runs out of swap. Performance degredation under heavy
memory loads is a much more
:Indeed, this is an interesting area. In the process of
:researching how to best implement this for Linux I have
:found various reasons why both FreeBSD's and NetBSD's
:load control systems cannot work in various realistic
:scenarios.
It's not a load control system. It's an emergency
On Mon, 7 May 2001, Matt Dillon wrote:
:Indeed, this is an interesting area. In the process of
:researching how to best implement this for Linux I have
:found various reasons why both FreeBSD's and NetBSD's
:load control systems cannot work in various realistic
:scenarios.
A
load
:
: A
: load control system is something like... oh, the 20 second enforced swap
: out that can be triggered when the VM system is under extreme memory
: pressure.
:
:Yup. Too bad the 20 second enforced swap out isn't enforced...
:(at least, not by the code in vm_glue.c)
:
:I'll
In article [EMAIL PROTECTED],
Daniel Eischen [EMAIL PROTECTED] wrote:
I was looking at our linuxthreads port and noticed some %gs
fiddling. If linuxthreads wants to allow POSIX semantics for
specifying thread stack allocation, they'll have to stop relying
on stack alignments for TSD.
On Mon, 7 May 2001, Alfred Perlstein wrote:
* Rik van Riel [EMAIL PROTECTED] [010507 10:59] wrote:
The next step is designing a load control system that
does work (not too hard) and having a reliable way of
detecting when exactly the system is thrashing (next
to impossible?).
You
On 7 May 2001, Dag-Erling Smorgrav wrote:
Dennis Glatting [EMAIL PROTECTED] writes:
On Monday 07 May 2001 08:10 am, Dag-Erling Smorgrav wrote:
malloc() will return NULL only if you hit a resource limit or exhaust
address space. There may or may not be memory (real or virtual)
Okay, enough said.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
On Mon, 7 May 2001, Alfred Perlstein wrote:
In FreeBSD we submit a patch perhaps after having an N-way
conversation (*) about the problem being addressed.
I'm are awaiting your patch,
I'll let this contradiction speak for itself.
You'll see a detailed analysis soon, patches will come only
Hi,
I was trying to debug a problem where sound card is not working because
it ends up with a irq that is shared with the VGA card. So I
figured I'd use gdb to look at the interrupt handler vector to see what
was there and to find out what is going on. However gdb is unable to
dump the data :
: For some reason banning you from the irc channel hasn't convinced
: you that complaining without providing patches isn't the way we do
: things around here.
:
:How about first analysing the problem in detail and
:trying to fix it after we understand the problem ?
:
:The current stage is that
You'll see a detailed analysis soon, patches will come only
after we've agreed on a way to fix the problem.
You've already had some folks respond to this, though I think the
argument has been mischaracterized as a BSD vs Linux thing. It's
not.
What people are (IMHO) really trying to argue
On 06-May-01 Alfred Perlstein wrote:
* Seigo Tanimura [EMAIL PROTECTED] [010506 04:40] wrote:
http://people.FreeBSD.org/~tanimura/patches/selectopt.diff
Please do not remove the spl calls, they serve as a useful guide
for making finer grained locks as well as error checking the new
On 06-May-01 Seigo Tanimura wrote:
As conversion of select(2) from msleep(9) to a condition variable is
in the SMPng TODO list, I have done that task.
Also, we do not have to lock a process in order to evaluate the result
of {sel,poll}scan() and the remaining time of {select,poll}(2). It
Get your FREE download of MSN Explorer at http://explorer.msn.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Dennis Glatting [EMAIL PROTECTED] writes:
On 7 May 2001, Dag-Erling Smorgrav wrote:
Dennis Glatting [EMAIL PROTECTED] writes:
On Monday 07 May 2001 08:10 am, Dag-Erling Smorgrav wrote:
malloc() will return NULL only if you hit a resource limit or exhaust
address space. There may
Dag-Erling Smorgrav wrote:
Dennis Glatting [EMAIL PROTECTED] writes:
I am intentionally testing at the limits to see what happens, usually
interesting things. :) In this case, the application is well behaved (in
the error proccesing sense): it'll exit, thus releasing its memory
38 matches
Mail list logo
