--
Rebuilding the temporary build tree
--
stage 1: bootstrap tools
--
stage 2: cleaning up the object tree
--
Rebuilding the temporary build tree
--
stage 1: bootstrap tools
--
stage 2: cleaning up the object tree
--
Rebuilding the temporary build tree
--
stage 1: bootstrap tools
--
stage 2: cleaning up the object tree
--
Rebuilding the temporary build tree
--
stage 1: bootstrap tools
--
stage 2: cleaning up the object tree
Bruce Evans [EMAIL PROTECTED] writes:
The correct fix is to unbreak getbsize() so that it takes an `int *' as its
first arg like it used to. The interface change and the above change
just give a header length that is not directly usably by any of its users.
The header length is what must be
--
Rebuilding the temporary build tree
--
stage 1: bootstrap tools
--
stage 2: cleaning up the object tree
I made a mballoc kernel thread that fills up mbufs and mbuf clusters
when number of mbufs/clusters of its general list is under low watermark
along with suggestions that Mr. Milekic has made around late November.
http://redjade.org/doc/patches/mballoc_kproc.diff
It seems useful until and even
:...
: is never a problem with its bounds). Other users of getbsize() in the
: src tree but perhaps not ones in ports have been broken to match the
: interface breakage. The usual breakage is to cast the size_t to int
: without checking bounds.
:
:Agreed. Not a single consumer actually wants a
Sevgili internet kullanicilari;
Bu mail sizlere rahatsizlik verdiyse çok çok özür diliyoruz.
Biz Erotik ürün satan bir firmayiz.
Avrupada insanlarin erotik marketlerden satin alarak
gerek ihtiyaçlarinda gerekse hediyelik esya olarak
güvenle kullandiklari erotik ürünleri ithal ederek
ülkemizde
In message [EMAIL PROTECTED], ryan beasley writes:
panic: lockmgr: draining against myself
I've just checked in revision 1.426 of vfs_subr.c which may solve
this, but I was not able to reproduce it myself. Could you or anybody
else who has seen this panic try the above revision to see if it
hello people,
as several other people already noted -current doesn't support
std::wstring. this is a real pitty as more and more programs tend to use
this.
you can test with this simple case:
% cat wchar.cc
#include string
int
main(int, char *[])
{
std::wstring test(Ltest);
}
% c++
I'm trying to debug a kernel problem with the RC1 install CD (I get a
hang) - basically playing with various kernel options and putting debug
printfs.
pxeboot sounded like just the thing I needed - burning CDs or floppies
being too cumbersome for me. I've followed the recipe and get to the
point
--
Rebuilding the temporary build tree
--
stage 1: bootstrap tools
--
stage 2: cleaning up the object tree
--
Rebuilding the temporary build tree
--
stage 1: bootstrap tools
--
stage 2: cleaning up the object tree
According to Dag-Erling Smorgrav:
--
Rebuilding the temporary build tree
--
I don't think it is fixed, we are still getting reports 4600 lines long...
Please someone do
--
Rebuilding the temporary build tree
--
stage 1: bootstrap tools
--
stage 2: cleaning up the object tree
On Mon, Dec 30, 2002 at 02:35:49AM +0900, Kyunghwan Kim wrote:
I made a mballoc kernel thread that fills up mbufs and mbuf clusters
when number of mbufs/clusters of its general list is under low watermark
along with suggestions that Mr. Milekic has made around late November.
Willem Jan Withagen wrote:
Hi,
I'm trying to edit my disklabels to create some swap on just all of them,
however when I try to do so, I get:
---
files# disklabel -w -B ad4s1 auto
disklabel: ioctl DIOCSDINFO: open partition would move or shrink
---
This is in single user
On Sun, 29 Dec 2002, Peter Wemm wrote:
=== sbin/swapon
cc1: warnings being treated as errors
/home/tinderbox/ia64/src/sbin/swapon/swapon.c: In function `swaplist':
/home/tinderbox/ia64/src/sbin/swapon/swapon.c:246: warning: field width is not type
int (arg 3)
HI guys,
Hope someone is awake :-)
watching my dmesg I saw the following:
pid 2612 (interference), uid 1001: exited on signal 11 (core dumped)
Dec 29 22:40:09 byblos kernel: pid 2612 (interference), uid 1001: exited
on signal 11 (core dumped)
what the heck is this?
I am using RC1 and
On Sun, 2002-12-29 at 19:06, redjupiter wrote:
pid 2612 (interference), uid 1001: exited on signal 11 (core dumped)
Dec 29 22:40:09 byblos kernel: pid 2612 (interference), uid 1001: exited
on signal 11 (core dumped)
what the heck is this?
Most probably it's
-r-xr-xr-x 1 root wheel 32016
Brandon S. Allbery KF8NH wrote:
On Sun, 2002-12-29 at 19:06, redjupiter wrote:
pid 2612 (interference), uid 1001: exited on signal 11 (core dumped)
Dec 29 22:40:09 byblos kernel: pid 2612 (interference), uid 1001: exited
on signal 11 (core dumped)
what the heck is this?
Most probably
On Sun, Dec 29, 2002 at 06:47:35PM -0500, Bosko Milekic wrote:
I don't really know what
to tell you because I'm working on the exact same thing (and I
mentionned in the Emails you brought up that I would be) except just
keep your code and go ahead and finish what you had intended but I
I'm trying to debug a kernel problem with the RC1 install CD (I get a
hang) - basically playing with various kernel options and putting debug
printfs.
pxeboot sounded like just the thing I needed - burning CDs or floppies
being too cumbersome for me. I've followed the recipe and get to the
On Mon, Dec 30, 2002 at 09:35:28AM +0900, Kyunghwan Kim wrote:
On Sun, Dec 29, 2002 at 06:47:35PM -0500, Bosko Milekic wrote:
I don't really know what
to tell you because I'm working on the exact same thing (and I
mentionned in the Emails you brought up that I would be) except just
On Sun, Dec 29, 2002 at 03:05:18PM -0800, walt wrote:
The GEOM code is still changing every day so things are not yet in
finished condition. If I understand correctly phk will eventually
make it possible to do what you want, but he's not there quite yet.
I think phk should disable that
On Mon, Dec 30, 2002 at 12:06:08AM +, redjupiter wrote:
HI guys,
Hope someone is awake :-)
watching my dmesg I saw the following:
pid 2612 (interference), uid 1001: exited on signal 11 (core dumped)
Dec 29 22:40:09 byblos kernel: pid 2612 (interference), uid 1001: exited
on signal
--
Rebuilding the temporary build tree
--
stage 1: bootstrap tools
--
stage 2: cleaning up the object tree
On Sun, 29 Dec 2002, Mike Barcroft wrote:
Bruce Evans [EMAIL PROTECTED] writes:
The correct fix is to unbreak getbsize() so that it takes an `int *' as its
first arg like it used to. The interface change and the above change
...
Agreed. Not a single consumer actually wants a size_t and
Hello all,
I recently updated my world to a releng5 source tree from 12/27. I noticed
that almost all of the RCNG scripts work perfectly for diskless (PXE) booting.
There is one minor problem that can easily be fixed. Upon booting the rc
scripts immediately initiate fsck of file systems.
Hi,
While debugging a problem recently I had all.log enabled
in syslog.conf. One of the things I noted was the messages
coming from cron where the ident string was the fully qualified
pathname:
Dec 29 21:00:00 xxx4 /usr/sbin/cron[7409]: (root) CMD (newsyslog)
Dec 29 21:00:00 xxx4
On Mon, Dec 30, 2002 at 03:21:22AM +, Mike Barcroft wrote:
=== sbin/swapon
cc1: warnings being treated as errors
/tinderbox/sparc64/src/sbin/swapon/swapon.c: In function `swaplist':
/tinderbox/sparc64/src/sbin/swapon/swapon.c:246: warning: field width is not type
int (arg 3)
Can someone
Thus spake Kris Kennaway [EMAIL PROTECTED]:
On Mon, Dec 30, 2002 at 03:21:22AM +, Mike Barcroft wrote:
=== sbin/swapon
cc1: warnings being treated as errors
/tinderbox/sparc64/src/sbin/swapon/swapon.c: In function `swaplist':
/tinderbox/sparc64/src/sbin/swapon/swapon.c:246: warning:
--
Rebuilding the temporary build tree
--
stage 1: bootstrap tools
--
stage 2: cleaning up the object tree
On Sun, Dec 29, 2002 at 09:17:05PM -0800, David Schultz wrote:
Thus spake Kris Kennaway [EMAIL PROTECTED]:
On Mon, Dec 30, 2002 at 03:21:22AM +, Mike Barcroft wrote:
=== sbin/swapon
cc1: warnings being treated as errors
/tinderbox/sparc64/src/sbin/swapon/swapon.c: In function
* De: Craig Rodrigues [EMAIL PROTECTED] [ Data: 2002-12-29 ]
[ Subjecte: Re: sparc64 tinderbox failure ]
I'm not sure if your patch will solve the problem.
The offending code is here:
240 if (lflag) {
241 char buf[32];
242
Thus spake Juli Mallett [EMAIL PROTECTED]:
* De: Craig Rodrigues [EMAIL PROTECTED] [ Data: 2002-12-29 ]
[ Subjecte: Re: sparc64 tinderbox failure ]
I'm not sure if your patch will solve the problem.
The offending code is here:
240 if (lflag) {
241
Thus spake David Schultz [EMAIL PROTECTED]:
Right. The complaint is that hlen is 64 bits and the printf()
expects the field length specifier to be an int. The same goes
for getbsize(hlen, ...), so I'm not sure why the compiler didn't
complain about a type mismatch. I guess it just coerced
I've installed RC2 on my new ASUS A7V8X/AthlonXP and the
whole thing went very well except for building XFree.
X does compile with no complaints but when I attempt to
run it I get unresolved symbol errors and then a coredump.
I'm not asking for a fix here, really, so I won't bother
you with
39 matches
Mail list logo
