A busy day, saw myself, jon and Jeff working on varous tasks.
We have the meat of signal delivey to threads in place (work by Jon and
Jeff) though there may be soem corner cases to work out.
We ahve also reapplied David Xu's patches (with soem minor exceptions
in the profiling code that I amstill
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
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 gradually runs the system out memory.
the wired memory count grows wit
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
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
de
44 matches
Mail list logo
