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 scsi
disk behind
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 huge .tgz file onto a vinum
[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
phksysctl kern.maxvnodes
phk
phk If you set it
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
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 reserved.
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 have a
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's
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.
But is for
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 actually
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.
phk And
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
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
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 on the
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
[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 via MAXMEM
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.
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't sure.
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 something?
-- -
Makoto `MAR
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 '107651072' is always the same. What am I
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 '4096' and '107651072' is always
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
... 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
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 a
îÅĦÌÑ 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.
No,
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 box,
25 matches
Mail list logo
