On Mon, 1 Jul 2002, Julian Elischer wrote:
>
> On Mon, 1 Jul 2002, Daniel Eischen wrote:
>
> > On Mon, 1 Jul 2002, Julian Elischer wrote:
> >
> > > I think that gets us a LOT closer!
> > >
> > >
> > > Total tests 212, passed 212, failed 0
> > > ref4# Jul 2 01:52:52 ref4 kernel: pid 330 (guar
On Mon, 1 Jul 2002, Daniel Eischen wrote:
> On Mon, 1 Jul 2002, Julian Elischer wrote:
>
> > I think that gets us a LOT closer!
> >
> >
> > Total tests 212, passed 212, failed 0
> > ref4# Jul 2 01:52:52 ref4 kernel: pid 330 (guard_b), uid 0: exited on
> > signal 11 (core dumped)
> > Jul 2
On Mon, 1 Jul 2002, Julian Elischer wrote:
> I think that gets us a LOT closer!
>
>
> Total tests 212, passed 212, failed 0
> ref4# Jul 2 01:52:52 ref4 kernel: pid 330 (guard_b), uid 0: exited on
> signal 11 (core dumped)
> Jul 2 01:52:52 ref4 kernel: pid 338 (guard_b), uid 0: exited on signa
SMP builds are still producing panics every 2-4 buildworlds after the
KSE commit, I'm still trying to track that down. But I was able to
complete the softupdates/non-softupdates test with a UP build of
-current:
with softupdates (UP BUILD, CURRENT):
3122.30 real 2360.7
I think that gets us a LOT closer!
Total tests 212, passed 212, failed 0
ref4# Jul 2 01:52:52 ref4 kernel: pid 330 (guard_b), uid 0: exited on
signal 11 (core dumped)
Jul 2 01:52:52 ref4 kernel: pid 334 (guard_b), uid 0: exited on signal 11
(core dumped)
Jul 2 01:52:52 ref4 kernel: pid 338 (g
> In <[EMAIL PROTECTED]>
> Julian Elischer <[EMAIL PROTECTED]> wrote:
JE> the question is:
JE> did you update both kernel and userland?
Yes. I always do update the whole world.
> I updated my current box about an hour ago, and got into trouble too.
And I backed kernel only of date=2
On Mon, 1 Jul 2002, Daniel Eischen wrote:
>
> > mutex_d (**hangs here**)
>
> This one takes quite a long time to run. Run it by hand and you'll
> see if it's really hanging or not.
you're not wrong!
it takes ages.. (still running in another window)
false al
On Mon, 1 Jul 2002, Julian Elischer wrote:
> On Mon, 1 Jul 2002, Daniel Eischen wrote:
>
> >
> > Someone can also try going into lib/libc_r/test and running the
> > tests in there, to see if even simple threaded programs are borken
> > or not.
> A
> cool
> I didn't know they are there!
>
>
turned out to be minor.. see other mail
On Mon, 1 Jul 2002, Julian Elischer wrote:
>
>
> On Mon, 1 Jul 2002, Daniel Eischen wrote:
>
> > I'm not sure. I would be interested in seeing any warnings from building
> > new libc_r. The only places I can think of are the queues (with the
> > QMD
On Mon, 1 Jul 2002, Daniel Eischen wrote:
>
> Someone can also try going into lib/libc_r/test and running the
> tests in there, to see if even simple threaded programs are borken
> or not.
A
cool
I didn't know they are there!
heres what happens when it is run (After fixing typos)
make: don'
I got this drive ("LF-D321" is printed in front of drive), but burncd
cannot set speed.
> acd1: DVD-R at ata1-slave PIO4
% sudo burncd -f /dev/acd1c data release.iso
burncd: ioctl(CDRIOCWRITESPEED): Input/output error
Dmesg shows:
> acd1: SET_SPEED - ILLEGAL REQUEST asc=0x20 ascq=0x00 error=
On Mon, 1 Jul 2002, Daniel Eischen wrote:
> I'm not sure. I would be interested in seeing any warnings from building
> new libc_r. The only places I can think of are the queues (with the
> QMD debug defined, that would definitely cause problems), but that
> seems to have been ruled out also w
I have seen this an dhoped that fixing some of the less scary ones would
fix it too..
^Z seems to occasionally kill the (or one of) process instead.
I have not figured it out..
Peter, did you see the mail I forwarded to you regarding the
condvar/msleep race?
I was hoping for a second opinion.
On Mon, 1 Jul 2002, Julian Elischer wrote:
>
> On Mon, 1 Jul 2002, Daniel Eischen wrote:
>
> >
> > I also made changes to uthread_sigpending.c and uthread_sigsuspend.c
> > 3 days ago (lib/libc_r/uthread/...). You can try reverting those
> > changes and go back to revisions 1.18 and 1.11 respec
This is on beast.freebsd.org, running -current as of about 20 minutes
ago. I just rm'ed a .o file and did a make:
peter@beast[5:32pm]/usr/src/sys/alpha/compile/BEAST-6# rm yarrow.o
peter@beast[5:32pm]/usr/src/sys/alpha/compile/BEAST-7# make
cc -c -O -pipe -mcpu=ev56 -Wall -Wredundant-decls -Wne
On Mon, 1 Jul 2002, Daniel Eischen wrote:
>
> I also made changes to uthread_sigpending.c and uthread_sigsuspend.c
> 3 days ago (lib/libc_r/uthread/...). You can try reverting those
> changes and go back to revisions 1.18 and 1.11 respectively.
It seems that you have been exhonorated..
I gue
Title: ces
±ÍÇÏÀÇ ½Â¶ô¾øÀÌ È«º¸¼º
oops,, sorry, you are right..
still it's being so confusing with people saying this and that, that it's
only now that I'm starting to believe that it's not the kernel
doing something nasty.
On Mon, 1 Jul 2002, Wesley Morgan wrote:
> I already tried that this morning, it had no effect ... Unl
I already tried that this morning, it had no effect ... Unless you would
like me to try an old kernel with it
On Mon, 1 Jul 2002, Julian Elischer wrote:
> can you try compiling a new libc_r with th efollowing change suggested by
> Dan Eischen:
>
> --begin quote:
>
> I also made changes to u
can you try compiling a new libc_r with th efollowing change suggested by
Dan Eischen:
--begin quote:
I also made changes to uthread_sigpending.c and uthread_sigsuspend.c
3 days ago (lib/libc_r/uthread/...). You can try reverting those
changes and go back to revisions 1.18 and 1.11 respecti
Somehow this thread slipped into privmail.
Original Message
Subject: Re: Post-KSE disaster with libc_r
Date: Mon, 1 Jul 2002 14:23:23 -0700 (PDT)
From: Julian Elischer <[EMAIL PROTECTED]>
To: Michael Nottebrock <[EMAIL PROTECTED]>
> [Applied 'thediff' to pre-KSE CURRENT and re
Hey Folks,
So now I'm working somewhere that we're trying to use Picobsd on the
Soekris boards (www.soekris.com). Right now there is a build problem I'm
trying to
solve. When picobsd goes to build the libraries etc. it chokes on the csu
stuff:
CC="cc" MKDEP_CPP_OPTS="-M -DCRT_BEGIN"
Reverting proc.h and queue.h do nothing. Booting a kernel from 20020624,
still crashes all threaded systems. Same behavior on a 20020620 kernel.
> I don't change any of those.
>
> On Mon, 1 Jul 2002, Daniel Eischen wrote:
>>
>> I'd suspect that it is something to do with the layout of
>> the fpreg
÷ Mon, 01.07.2002, × 00:21, Julian Elischer ÎÁÐÉÓÁÌ:
> hmmm
> well, since the only changes were in the kernel except for libkvm
> I'm puzzled. If you boot off the old kernel (You still have it right? :-)
> does it still act the same?
I have same problem, reverting to old (20020625) kernel not
On Mon, 1 Jul 2002, Julian Elischer wrote:
> I don't change any of those.
>
> On Mon, 1 Jul 2002, Daniel Eischen wrote:
> >
> > I'd suspect that it is something to do with the layout of
> > the fpregs, mcontext or something like that. Libc_r mucks
> > about in jmp_buf (userland) and ucontext/mc
I don't change any of those.
On Mon, 1 Jul 2002, Daniel Eischen wrote:
>
> I'd suspect that it is something to do with the layout of
> the fpregs, mcontext or something like that. Libc_r mucks
> about in jmp_buf (userland) and ucontext/mcontext, so anything
> that changed those would cause prob
I have some debug stuff added for TAILQs
theoretically it should be defined out but
I don't trust theory :-)
On Mon, 1 Jul 2002, Daniel Eischen wrote:
> On Mon, 1 Jul 2002, Julian Elischer wrote:
>
> > is there any chance you can try compile a new libc_r but with old versions
> > of proc.h and
On Mon, 1 Jul 2002, Christian Weisgerber wrote:
> Mike Barcroft <[EMAIL PROTECTED]> wrote:
>
> > You might want to get rid of the other misuse of `rc' above this and
> > just remove the variable.
>
> The use of an gratuitous int variable rc to capture return values
> is rampant throughout this c
On Mon, 1 Jul 2002, Julian Elischer wrote:
>
> On Mon, 1 Jul 2002, Andrey A. Chernov wrote:
>
> > On Mon, Jul 01, 2002 at 10:26:22 -0700, Julian Elischer wrote:
> > > the question is:
> > > did you update both kernel and userland?
> >
> > This bug is not related to in-kernel KSE code (but, mayb
On Mon, 1 Jul 2002, Julian Elischer wrote:
> is there any chance you can try compile a new libc_r but with old versions
> of proc.h and queue.h in the system?
What changed in queue.h? We do have some macros defined for presetting
queue.h *_HEAD's.
--
Dan Eischen
To Unsubscribe: send mail to
is there any chance you can try compile a new libc_r but with old versions
of proc.h and queue.h in the system?
On Mon, 1 Jul 2002, Andrey A. Chernov wrote:
> On Mon, Jul 01, 2002 at 10:26:22 -0700, Julian Elischer wrote:
> > the question is:
> > did you update both kernel and userland?
>
> Th
On Mon, 1 Jul 2002, Andrey A. Chernov wrote:
> On Mon, Jul 01, 2002 at 10:26:22 -0700, Julian Elischer wrote:
> > the question is:
> > did you update both kernel and userland?
>
> This bug is not related to in-kernel KSE code (but, maybe related to
> header files compiled in). I got it even wi
Andrey A. Chernov wrote:
> On Mon, Jul 01, 2002 at 10:26:22 -0700, Julian Elischer wrote:
>
>>the question is:
>>did you update both kernel and userland?
>
>
> This bug is not related to in-kernel KSE code (but, maybe related to
> header files compiled in). I got it even with updated userland a
Mike Barcroft <[EMAIL PROTECTED]> wrote:
> You might want to get rid of the other misuse of `rc' above this and
> just remove the variable.
The use of an gratuitous int variable rc to capture return values
is rampant throughout this code. In fact, not using it is something
of a violation of the
looks like 2 processors runing the ddb at the same time...
On Mon, 1 Jul 2002, Matthew Dillon wrote:
> I've been doing buildworld tests on an SMP build, 2-cpu 2550 w/ 2G of
> ram configured. It gets through two or three builds and then crashes.
>
> Unfortunately the crash seems to
On Mon, Jul 01, 2002 at 10:26:22 -0700, Julian Elischer wrote:
> the question is:
> did you update both kernel and userland?
This bug is not related to in-kernel KSE code (but, maybe related to
header files compiled in). I got it even with updated userland and old
pre-KSE kernel (with both update
I've been doing buildworld tests on an SMP build, 2-cpu 2550 w/ 2G of
ram configured. It gets through two or three builds and then crashes.
Unfortunately the crash seems to be completely undebuggable. It drops
into DDB> but the serial port is completely screwed up and I can't ty
>
> Jeff , (current included because it may be an interesting answer)
>
>
> As you know I'm using UMA to allocate threads and cache them.
> The 'constructor methods allow me to allocated threads that have been
> pre-set up with thread stacks and other special items.
>
>
> When they are being cach
the question is:
did you update both kernel and userland?
On Mon, 1 Jul 2002, NAKAJI Hiroyuki wrote:
> > In <[EMAIL PROTECTED]>
> > Marc Recht <[EMAIL PROTECTED]> wrote:
>
> > Can someone please check out a libc_r tree as of 3 days ago
> > and try that...
> >
> > There was a commit i
Hi,
panic: Most recently used by routetbl
I get this type of panic withing minutes of uptime with a -current of
25-Jun-2002 around 13:52 GMT-2. Another anomaly is that name resolution
doesn't seem to work reliably, or maybe even TCP in general has a
problem -- it all takes very long if it wo
On Sun, Jun 30, 2002 at 11:58:51PM -0400, Garance A Drosihn wrote:
> Have many people had a chance to test this? I wanted to try it out
> this weekend, but I lost most of the weekend due to other problems
> with compiling current on my test machine. I finally got by those
> problems, but now it'
Ktracing with context switches look the same as before
Stepping into libc_r leads me on a merry chase through what appears to be
normal execution, until somewhere in uthread_sig.c about line 552...
(gdb) r
Starting program: /usr/local/bin/kdeinit
Breakpoint 1 at 0x28e839f6: file
/usr/src/lib/
Christian Weisgerber <[EMAIL PROTECTED]> writes:
> I would like to clean up the last instances of (int)signal(...) in
> the tree. Any objection to the changes below?
>
> Other occurrences not worth touching:
> - contrib/opie/opieftpd.c: contrib, not used
> - libexec/bootpd/bootpd.c: #ifdef'ed
On Sun, 30 Jun 2002, Doug Barton wrote:
> Chuck Robey wrote:
> >
> > I've just finished going thru another medical session, this one took about
> > 5 months, and because of the extended time spent away, I'm running 4.5
> > (I've been running current since 1.1, this feels really odd). I need
> >
On Mon, 2002-07-01 at 09:02, Luigi Rizzo wrote:
> On Mon, Jul 01, 2002 at 09:58:04AM -0400, Andrew Gallatin wrote:
> ...
> > That's actually rather scary. It implies that a freshly checked out
> > tree checked out with plain 'cvs co src' is no longer buildable.
>
> c'mon... it is not that terrib
Several threaded applications like mnogosearch, drweb-sendmail now dumps
core (recent -current). When libc_r replaced by old variant, they works
again.
--
Andrey A. Chernov
http://ache.pp.ru/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the me
Dag-Erling Smorgrav <[EMAIL PROTECTED]> writes:
> gzip: stdout: No space left on device
> *** Error code 1
I moved the Alpha build to a different disk, the next run should be OK.
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe fre
>
> Looks like someone broke AC97 rate measurement in -CURRENT
>
> -STABLE measures AC97 rate well (about 55900). Current gives about
> 41000...
>
> Hardware is Compaq EXD C600 (-STABLE) and Compaq iPAQ C700 (-CURRENT)
> Both are i815 equipped with SoundMAX AC97 codec...
>
>Sincerely, Maxi
On Mon, Jul 01, 2002 at 09:58:04AM -0400, Andrew Gallatin wrote:
...
> That's actually rather scary. It implies that a freshly checked out
> tree checked out with plain 'cvs co src' is no longer buildable.
c'mon... it is not that terrible, just a matter of adding a -P flag
luigi
To Uns
Luigi Rizzo writes:
> On Mon, Jul 01, 2002 at 09:47:26AM -0400, Andrew Gallatin wrote:
> >
> > The same thing happened to me when buildworlding on a ~june 20th
> > current box.
>
> Ruslan explained me the source of the problem... cvs does not
> prune empty directories unless you specify
On Mon, Jul 01, 2002 at 09:47:26AM -0400, Andrew Gallatin wrote:
>
> The same thing happened to me when buildworlding on a ~june 20th
> current box.
Ruslan explained me the source of the problem... cvs does not
prune empty directories unless you specify a revision or a date.
In my case i wanted
The same thing happened to me when buildworlding on a ~june 20th
current box.
I removed CPUTYPE from /etc/make.conf, and I fsck'ed the disk in
question (after a crash resulting from the condvar problem discussed
here). And I removed -j4 from my make flags. One of these things
(sorry that I don
I would like to clean up the last instances of (int)signal(...) in
the tree. Any objection to the changes below?
Other occurrences not worth touching:
- contrib/opie/opieftpd.c: contrib, not used
- libexec/bootpd/bootpd.c: #ifdef'ed out in favor of sigaction().
Index: atmarpd/atmarpd.c
==
--
>>> 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
> MR> I don't know if this helps, but I've a pre-KSE userland (28.06.), a
> MR> post-KSE kernel (30.06.) and I've none of the described problems.
> MR> Evolution, KDE3, Mozilla, ogg123, jdk13 all run without a problem.
>
> I updated my current box about an hour ago, and got into trouble too.
But
> In <[EMAIL PROTECTED]>
> Marc Recht <[EMAIL PROTECTED]> wrote:
> Can someone please check out a libc_r tree as of 3 days ago
> and try that...
>
> There was a commit in libc_r/uthreads 2 days ago that might be relevant.
> failing that, can someone try newly compiled utilities on an
> Can someone please check out a libc_r tree as of 3 days ago
> and try that...
>
> There was a commit in libc_r/uthreads 2 days ago that might be relevant.
> failing that, can someone try newly compiled utilities on an older pre-KSE
> kernel?
>
> We need to eliminate one of these two changes...
Glenn Gombert writes:
> I get the following error when trying to rebuild the last couple of
> days...
>
> ../sys/kern/syscalls.master
> syscall.master : line 55: syscall number out of sync at 7 ...
>
> line is: struct rusage * rsuage ) ; } wait4 wait_args int
>
I've seen this and if I
According to Beech Rintoul:
> Will kde-2.2.2 work with qt3?
No. Qt3 is only for kde 3.x.
> Or will I completely hose my desktop?
> My qt2 got borked during a restore and I can't get it to build with the new
> gcc31. Add that to several others that won't build eit
NAKAJI Hiroyuki wrote:
>
> > In <[EMAIL PROTECTED]>
> > NAKAJI Hiroyuki <[EMAIL PROTECTED]> wrote:
>
> NH> I noticed share/doc/smm/10.named fails after dougb's commit deleting
> NH> contrib/bind/doc/bog/*.
>
> Oops. Dougb already fixed the problem about 2 hours ago.
Yep, sorry about
According to Michael L. Hostbaek:
> When trying to compile the kdebase3 port under recent -CURRENT - I get
> the following error:
Are you sure your libstdc++ is in sync ? Hvae you compiled QT with the ports
gcc (it will break if not) ?
--
Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- [EMA
According to Gavin Atkinson:
> My laptop powered off due to a flat battery, and upon powerup, i
> immediately experienced a panic.
>
> ata0: resetting devices .. done
> panic: ata_dmasetup: transfer active on this device!
It does happen sometimes on my Z600TEL Vaio too.
--
Ollivier ROBERT -=- F
> In <[EMAIL PROTECTED]>
> NAKAJI Hiroyuki <[EMAIL PROTECTED]> wrote:
NH> I noticed share/doc/smm/10.named fails after dougb's commit deleting
NH> contrib/bind/doc/bog/*.
Oops. Dougb already fixed the problem about 2 hours ago.
I'm now under fourth buildworld today. Thanks.
--
NAKAJ
Hi,
I noticed share/doc/smm/10.named fails after dougb's commit deleting
contrib/bind/doc/bog/*.
===
Revision 1.1.1.2 (vendor branch), Mon Jul 1 01:27:59 2002 UTC (6 hours, 43 minutes
ago) by dougb
Branch: VIXIE, MAIN, ISC
CVS Tags: HEAD
Changes since 1.1.1.1: +0 -0 lines
FILE REMOVED
I don't
On (2002/06/30 11:15), Szilveszter Adam wrote:
> Grrr, hit me baby one more time.
>
> One of the diffs included a completely gratuitous one-line change which
> I made yesterday night while I was tired and neglected to correct today.
>
> So, the patchset again. (Take three!)
I've tested your pa
On Mon, 1 Jul 2002, Wesley Morgan wrote:
>
> Both the kdeinit and a child it forks are dying... Setting a breakpoint of
> fork() in the binary shows:
>
>
> Breakpoint 1, 0x28eda7d4 in fork () from /usr/lib/libc.so.5
> (gdb) bt
> #0 0x28eda7d4 in fork () from /usr/lib/libc.so.5
> #1 0x28e83a
I just cvsup'd but when I do a "make buildworld" get:
[...]
[stuff that scrolled off]
[...]
Warning: this is the location of the previous definition
In file included from
/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/config/i386/att.h:22,
from
/usr/obj/usr/src/i386/usr/s
In message: <[EMAIL PROTECTED]>
Julian Elischer <[EMAIL PROTECTED]> writes:
: Who's doing UPDATING now?
Nobody owns it. I've committed your change. I have a few more
changes I should commit.
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" i
Jeff , (current included because it may be an interesting answer)
As you know I'm using UMA to allocate threads and cache them.
The 'constructor methods allow me to allocated threads that have been
pre-set up with thread stacks and other special items.
When they are being cached they still h
70 matches
Mail list logo
