W Gerald Hicks wrote:
On Wednesday, July 3, 2002, at 04:13 PM, Julian Elischer wrote:
On Wed, 3 Jul 2002, Erik Greenwald wrote:
Looks like I'm out of this one, I got up this morning, cvsup'd and
built
world just to make sure it was fresh, then I quit getting the
crashes. I
d'no if
After building today's -CURRENT successfully (CVSup started at 0347 hrs.
Pacific (7 hrs. west of GMT/UTC at this time of year) from cvsup14, with
the addition of Ruslan's updates to the src/share/mk/bsd.*.mk files),
I thought it might be of use to just let this SMP (2x866 PIII) box sit
in a make
congratulations.. I think that you win the Matt Dillon got both
processors to enter the ddb at the same time award..
On Wed, 3 Jul 2002, David Wolfskill wrote:
login: panic: vm_page_free: invalid wire count (360), pindex: 0x1
cpuid = 0; lapic.id =
Debugger(panic)
uernteilm etoruatp
You were possibly on the right track but we got the answer already :-)
there was a debug statement left in queue.h
that was breaking some of the queues in libc_r
possibly where the thread was taken off the run queue.
Now the very important thing is that you keep looking
and hacking
On Wed, 3 Jul 2002, Erik Greenwald wrote:
Looks like I'm out of this one, I got up this morning, cvsup'd and built
world just to make sure it was fresh, then I quit getting the crashes. I
d'no if the issue was fixed by something someone else did or what...
It was solved, but thanks for
On Wednesday, July 3, 2002, at 04:13 PM, Julian Elischer wrote:
On Wed, 3 Jul 2002, Erik Greenwald wrote:
Looks like I'm out of this one, I got up this morning, cvsup'd and
built
world just to make sure it was fresh, then I quit getting the
crashes. I
d'no if the issue was fixed by
hey don't give up yet..
there's still a couple of crashing bugs hiding in there
you could have your chance yet..
On Wed, 3 Jul 2002, W Gerald Hicks wrote:
On Wednesday, July 3, 2002, at 04:13 PM, Julian Elischer wrote:
On Wed, 3 Jul 2002, Erik Greenwald wrote:
Looks like
Ok so Usability for the average command line user is
very good. David Xu tracked down a problem that was
eluding me with SMP machines. Matt is tracking down
something that may be giving some instability
but may also be related to what David found.
He however gets the award for most confusing
On Tue, 2 Jul 2002, Julian Elischer wrote:
Ok so Usability for the average command line user is
very good. David Xu tracked down a problem that was
eluding me with SMP machines. Matt is tracking down
something that may be giving some instability
but may also be related to what David
BTW feel free to spend some time helping try figire out why libc_r
is bombing out. It's not an exclusive club :-)
On Tue, 2 Jul 2002, Julian Elischer wrote:
Ok so Usability for the average command line user is
very good. David Xu tracked down a problem that was
eluding me with SMP
In message [EMAIL PROTECTED], Ju
lian Elischer writes:
The big problem at the moment is that something in the
source tree as a whole, and probably something that came in with KSE
is stopping us from successfully compiling a working libc_r.
(a bit ironic really).
Is the new
In article local.mail.freebsd-current/[EMAIL PROTECTED] you
write:
In message [EMAIL PROTECTED], Ju
lian Elischer writes:
The big problem at the moment is that something in the
source tree as a whole, and probably something that came in with KSE
is stopping us from successfully compiling a
Good idea.
Unforunatly someone tried to complie a libc_r with the old queue.h and it
had the same problem (or so they said).
On Tue, 2 Jul 2002, Ian Dowse wrote:
In message [EMAIL PROTECTED], Ju
lian Elischer writes:
The big problem at the moment is that something in the
source tree as a
On Tue, 2 Jul 2002, Jonathan Lemon wrote:
In article local.mail.freebsd-current/[EMAIL PROTECTED] you
write:
In message [EMAIL PROTECTED], Ju
lian Elischer writes:
The big problem at the moment is that something in the
source tree as a whole, and probably something that came in with KSE
:...
:another queue using the same link. There are other places in libc_r
:where we do re-use the same link (remove from one list and add to
:another), but roll our own loop in that case:
:
: for (p = TAILQ_FIRST(q); p != NULL; p = p_next) {
: p_next = TAILQ_NEXT(p, p_qe);
:
On Tue, 2 Jul 2002, Julian Elischer wrote:
Good idea.
Unforunatly someone tried to complie a libc_r with the old queue.h and it
had the same problem (or so they said).
Well, it certainly looks wrong to use TAILQ_REMOVE inside of
TAILQ_FOREACH, so either libc_r should be changed or queue.h
I just removed the extra debug line in queue.h
that set the next pointer to -1 then the element was removed.
Since I was told that the problem still occurs with an old queue.h
I don;t think that that will fix it but we might as well try it
again with this change.
On Tue, 2 Jul 2002,
ok, so you are saying that GNOME stuff works fine?
What do yuo have running and is there still anything that does the wrong
thing?
On Tue, 2 Jul 2002, Wesley Morgan wrote:
After reading this... I got to thinking, and I copied the old headers into
the wrong place. After rebuilding, it works
I put the -1 under the conditional
so it should be 'gone' now.
we'll see it makes a difference.
On Tue, 2 Jul 2002, Matthew Dillon wrote:
:...
:another queue using the same link. There are other places in libc_r
:where we do re-use the same link (remove from one list and add to
Dan is there a chance that before you upgrade, you see if you can get the
test program to pass all the tests? If we can have one that passes on a
pre KSE system it will help us considerably.. it seems to fail
on the last 3 tests even pre-KSE. (may be compiler dependent).
I have reports that
On Tue, 2 Jul 2002, Wesley Morgan wrote:
KDE is working fine. GIMP GNUCash are the only two gnome apps I am
using, and they both work. Everybuddy now works... In short, it all
seems to work. I am using rev 1.225 of proc.h and 1.48 of queue.h. Last
cvsup was Jul 1 17:13 MDT.
ok so cen you
On Tuesday 02 July 2002 12:57 am, Julian Elischer wrote:
Ok so Usability for the average command line user is
very good. David Xu tracked down a problem that was
eluding me with SMP machines. Matt is tracking down
something that may be giving some instability
but may also be related to what
After reading this... I got to thinking, and I copied the old headers into
the wrong place. After rebuilding, it works fine :)... That's what I get
for doing it at 2am! My fault, you guys could have fixed this almost
immediately except for some bad info from me.
Good idea.
Unforunatly someone
KDE is working fine. GIMP GNUCash are the only two gnome apps I am
using, and they both work. Everybuddy now works... In short, it all
seems to work. I am using rev 1.225 of proc.h and 1.48 of queue.h. Last
cvsup was Jul 1 17:13 MDT.
ok, so you are saying that GNOME stuff works fine?
What do
On Tue, 2002-07-02 at 16:07, Julian Elischer wrote:
ok, so you are saying that GNOME stuff works fine?
What do yuo have running and is there still anything that does the wrong
thing?
I just did an update of -CURRENT about 4 hours ago, and everything in
GNOME works fine except nautilus.
On Tue, 2 Jul 2002, Julian Elischer wrote:
Dan is there a chance that before you upgrade, you see if you can get the
test program to pass all the tests? If we can have one that passes on a
pre KSE system it will help us considerably.. it seems to fail
on the last 3 tests even pre-KSE. (may
On Tue, 2002-07-02 at 16:42, Julian Elischer wrote:
On Tue, 2 Jul 2002, Wesley Morgan wrote:
KDE is working fine. GIMP GNUCash are the only two gnome apps I am
using, and they both work. Everybuddy now works... In short, it all
seems to work. I am using rev 1.225 of proc.h and 1.48
BTW feel free to spend some time helping try figire out why libc_r
is bombing out. It's not an exclusive club :-)
I took a stab at hunting it down, I think I may've found it in the
libc_r, not the kern
src/lib/libc_r/uthread/uthread_kern.c, in the neighborhood of line 172,
the last line of
You were possibly on the right track but we got the answer already :-)
there was a debug statement left in queue.h
that was breaking some of the queues in libc_r
possibly where the thread was taken off the run queue.
Now the very important thing is that you keep looking
and hacking :-)
On Tue,
On Tue, Jul 02, 2002 at 10:53:23PM -0500, Erik Greenwald wrote:
I took a stab at hunting it down, I think I may've found it in the
libc_r, not the kern
src/lib/libc_r/uthread/uthread_kern.c, in the neighborhood of line 172,
the last line of _thread_kern_sched() is
30 matches
Mail list logo
