don't trust yesterday's build :-/
On Thu, 4 Jul 2002, Edwin Culp wrote:
> both with yesterday's build - kernel and world.
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
On Thu, 4 Jul 2002, Kenneth Culver wrote:
> Does this wired memory problem only happen on SMP systems, or is it
> happening across the board?
>
> Ken
>
Uniprocessor had the bug too.
(had... as in I fixed it..)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current
Quoting Kenneth Culver <[EMAIL PROTECTED]>:
| > I'm running a uniproc. box at work with -CURRENT and over 4-5hrs, wired
| > grew from 50megs (when I first time checked) to 141megs (now). Dunno if
| > this normal, but it has kept growing.
|
| OK, I don't see it happening here on my uniproc b
> I'm running a uniproc. box at work with -CURRENT and over 4-5hrs, wired
> grew from 50megs (when I first time checked) to 141megs (now). Dunno if
> this normal, but it has kept growing.
OK, I don't see it happening here on my uniproc box, I havn't tried on my
SMP box, I guess my sources aren't
>
>
>Does this wired memory problem only happen on SMP systems, or is it
>happening across the board?
>
>Ken
>
I'm running a uniproc. box at work with -CURRENT and over 4-5hrs, wired
grew from 50megs (when I first time checked) to 141megs (now). Dunno if
this normal, but it has kept growing.
-
Does this wired memory problem only happen on SMP systems, or is it
happening across the board?
Ken
On Wed, 3 Jul 2002, Julian Elischer wrote:
>
> Well it's all fun and games her at KSE central..
> We have a set of cascading hidden bugs..
>
> bug 1 hides bug 2 hides bug 3
>
> the current state
On Thu, Jul 04, 2002 at 05:40:01AM -0700, Julian Elischer wrote:
> I've checked in a change for the vm change
>
> as for the kernel.. check it is not 0 length :-)
>
Doh! I've built so many kernels the last few
days that I just assumed it worked. I've never
seen an empty /boot/kernel before th
I've checked in a change for the vm change
as for the kernel.. check it is not 0 length :-)
In any case you need the newest vm_glue.c
(and everything else :-)
On Thu, 4 Jul 2002, Steve Kargl wrote:
> On Wed, Jul 03, 2002 at 11:17:53PM -0700, Julian Elischer wrote:
> >
> > bug 1 hides bug 2 h
On Wed, Jul 03, 2002 at 11:17:53PM -0700, Julian Elischer wrote:
>
> bug 1 hides bug 2 hides bug 3
>
> the current state of play:
>
> the system works well for a while however there is a leak in
> the system that gradually runs the system out memory.
> the wired memory count grows with time. My
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
On Wed, 3 Jul 2002, Julian Elischer wrote:
>
> Well it's all fun and games her at KSE central..
> We have a set of cascading hidden bugs..
>
> bug 1 hides bug 2 hides bug 3
>
> the current state of play:
>
> the system works well for a while however there is a leak in
> the system that grad
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:
> >
> >>
>
> 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
>
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 issu
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
>
> 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 ha
On 03-Jul-2002 Julian Elischer wrote:
> 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; la
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 e
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
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
>
> ___longj
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,
> 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
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 pr
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. (m
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. Nau
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?
> Wha
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 someon
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 w
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
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 K
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
> :anot
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 f
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, Da
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.
:...
: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, Jonathan Lemon wrote:
> In article [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
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 tre
In article [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 working libc_r.
>>(a
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
(elm)->
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 mac
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 Dav
41 matches
Mail list logo
