[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.
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
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
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
>
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'
18 matches
Mail list logo