On Tue, 27 Feb 2001, Julian Elischer wrote:
Bruce Evans wrote:
Most of the pcb actually has the same persistence as the kernel stack
(both mainly store the process's context while the process is in the
kernel). But it is silly to put the pcb below the stack instead of
above it.
Bruce Evans wrote:
On Tue, 27 Feb 2001, Julian Elischer wrote:
Bruce Evans wrote:
Most of the pcb actually has the same persistence as the kernel stack
(both mainly store the process's context while the process is in the
kernel). But it is silly to put the pcb below the stack
On 28-Feb-01 Bruce Evans wrote:
On Tue, 27 Feb 2001, John Baldwin wrote:
Ok. It may be that we are overflowing the kernel stack and corrupting the
pcb
in the process. One idea atm is to move the pcb off of the stack (since it
stores persistent data it's a bad place for it anyways) and
In message [EMAIL PROTECTED] Leif Neland
writes:
: === pecoff
: make: don't know how to make machine/lock.h. Stop
If you are making from pure, clean sources, like I think you said you
were, you may need to rm src/sys/modules/pecoff/.depend.
I had a few of these kicking around and it caused me
In message [EMAIL PROTECTED] "David O'Brien" writes:
: On Tue, Feb 27, 2001 at 11:28:37AM -0800, John Baldwin wrote:
: Have you tried running make depend?
:
: I've got the same problem about a bogus dependancy on machine/lock.h.
: And yes, this is after a `make depend' on a /sys I *just*
In message [EMAIL PROTECTED] Edwin Culp writes:
: I had that, and many other problems, about a week ago and I am not
: sure but i think that I ended up doing an rm -rf /usr/sys/modules/*
: , cvsuped made world and built new kernel with no problem. I
: remember that I had to erase all the modules
On Wed, 28 Feb 2001, John Baldwin wrote:
On 28-Feb-01 Bruce Evans wrote:
Most of the pcb actually has the same persistence as the kernel stack
(both mainly store the process's context while the process is in the
kernel). But it is silly to put the pcb below the stack instead of
above
On 27-Feb-01 Leif Neland wrote:
This happens with both my custom and GENERIC kernel.
It has failed for some days, and also with source cvsup'ed today.
A kernel built with "make buildkernel -k" works...
Leif
Have you tried running make depend?
--
John Baldwin [EMAIL PROTECTED] --
John Baldwin writes:
On 27-Feb-01 Leif Neland wrote:
This happens with both my custom and GENERIC kernel.
It has failed for some days, and also with source cvsup'ed today.
A kernel built with "make buildkernel -k" works...
Leif
Have you tried running make depend?
Failing
On Tue, 27 Feb 2001, Gary Jennejohn wrote:
John Baldwin writes:
On 27-Feb-01 Leif Neland wrote:
This happens with both my custom and GENERIC kernel.
It has failed for some days, and also with source cvsup'ed today.
A kernel built with "make buildkernel -k" works...
On 27-Feb-01 Leif Neland wrote:
On Tue, 27 Feb 2001, Gary Jennejohn wrote:
John Baldwin writes:
On 27-Feb-01 Leif Neland wrote:
This happens with both my custom and GENERIC kernel.
It has failed for some days, and also with source cvsup'ed today.
A kernel built with
On Tue, 27 Feb 2001, John Baldwin wrote:
On 27-Feb-01 Leif Neland wrote:
On Tue, 27 Feb 2001, Gary Jennejohn wrote:
John Baldwin writes:
On 27-Feb-01 Leif Neland wrote:
This happens with both my custom and GENERIC kernel.
It has failed for some days, and
On 27-Feb-01 Leif Neland wrote:
On Tue, 27 Feb 2001, John Baldwin wrote:
On 27-Feb-01 Leif Neland wrote:
On Tue, 27 Feb 2001, Gary Jennejohn wrote:
John Baldwin writes:
On 27-Feb-01 Leif Neland wrote:
This happens with both my custom and GENERIC kernel.
On Tue, Feb 27, 2001 at 11:28:37AM -0800, John Baldwin wrote:
Have you tried running make depend?
I've got the same problem about a bogus dependancy on machine/lock.h.
And yes, this is after a `make depend' on a /sys I *just* CVSup'ed. :-(
--
-- David ([EMAIL PROTECTED])
GNU is
On Tue, 27 Feb 2001, John Baldwin wrote:
Ok. It may be that we are overflowing the kernel stack and corrupting the pcb
in the process. One idea atm is to move the pcb off of the stack (since it
stores persistent data it's a bad place for it anyways) and to add a red zone
at the bottom of
Bruce Evans wrote:
On Tue, 27 Feb 2001, John Baldwin wrote:
Ok. It may be that we are overflowing the kernel stack and corrupting the pcb
in the process. One idea atm is to move the pcb off of the stack (since it
stores persistent data it's a bad place for it anyways) and to add a
16 matches
Mail list logo
