On Tuesday, 6th July 1999, Stephen McKay wrote:
>the make world hangs with cc1 in "objtrm"...
I'm having a fun old conversation with myself here! ;-)
Here's some concrete info:
(kgdb) p/x *(struct vm_object*) 0xc32ea21c
$13 = {object_list = {tqe_next = 0xc3389e58, tqe_prev = 0xc323fdec},
sh
You'll want to look primarily in the swap_pager code since it messes with
that (at least it used to - I don't recall what Matt's new code does with it).
There should be various calls to vm_object_pip_* that manipulate the
paging_in_progress number.
-DG
David Greenman
Co-founder/Principal Arch
Hi,
On Mon, Jul 05, 1999 at 04:04:46PM -0400, Nicolas Blais wrote:
> Hi. I've finally installed FreeBSD 4.0 and to tell you the truth, I'm
> not very impressed. I was expecting some bugs but not like that...
Not the best way to start a message if you want to get responses. Also,
the wrapping
I've occasionally seen systems wedged in a similar state. I reported
my sighting of this on May 24th. Haven't seen it since.
The one bit of useful info I've learned since my report was that from
a talk with the program's author, I suspect the object in question may
have been created with mmap
> > Speaking of which, I'm also of the opinion that we should add a "Do
> > you want to run Linux binaries?" query to sysinstall which results in
> > linux emulation being enabled by default and the linux_lib package
> > being loaded. This would make it even more transparent to the
> > user. Any
Dear Furniture Website Owner
We have found your Site
The FreeBSD Project
through the GoTo searchengine.
Here is our free offer:
We are a new and exiting shopping mall.
We offer you to take advantage of our system and place all
your products located at:
http://freebsd.rrze.uni-erlangen.de/
I think you folks are in for a big surprise if you think that the
proposed rtfm(1) tool will save you any heartache.
Most of the times that people come to you for help, it's because they
lack one or more of the time and inclination to help themselves. The
proposed tool's inappropriate name rein
On Mon, 5 Jul 1999, Jordan K. Hubbard wrote:
> I'm also sure this response will probably scare a few people off and
> garner stern rebukes from the newbie hand-holding folks,
As one of the "newbie hand-holding folks" I would say that the
kindest thing you can do for a new user who's wand
On Tue, 6 Jul 1999, Andrew Gallatin wrote:
>
>
> I've occasionally seen systems wedged in a similar state. I reported
> my sighting of this on May 24th. Haven't seen it since.
>
> The one bit of useful info I've learned since my report was that from
> a talk with the program's author, I susp
Andrew Gallatin writes:
>Stephen McKay writes:
> > PS I haven't worked out yet how to find the stack of the errant process.
> > Any hints? The stack trace should be helpful.
>
>Yes. say 'proc pidhashtbl[PID & pidhash]->lh_first' in kgdb.
>
it should also work to do ``ps -M -N '' and pick out
OK. Per many requests from the community, I've committed my cross
compilation changes.
To build you just say
make buildworld TARGET=hpcmips TARGET_ARCH=mipsel
or
make buildworld TARGET=m68k TARGET_ARCH=m68k
Right now you must specify both TARGET and TARGET_ARCH. You will want
I've been seeing this for a while now, even with sources CVSup'd recently.
I've run make clean, and make cleandir many many times, yet if I run make
buildworld, I see this:
===> usr.bin/kdump
cc -nostdinc -O -pipe -I/usr/src/usr.bin/kdump/../ktrace
-I/usr/src/usr.bin/kdump/../.. -I/usr/obj/usr
On Tuesday, 6th July 1999, Andrew Gallatin wrote:
>Yes. say 'proc pidhashtbl[PID & pidhash]->lh_first' in kgdb.
>I suspect that it will be in exit() also..
Magic!
It looks like a plain old exit() to me.
(kgdb) proc pidhashtbl[27157&pidhash]->lh_first
(kgdb) bt
#0 mi_switch () at ../../kern/k
Warner Losh wrote:
>
> OK. Per many requests from the community, I've committed my cross
> compilation changes.
Thanks.
> To build you just say
> make buildworld TARGET=hpcmips TARGET_ARCH=mipsel
> or
> make buildworld TARGET=m68k TARGET_ARCH=m68k
> Right now you must specify both
In message <[EMAIL PROTECTED]> John Birrell writes:
: I was aiming to build a set of cross tools as (an optional) part of the
: i386 build like binutils. When building the cross-compiler, defining
: CROSS_COMPILE and setting the execution path will avoid the native
: compiler. Then in the mk files
Warner Losh wrote:
> You'll need to do this for all binutils as well.
I already build binutils with multi-architecture support. On alpha,
I have "CROSS_TOOLS= i386 m68k" in my /etc/make.conf and at the
end of a make world I have one ld that knows all the formats. Only
gas is a special case, so I
I just cvsup'd today hoping that all the NFS fixes that went in
recently would have alleviated (sp?) the hangs I've been getting
while building things in ports for the last couple of months.
It used to be that just NFS would hang, now it seems to crash the
entire box.
server:/vol/extra/ports /
17 matches
Mail list logo
