On Thu, 10 Jul 2003, Bosko Milekic wrote:
> But for now the only advice I have is that you tune the boot-time
> kern.vm.kmem.size tunable. Don't set it too high, but you can try about
> 250,000 for your configuration. The constant we have that caps the size
> is getting too small and we're at le
Sorry for the top-reply...
But for now the only advice I have is that you tune the boot-time
kern.vm.kmem.size tunable. Don't set it too high, but you can try about
250,000 for your configuration. The constant we have that caps the size
is getting too small and we're at least going to have to b
Hi,
we are currently stress-testing two 5.1 machines. Each of the machines
have a 2.6GHz P4 and 512 MB RAM. The machines are running zebra, ospfd and
nscd. We bomb the machines with many DNS requests (up to 50k/s),
transmitted over Gigabit Ethernet.
Unfortunately, both machines panic soon after s
On Fri, 13 Jun 2003, John Hay wrote:
> On a 5.1-RELEASE machine I have been able to cause a panic like this:
>
> panic: kmem_malloc(4096): kmem_map too small: 28610560 total allocated
>
> The machine is an old 300MHz Celeron with 64M Ram. I get the panic by
> un-taring a "
Hi,
On a 5.1-RELEASE machine I have been able to cause a panic like this:
panic: kmem_malloc(4096): kmem_map too small: 28610560 total allocated
The machine is an old 300MHz Celeron with 64M Ram. I get the panic by
un-taring a "huge" .tgz file onto a vinum partition which is on a
[EMAIL PROTECTED] wrote
in <[EMAIL PROTECTED]>:
phk> I only have 2G ram and that's what I have tested (extensively). If we're
phk> still broken for >2G ram, somebody needs to revist this.
phk>
phk> One thing you can try is reduce the value of the
phk>sysctl kern.maxvnodes
phk>
phk> If you
Thus spake [EMAIL PROTECTED] <[EMAIL PROTECTED]>:
> >And to that fact I have a question:
> >At the moment 8% of the disk is reserved.
> >It being a 170Gb raid, that wastes a good 13,6Gb, which I find at lot.
> >tunefs lets me bring that down to 5% = 8,5Gb without speed penalty.
> >
> File get quite fragmented (enough to lose a factor of 2 or so of the
> disk's bandwidth) even when the disk is almost empty. Then they don't
> get defragmented unless you copy them, etc. The Real Fragmentation
> that occurs when a disk is nearly full loses a much larger factor of
> the disk
On Tue, 7 Jan 2003 [EMAIL PROTECTED] wrote:
> In message <01e701c2b62b$db07ddd0$471b3dd4@dual>, "Willem Jan Withagen" writes:
> >I was able to copy the full 100+Gb.
> >Next I'm going to try and fill the disk to the max as user, but i guess it'll not
>trigger this bug.
> >
> >And to that fact I ha
In message <01e701c2b62b$db07ddd0$471b3dd4@dual>, "Willem Jan Withagen" writes:
>I was able to copy the full 100+Gb.
>Next I'm going to try and fill the disk to the max as user, but i guess it'll not
>trigger this bug.
>
>And to that fact I have a question:
>At the moment 8% of the disk is res
I was able to copy the full 100+Gb.
Next I'm going to try and fill the disk to the max as user, but i guess it'll not
trigger this bug.
And to that fact I have a question:
At the moment 8% of the disk is reserved.
It being a 170Gb raid, that wastes a good 13,6Gb, which I find at lot
[EMAIL PROTECTED] wrote:
> In message <[EMAIL PROTECTED]>, Hiroki Sato writes:
> > I also had "kmem_malloc(4096): kmem_map too small: 275378176 total allocated"
> > several times on -current as of Jan 4th. My -current box has 3GB memory,
> > but when the memory size is explicitly specified as 2GB
Hiroki Sato wrote:
> I also had "kmem_malloc(4096): kmem_map too small: 275378176 total allocated"
> several times on -current as of Jan 4th. My -current box has 3GB memory,
> but when the memory size is explicitly specified as 2GB via MAXMEM option,
> the panic disappears (but I don't know wh
In message <051f01c2b42e$e4651400$471b3dd4@dual>, "Willem Jan Withagen" writes:
>But the following question is alrady there.
>When I woke up this morning I found my box with a double panic:
>lock (sleep mutex) VM page queue mutex not locked @
>/usr/src/sys/kern/vf
>[the remainder was not o
> In message <03a701c2b38c$8e3ad990$471b3dd4@dual>, "Willem Jan Withagen" writes:
> >Which seems a problem sticking up it's head once so often.
> >I had it happen to me now 3 times over the last day. It just drops into the
>debugger.
> >And I've foun little extra info in the archive.
> >
> >W
In message <[EMAIL PROTECTED]>, Hiroki Sato writes:
> I also had "kmem_malloc(4096): kmem_map too small: 275378176 total allocated"
> several times on -current as of Jan 4th. My -current box has 3GB memory,
> but when the memory size is explicitly specified as 2GB via MAXMEM option,
> the panic d
Hi,
[EMAIL PROTECTED] wrote
in <[EMAIL PROTECTED]>:
phk> In message <03a701c2b38c$8e3ad990$471b3dd4@dual>, "Willem Jan Withagen" writes:
phk> >Which seems a problem sticking up it's head once so often.
phk> >I had it happen to me now 3 times over the last day. It just drops into the
debugger.
In message <03a701c2b38c$8e3ad990$471b3dd4@dual>, "Willem Jan Withagen" writes:
>Which seems a problem sticking up it's head once so often.
>I had it happen to me now 3 times over the last day. It just drops into the debugger.
>And I've foun little extra info in the archive.
>
>What dows this actua
Which seems a problem sticking up it's head once so often.
I had it happen to me now 3 times over the last day. It just drops into the debugger.
And I've foun little extra info in the archive.
What dows this actually mean? Is something leaking in the kernel.
IF so how do I help it go away.
In message: <[EMAIL PROTECTED]>
Terry Lambert <[EMAIL PROTECTED]> writes:
: "M. Warner Losh" wrote:
: > : > : + if (sops)
: > : > : + free(sops, M_SEM);
: > : >
: > : > The kernel free() groks free(NULL, M_FOO), so the if isn't needed.
: > :
: > : Wow. That's bogus. It
"M. Warner Losh" wrote:
> : > : + if (sops)
> : > : + free(sops, M_SEM);
> : >
> : > The kernel free() groks free(NULL, M_FOO), so the if isn't needed.
> :
> : Wow. That's bogus. It should panic.
>
> It isn't bogus. free(NULL) is defined to be OK in ansi-c. The kernel
> just mi
* Ben Stuyts <[EMAIL PROTECTED]> [021019 07:16] wrote:
> At 13:34 19/10/2002, Ben Stuyts wrote:
> >At 04:15 19/10/2002, Alfred Perlstein wrote:
> >>* Jake Burkholder <[EMAIL PROTECTED]> [021018 18:26] wrote:
> >>> semop() leaks memory. An important free() was removed by alfred in
> >>> rev 1.55.
At 13:34 19/10/2002, Ben Stuyts wrote:
At 04:15 19/10/2002, Alfred Perlstein wrote:
* Jake Burkholder <[EMAIL PROTECTED]> [021018 18:26] wrote:
> semop() leaks memory. An important free() was removed by alfred in
> rev 1.55. Try this.
Seriously, I just checked in slightly different fix (based
At 04:15 19/10/2002, Alfred Perlstein wrote:
* Jake Burkholder <[EMAIL PROTECTED]> [021018 18:26] wrote:
> semop() leaks memory. An important free() was removed by alfred in
> rev 1.55. Try this.
Oh' c'mon, isn't MP-safeness a bit more important than a some
little memory leak, ram is cheap! pro
* Jake Burkholder <[EMAIL PROTECTED]> [021018 18:26] wrote:
> semop() leaks memory. An important free() was removed by alfred in
> rev 1.55. Try this.
Oh' c'mon, isn't MP-safeness a bit more important than a some
little memory leak, ram is cheap! processors aren't!
Seriously, I just checked in
Apparently, On Sat, Oct 19, 2002 at 12:19:57AM +0200,
Ben Stuyts said words to the effect of;
> Terry,
>
> At 23:07 18/10/2002, you wrote:
> >Ben Stuyts wrote:
> > > Furthermore, this might be interesting: the last vmstat -m log
> > > before the panic. Maybe someone can check if these val
Ben Stuyts wrote:
> >Almost 5.3M of unswappable physical memory dedicated to semaphores
> >seems like a bit much.
>
> Yes, and it increases continuously, for example when I fetch new mail (over
> pop) from my windows pc. The pc stores this again on a network drive, so
> both qpopper and smbd are i
Terry,
At 23:07 18/10/2002, you wrote:
Ben Stuyts wrote:
> Furthermore, this might be interesting: the last vmstat -m log
> before the panic. Maybe someone can check if these values are reasonable?
> The system has 64 MB memory and has been up for about 24 hrs with almost no
> load.
>
This is a repost. Forgive me if you see it twice, but it didn't turn up in
the -current list.
Hi,
Just had another panic, same kmem_malloc(). I did a trace but forgot to
write the traceback down. In any case, there was a semop() call in the
traceback. Furthermore, this might be interesting: th
Some info I did not include in the previous messages:
dmesg output and kernel config.
[terminus.stuyts.nl boot/kernel]26: dmesg
Copyright (c) 1992-2002 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California.
Hello Alfred,
On Wed, Oct 16, 2002 at 02:26:19PM -0700, Alfred Perlstein wrote:
> * Ben Stuyts <[EMAIL PROTECTED]> [021016 14:05] wrote:
> >
> > No need to wait for tomorrow. :-) Just 1.5 hours later, vmstat -m says:
> >
> > < sem167344 2622K 2622K 167344 16,1024,4096
> > ---
> >
* Ben Stuyts <[EMAIL PROTECTED]> [021016 14:05] wrote:
> At 22:00 16/10/2002, Jeff Roberson wrote:
>
> >On Wed, 16 Oct 2002, Ben Stuyts wrote:
> >
> >> I'll also run your vmstat script that you posted in a similar thread. One
> >> of the big memory users seems to be sem, and it's growing. Almost
At 22:00 16/10/2002, Jeff Roberson wrote:
>On Wed, 16 Oct 2002, Ben Stuyts wrote:
>
> > I'll also run your vmstat script that you posted in a similar thread. One
> > of the big memory users seems to be sem, and it's growing. Almost every
> > time I do a vmstat -m, sem usage has grown a few k.
> >
At 21:20 11/10/2002, Terry Lambert wrote:
>Please find a (relatively bogus) patch attached, which could cause
>things to block for a long time, but will avoid the panic.
Terry,
I just got the same panic without your patch. (I wanted to verify that it
was still panic-ing with the latest src tree
On Wed, 16 Oct 2002, Ben Stuyts wrote:
> I just got the same panic without your patch. (I wanted to verify that it
> was still panic-ing with the latest src tree.) I am now building a kernel
> with your patch.
>
> I'll also run your vmstat script that you posted in a similar thread. One
> of the
Makoto Matsushita wrote:
> tlambert2> The worst case failure with my "Ugly patch" should be that
> tlambert2> things hang, and quit running completey.
>
> I've emailed to the list that I've tried your patch but it cannot boot
> (actually it boots, but panics immediately.) Maybe I'm using
> diffe
tlambert2> The worst case failure with my "Ugly patch" should be that
tlambert2> things hang, and quit running completey.
I've emailed to the list that I've tried your patch but it cannot boot
(actually it boots, but panics immediately.) Maybe I'm using
different time of source code. Which 5-c
Makoto Matsushita wrote:
> jroberson> I suspect that there is some other bug then. 1/2 of your
> jroberson> memory should not be consumed by kernel malloc. Do you
> jroberson> have an abnormally large MD or something?
>
> MD devices are used to create installation floppies but no, it should
> b
jroberson> I suspect that there is some other bug then. 1/2 of your
jroberson> memory should not be consumed by kernel malloc. Do you
jroberson> have an abnormally large MD or something?
MD devices are used to create installation floppies but no, it should
be 1.44MB/2.88MB size, relatively sma
On Tue, 15 Oct 2002, Makoto Matsushita wrote:
>
> I'm now trying Terry's patch (just rebuilding a kernel).
>
> jroberson> You are using 100mb of KVA for malloc(9)? Are you certain
> jroberson> that you don't have a memory leak?
>
> Maybe there's a chance of a memory leakage by GLOBAL, but I don
matusita> Thank you, I'll try it right now.
Unfortunately, kernel panics soon after it wakes up... maybe I've
still missed something.
-- -
Makoto `MAR' Matsushita
Booting [/boot/kernel/kernel]...
Copyright (c) 1992-2002 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 199
tlambert2> This was recently discussed on -current. I posted a dumb
tlambert2> patch that "fixes" the problem.
(stuff deleted)
tlambert2> See the archive of the posting, for more details:
Thank you, I'll try it right now.
-- -
Makoto `MAR' Matsushita
To Unsubscribe: send mail to [EMAIL PROTEC
I'm now trying Terry's patch (just rebuilding a kernel).
jroberson> You are using 100mb of KVA for malloc(9)? Are you certain
jroberson> that you don't have a memory leak?
Maybe there's a chance of a memory leakage by GLOBAL, but I don't sure.
jroberson> How much memory is in this machine? W
On Mon, 14 Oct 2002, Makoto Matsushita wrote:
>
> After upgrading my 5-current box (as of late September 2002), the
> kernel panics periodically with following message:
>
> panic: kmem_malloc(4096): kmem_map too small: 107651072 total allocated
>
> The number
Makoto Matsushita wrote:
> After upgrading my 5-current box (as of late September 2002), the
> kernel panics periodically with following message:
>
> panic: kmem_malloc(4096): kmem_map too small: 107651072 total allocated
>
> The number '4096' and '10765107
After upgrading my 5-current box (as of late September 2002), the
kernel panics periodically with following message:
panic: kmem_malloc(4096): kmem_map too small: 107651072 total allocated
The number '4096' and '107651072' is always the same. What am I
missing somethin
Jeff Roberson wrote:
> On Fri, 11 Oct 2002, Terry Lambert wrote:
> > Ben Stuyts wrote:
> > > Is there a way to check the free list of the kernel? Maybe I can find out
> > > what action triggers eating al its memory.
>
> Maybe you should just increase the size of your kmem_map? I'll look into
> a
ut that should do it short term.
>
> ] panic: kmem_malloc(4096): kmem_map too small: 28246016 total allocated.
>
> That's easy: you're calling kmem_malloc() without M_NOWAIT.
>
> That function only operates on the maps kmem_map or mb_map.
>
> It calls vm_m
Ben Stuyts wrote:
> Is there a way to check the free list of the kernel? Maybe I can find out
> what action triggers eating al its memory.
] panic: kmem_malloc(4096): kmem_map too small: 28246016 total allocated.
That's easy: you're calling kmem_malloc() without M_NOWAIT.
Th
At 00:23 11/10/2002, Terry Lambert wrote:
>Robert Watson wrote:
> > I've run into this on a couple of boxes, but those boxes were diskless
> > root boxes, and used md backed ffs for /tmp and /var. Apparently if you
> > do that, you're likely to exceed the kernel's auto-tuned kmem map size.
> > Th
Robert Watson wrote:
> I've run into this on a couple of boxes, but those boxes were diskless
> root boxes, and used md backed ffs for /tmp and /var. Apparently if you
> do that, you're likely to exceed the kernel's auto-tuned kmem map size.
> That said, they didn't do it as frequently, so perhap
At 23:55 10/10/2002, Robert Watson wrote:
>On Thu, 10 Oct 2002, Ben Stuyts wrote:
>
> > panic: kmem_malloc(4096): kmem_map too small: 28246016 total allocated.
>I've run into this on a couple of boxes, but those boxes were diskless
>root boxes, and used md backe
10 Oct 2002, Ben Stuyts wrote:
> Hi,
>
> A couple of days ago I reported a panic, which I just got again:
>
> panic: kmem_malloc(4096): kmem_map too small: 28246016 total allocated.
>
> I don't know where to start looking for this, so I'd appreciate some help.
>
Hi,
A couple of days ago I reported a panic, which I just got again:
panic: kmem_malloc(4096): kmem_map too small: 28246016 total allocated.
I don't know where to start looking for this, so I'd appreciate some help.
This is on a lightly loaded server. I've pasted the dmes
Hello,
At 09:06 06/10/2002, Mikhail Teterin wrote:
>... 218222592 total allocated
>
>this machine has a total of 512Mb of RAM, and no swap.
>No X was running. Just ``cvs update''-ing.
I got this also a couple of times over the last week. It would panic every
few days with this same message. I c
On Mon, 7 Oct 2002, Mikhail Teterin wrote:
> No... With today's kernel, machine has already _frozen_ after swappager
> complained about lack of swap. Rather sad -- a not so uncommon installation
> with 128Mb of memory plus twice that much of swap would still have less
> virtual memory than this b
îÅĦÌÑ 06 öÏ×ÔÅÎØ 2002 03:13 am, n0g0013 ÷É ÎÁÐÉÓÁÌÉ:
> On 06.10-03:06, Mikhail Teterin wrote:
> > this machine has a total of 512Mb of RAM, and no swap.
> > No X was running. Just ``cvs update''-ing.
>
> running vinum ? i am getting this consistently with vinum (but am
> taking an age to rebuild
On 06.10-03:06, Mikhail Teterin wrote:
> this machine has a total of 512Mb of RAM, and no swap.
> No X was running. Just ``cvs update''-ing.
running vinum ? i am getting this consistently with vinum (but am
taking an age to rebuild.
did you get a backtrace ? . . . to vfs allocations
. . . and
... 218222592 total allocated
this machine has a total of 512Mb of RAM, and no swap.
No X was running. Just ``cvs update''-ing.
-mi
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Excellent detective work, thanks. :)
Doug
Original Message
Subject: Re: panic: kmem_malloc(-1077936128): kmem_map too small
Date: Fri, 15 Sep 2000 12:29:01 +0200
From: Mitja Horvat <[EMAIL PROTECTED]>
To: Doug Barton <[EMAIL PROTECTED]>
References: <[
60 matches
Mail list logo
