On Thu, 4 Jul 2002, Julian Elischer wrote:
>
> On Thu, 4 Jul 2002, Daniel Eischen wrote:
>
> > On Thu, 4 Jul 2002, Julian Elischer wrote:
> >
> > > 2/
> > > We could add a new macro/method that is slightly less efficient than the
> > > current FOREACH macros, but allows element removal.
> > > E
On Thu, 4 Jul 2002, Daniel Eischen wrote:
> On Thu, 4 Jul 2002, Julian Elischer wrote:
>
> > there are two proposals floatingat the moment..
> >
> > 1/ I added debugging stuff to TAILQ to help find bad usages in KSE.
> > Qusetion/proposal: Should I extend this to other types and add it to the
*phew* (wipes sweat from brow)
Ok After a hectic couple of days it looks like the stability of -current
is back where it should be. Multiple buildworlds are completing
with no discernable degradation.
At this time I have no information on any apps that fail to work (that did
work before KSE).
On Thu, 4 Jul 2002, Julian Elischer wrote:
> there are two proposals floatingat the moment..
>
> 1/ I added debugging stuff to TAILQ to help find bad usages in KSE.
> Qusetion/proposal: Should I extend this to other types and add it to the
> file (or not delete what is there now)
I was suggesti
there are two proposals floatingat the moment..
1/ I added debugging stuff to TAILQ to help find bad usages in KSE.
Qusetion/proposal: Should I extend this to other types and add it to the
file (or not delete what is there now)
2/
We could add a new macro/method that is slightly less efficient
how about getting the new version of vm_glue.c that fixes this?
:-)
On Thu, 4 Jul 2002, Mario Goebbels wrote:
> 4th July 5pm CET, with world and kernel from 11am 3rd July, after a
> couple of hours runtime, doing mainly xchat and Mozilla, I got these stats:
>
> Mem: 73M Active, 221M Inact, 210
> Hi, I just updated this morning to the latest -CURRENT, and just to let
> everyone know, the new KSE stuff seems to be working fine... however, my
> ipfw rules for dummynet no longer work:
>
> ipfw add queue 1 tcp from any to a.b.c.d 25 in via fxp0
> ipfw pipe 1 config bw 28Kbit/s queue 2
> ipfw
On 3 Jul, Peter Wemm wrote:
> Chuck Robey wrote:
>> On Wed, 3 Jul 2002, David O'Brien wrote:
>>
>> > On Wed, Jul 03, 2002 at 07:43:22PM -0700, George V. Neville-Neil wrote:
>> > > I know everyone says "they all work" but i'd like some recommendations
> on
>> > > MP machines for -CURRENT wo
Hi, I just updated this morning to the latest -CURRENT, and just to let
everyone know, the new KSE stuff seems to be working fine... however, my
ipfw rules for dummynet no longer work:
ipfw add queue 1 tcp from any to a.b.c.d 25 in via fxp0
ipfw pipe 1 config bw 28Kbit/s queue 2
ipfw queue 1 conf
On Thu, 4 Jul 2002, Julian Elischer wrote:
> that was teh plan... we're just discussing the name..
> TAILQ_FOREACH_SAFE ?
Oh, I thought the initial proposal was to add a _new_ interface
that allowed safe removals while traversing the list (and allow
the existing macros to be changed for debugging
On Fri, Jul 05, 2002 at 02:38:08AM +1000, Bruce Evans wrote:
> On Thu, 4 Jul 2002, Jonathan Lemon wrote:
>
> > In article
>[EMAIL PROTECTED]> you
>write:
> > >in RELENG_4, when one calls callout_stop() (not nested in softclock execute
> > >path
> > >, I am not talking about this case), after it
On Thu, 4 Jul 2002, Jonathan Lemon wrote:
> In article
>[EMAIL PROTECTED]> you
>write:
> >in RELENG_4, when one calls callout_stop() (not nested in softclock execute
> >path
> >, I am not talking about this case), after it returns, he can believe that the
> >callout is truely stopped, however i
4th July 5pm CET, with world and kernel from 11am 3rd July, after a
couple of hours runtime, doing mainly xchat and Mozilla, I got these stats:
Mem: 73M Active, 221M Inact, 210M Wired, 1128K Cache, 61M Buf, 136M Free
Swap: 512M Total, 512M Free
I started a buildworld, then I aborted somewhere i
Quoting Mario Goebbels <[EMAIL PROTECTED]>:
| 4th July 5pm CET, with world and kernel from 11am 3rd July, after a
| couple of hours runtime, doing mainly xchat and Mozilla, I got these stats:
|
| Mem: 73M Active, 221M Inact, 210M Wired, 1128K Cache, 61M Buf, 136M Free
| Swap: 512M Total, 5
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
Chuck Robey wrote:
>On Wed, 3 Jul 2002, David O'Brien wrote:
>
>>On Wed, Jul 03, 2002 at 07:43:22PM -0700, George V. Neville-Neil wrote:
>>
>>> I know everyone says "they all work" but i'd like some recommendations on
>>>MP machines for -CURRENT work. I'll be ordering one this week.
>>>
>>Th
On a second thought, how does it accumulate 870megs of wired memory on a
box that has only 512megs and the swap file hasn't even been touched?
Maybe there's just a profiling counter boken?
Or do I misinterpret the concept of wired memory?
Anyway, cheers,
-mg
> 4th July 5pm CET, with world and
that was teh plan... we're just discussing the name..
TAILQ_FOREACH_SAFE ?
On Thu, 4 Jul 2002, Daniel Eischen wrote:
> On Wed, 3 Jul 2002, Julian Elischer wrote:
> > On Wed, 3 Jul 2002, Neal Fachan wrote:
> >
> > > We've got local changes (which I've attached) where the name is
> > > *_FOREACH_
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
In article
[EMAIL PROTECTED]> you
write:
>in RELENG_4, when one calls callout_stop() (not nested in softclock execute
>path
>, I am not talking about this case), after it returns, he can believe that the
>callout is truely stopped, however in CURRENT, this assumption is false, now we
>
>must car
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
Julian Elischer wrote:
> I've tracked it down to my losing 1 page for every thread that is started.
>
> if I start a process with 6 threads, I lose 6 x 4k.
> if I start a single threaded process I lose 4k.
The problem seems fixed at this end after the vm_glue update from today,
July 4. Thanks!
On Thu, Jul 04, 2002 at 09:20:38AM -0500, Richard Seaman, Jr. wrote:
> On Tue, Jul 02, 2002 at 06:04:36PM -0700, Joel M. Baldwin wrote:
> >
> >
> > Something has messed up natd. If I don't have the
> > punch_fw option in the /etc/natd.conf file it eventuially
> > core dumps with a bus error. I
After the change to vm_glue.c the problem seems to be gone ...
--
Any time things appear to be going better, you have overlooked
something.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
On Tue, Jul 02, 2002 at 06:04:36PM -0700, Joel M. Baldwin wrote:
>
>
> Something has messed up natd. If I don't have the
> punch_fw option in the /etc/natd.conf file it eventuially
> core dumps with a bus error. I think this started JUST
> BEFORE the KSE commit.
Yes, I've seen the same thing
> try a new vm_glue.c as well.
> ( 1.140)
Yes, this works. Thanks!
Marc
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
George V. Neville-Neil writes:
> Hi,
>
> I know everyone says "they all work" but i'd like some recommendations on
> MP machines for -CURRENT work. I'll be ordering one this week.
>
I'm in the market for a new SMP x86 workstation to replace my aging
alpha desktop.
What's the state
> 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
Sorry to answer myself, but after a bit of free time to reflect on
this, I may as well talk back at myself. I wrote:
> Am I the only one getting duplicated #include lines in the generated
> ioctl.c file, created as part of building usr.bin/kdump?
YES!
> 27 #include
> 28 #include
On Wed, 3 Jul 2002, Julian Elischer wrote:
> On Wed, 3 Jul 2002, Neal Fachan wrote:
>
> > We've got local changes (which I've attached) where the name is
> > *_FOREACH_REMOVE. We didn't add reverse removable iterators. Also, the
> > temp variable is the second argument. I can't think of a way of
Chuck Robey writes:
>
> The main difference in the updated chipset is the fact that the 64 bit PCI
> slots now run at double-speed, giving double the throughput. No change
Most motherboards which support 64-bit/66MHz PCI slots can't run them
anywhere near the theoretical limit. So its more
in RELENG_4, when one calls callout_stop() (not nested in softclock execute
path
, I am not talking about this case), after it returns, he can believe that the
callout is truely stopped, however in CURRENT, this assumption is false, now we
must care if callout_stop() truely stopped the callout wh
My analysis was finished. Please try this patch.
--- exfield.c- Thu Jul 4 21:54:24 2002
+++ exfield.c Thu Jul 4 21:55:02 2002
@@ -200,7 +200,7 @@
/* Handle both ACPI 1.0 and ACPI 2.0 Integer widths */
IntegerSize = sizeof (ACPI_INTEGER);
-if (WalkState->MethodNode->Flags & A
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
try a new vm_glue.c as well.
( 1.140)
On Thu, 4 Jul 2002, Julian Elischer wrote:
> what do you call "today's" ?
> (version #?)
>
>
>
> On 4 Jul 2002, Marc Recht wrote:
>
> > Hi!
> >
> > I got this with today's pmap
> > panic: pmap_new_thread: kstack allocation failed
> >
> > Yesterday's
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
> what do you call "today's" ?
Oops, sorry.. I know I missed something.. :-)
> (version #?)
src/sys/i386/i386/pmap.c,v 1.331 2002/07/04 00:35:48
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
what do you call "today's" ?
(version #?)
On 4 Jul 2002, Marc Recht wrote:
> Hi!
>
> I got this with today's pmap
> panic: pmap_new_thread: kstack allocation failed
>
> Yesterday's kernel works fine.
>
>
> Marc
>
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe f
Fixed a few minutes ago.
On Thu, Jul 04, 2002 at 02:12:39AM -0400, Munish Chopra wrote:
> Sources checked out today, 3AM EST.
>
> makeinfo --no-validate -I
> /usr/src/gnu/usr.bin/binutils/doc/../../../../contrib/binutils/gas/doc
> -I /usr/src/gnu/usr.bin/binutils/doc/../../../../contrib/binutils
I may be fixed. but there's a memory leak still.
reboot when your wired coun gets too high.
On Thu, 4 Jul 2002, Christopher Sharp wrote:
> Hello,
> with a world+kernel from yesterday I get this message
> and then the machine freezes and/or reboots.
>
> Any Ideas ? is this already fixed ?
>
>
On 3 Jul, Peter Wemm wrote:
> Chuck Robey wrote:
>> On Wed, 3 Jul 2002, David O'Brien wrote:
>>
>> > On Wed, Jul 03, 2002 at 07:43:22PM -0700, George V. Neville-Neil wrote:
>> > > I know everyone says "they all work" but i'd like some recommendations
> on
>> > > MP machines for -CURRENT wo
On Thu, 4 Jul 2002, Greg 'groggy' Lehey wrote:
> I don't know enough about GEOM to embrace it whole-heartedly, but I
> think you'd be hard pressed to find anybody who disagrees that devfs
> is a forward. It may need some improvement, but it's so much more
> logical than what we had before that I
Hi,
I got this panic with -current of date=2002.06.27.22.00.00. It reminds
me of another panic that I had recently with a -current of 25-June, the
message of that earlier incident was "panic: Most recently used by
routetbl".
hunter[7]$ gdb -k /boot/kernel/kernel vmcore.26
GNU gdb 4.18 (
On Thu, 4 Jul 2002, David Xu wrote:
> - Original Message -
> From: "Julian Elischer" <[EMAIL PROTECTED]>
> To: "David Xu" <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>
> Sent: Thursday, July 04, 2002 4:36 PM
> Subject: Re: Timeout and SMP race
> >
> > On Thu, 4 Jul 2002, David Xu wrote:
>
Hi!
I got this with today's pmap
panic: pmap_new_thread: kstack allocation failed
Yesterday's kernel works fine.
Marc
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
On Wed, 3 Jul 2002, Terry Lambert wrote:
> Bruce Evans wrote:
> > On Wed, 3 Jul 2002, Poul-Henning Kamp wrote:
> > > Some bits are missing yet, for instance the ioctls to change
> > > disklabels etc. when they're done and it works also with sysinstall
> > > it'll be standard.
> >
> > It shouldn'
Greg 'groggy' Lehey wrote:
On Thursday, 4 July 2002 at 19:20:00 +1000, Bruce Evans wrote:
On Wed, 3 Jul 2002, Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED]"><[EMAIL PROTECTED]>, Bruce Evans writes:
This is mostly because resources hav
Hello,
with a world+kernel from yesterday I get this message
and then the machine freezes and/or reboots.
Any Ideas ? is this already fixed ?
Christopher Sharp
--
Any time things appear to be going better, you have overlooked
something.
To Unsubscribe: send mail to [EMAIL PROTECTED]
w
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 Thursday, 4 July 2002 at 19:20:00 +1000, Bruce Evans wrote:
> On Wed, 3 Jul 2002, Poul-Henning Kamp wrote:
>
>> In message <[EMAIL PROTECTED]>, Bruce Evans writes:
>>> This is mostly because resources have been diverted away from updating
>>> working code to write a second system.
>>
>> Make t
On Wed, 3 Jul 2002, Poul-Henning Kamp wrote:
> In message <[EMAIL PROTECTED]>, Bruce Evans writes:
> >This is mostly because resources have been diverted away from updating
> >working code to write a second system.
>
> Make that third system, the current slice/label code is our second
> system, a
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
- Original Message -
From: "Julian Elischer" <[EMAIL PROTECTED]>
To: "David Xu" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Thursday, July 04, 2002 4:36 PM
Subject: Re: Timeout and SMP race
>
>
> On Thu, 4 Jul 2002, David Xu wrote:
>
> > while we are getting rid of Giant, cur
On Thu, 4 Jul 2002, David Xu wrote:
> while we are getting rid of Giant, current race condition between softclock()
> and callout_stop() is unacceptable. the race causes two many places in source
> code would be modified to fit this new behaviour, besides this, everywhere
> callout_stop() is
I've tracked it down to my losing 1 page for every thread that is started.
if I start a process with 6 threads, I lose 6 x 4k.
if I start a single threaded process I lose 4k.
well, that's a start.. it narrows it down quite a bit :-)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsub
58 matches
Mail list logo
