Re: panic: kmem_malloc(4096): kmem_map too small
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 partition which is on a scsi
> disk behind a Adaptec 2940 controller. The "huge" tar file contains a
> ...
> Here follow the output of vinum list and then the panic message and
> a gdb traceback. I'm not sure if the traceback is correct. I think
> it only show the second panic.
It shows mainly bugs in the debugging :-[.
> panic: free locked buf
Debugging bug 1:
The above shows a secondary panic, but is supposed to show the primary
panic. gdb just prints the contents of the kernel panicstr variable,
but the setting of that variable is broken (see below).
> panic messages:
> ---
> panic: kmem_malloc(4096): kmem_map too small: 28610560 total allocated
>
> syncing disks, buffers remaining... panic: free locked buf
> Uptime: 1h47m5s
> (da0:ahc0:0:6:0): SYNCHRONIZE CACHE. CDB: 35 0 0 0 0 0 0 0 0 0
> (da0:ahc0:0:6:0): error code 54
> Dumping 64 MB
> ata0: resetting devices ..
> done
> 16 32 48
> ---
Debugging bug 2:
gdb then prints the contents of the message buffer starting with the
regexp "^(panic:|Fatal trap) ". It just uses system("dmesg ... | awk ...").
Eeek. This may start with a panic for a previous boot and print all
messages in the buffer for subsequent boots. This doesn't happen here.
> Reading symbols from
> /usr/src/sys/i386/compile/TRY/modules/usr/src/sys/modules/vinum/vinum.ko.debug...done.
> Loaded symbols for
> /usr/src/sys/i386/compile/TRY/modules/usr/src/sys/modules/vinum/vinum.ko.debug
> #0 doadump () at ../../../kern/kern_shutdown.c:238
> 238 dumping++;
> (kgdb) bt
> #0 doadump () at ../../../kern/kern_shutdown.c:238
> #1 0xc01ab1ca in boot (howto=260) at ../../../kern/kern_shutdown.c:370
> #2 0xc01ab483 in panic () at ../../../kern/kern_shutdown.c:543
> #3 0xc1064926 in freerq (rq=0xc166c4c0)
> at /usr/src/sys/dev/vinum/vinuminterrupt.c:252
> #4 0xc106482a in complete_rqe (bp=0xc12a6c24)
> at /usr/src/sys/dev/vinum/vinuminterrupt.c:230
> #5 0xc01eda81 in bufdone (bp=0xc12a6c24) at ../../../kern/vfs_bio.c:3086
> #6 0xc01ed984 in bufdonebio (bp=0x0) at ../../../kern/vfs_bio.c:3034
> #7 0xc01ed7e2 in biodone (bp=0xc12a6c24) at ../../../kern/vfs_bio.c:2961
> #8 0xc017d4be in g_dev_done (bp2=0xc1552120) at ../../../geom/geom_dev.c:391
> #9 0xc01ed7e2 in biodone (bp=0xc1552120) at ../../../kern/vfs_bio.c:2961
> #10 0xc017fc62 in g_io_schedule_up (tp=0xc0607e40)
> at ../../../geom/geom_io.c:365
> #11 0xc017fe58 in g_up_procbody () at ../../../geom/geom_kern.c:91
> #12 0xc01986ce in fork_exit (callout=0xc017fe30 , arg=0x0,
> frame=0x0) at ../../../kern/kern_fork.c:768
> (kgdb) quit
Debugging bug 3:
The primary panic occurred in another thread, and we just got here to
sync() for the other thread. Then we soon paniced with "free locked buf".
Thus there is no trace of the primary panic in this frame and no
secondary or tertiary panics in this frame. freerq() just paniced in
BUF_LOCKFREE() and the panic didn't try syncing again since it is
"recursive" (not actually recursive since it is in a diferent thread).
You need to look at other threads to see where the primary panic occurred.
panic() doesn't understand that it may be called from more than 1 thread
(it shouldn't be), so it doesn't print any hints its callers.
Debugging bug 1 (continued):
The setting of `panicstr' was broken in rev.1.38:
% void
% panic(const char *fmt, ...)
% {
% struct thread *td = curthread;
% int bootopt, newpanic;
% va_list ap;
% static char buf[256];
%
% #ifdef SMP
% ...
% #endif
%
% bootopt = RB_AUTOBOOT | RB_DUMP;
% newpanic = 0;
% if (panicstr)
% bootopt |= RB_NOSYNC;
% else {
% panicstr = fmt;
^^
This sets panicstr for the original panic only.
% newpanic = 1;
% }
%
% va_start(ap, fmt);
% (void)vsnprintf(buf, sizeof(buf), fmt, ap);
% if (panicstr == fmt)
% panicstr = buf;
^^
This gives a more useful setting of panicstr (rev.1.38). Unfortunately,
it points panicstr at static storage which is clobbered by secondary
panics.
% va_end(ap);
% printf("panic: %s\n", buf);
Bruce
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
panic: kmem_malloc(4096): kmem_map too small
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 a Adaptec 2940 controller. The "huge" tar file contains a "normal user" 5.1 installation plus the 5.1-RELEASE bits from the ftp site, so it is a 320 Meg .tgz. I have played around a bit. It seems to panic a little quicker if the machine have only 32M Ram. I haven't been able to panic it if I do it in a normal, non-vinum partition. I don't know if vinum is at fault though, it might just help to agravate the situation. Here follow the output of vinum list and then the panic message and a gdb traceback. I'm not sure if the traceback is correct. I think it only show the second panic. John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] The output of vinum list: ### 1 drives: D vd0 State: up /dev/da0s1d A: 0/966 MB (0%) 1 volumes: V root State: up Plexes: 1 Size:966 MB 1 plexes: P root.p0 C State: up Subdisks: 1 Size:966 MB 1 subdisks: S root.p0.s0State: up D: vd0 Size:966 MB ### GNU gdb 5.2.1 (FreeBSD) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-undermydesk-freebsd"... panic: free locked buf panic messages: --- panic: kmem_malloc(4096): kmem_map too small: 28610560 total allocated syncing disks, buffers remaining... panic: free locked buf Uptime: 1h47m5s (da0:ahc0:0:6:0): SYNCHRONIZE CACHE. CDB: 35 0 0 0 0 0 0 0 0 0 (da0:ahc0:0:6:0): error code 54 Dumping 64 MB ata0: resetting devices .. done 16 32 48 --- Reading symbols from /usr/src/sys/i386/compile/TRY/modules/usr/src/sys/modules/vinum/vinum.ko.debug...done. Loaded symbols for /usr/src/sys/i386/compile/TRY/modules/usr/src/sys/modules/vinum/vinum.ko.debug #0 doadump () at ../../../kern/kern_shutdown.c:238 238 dumping++; (kgdb) bt #0 doadump () at ../../../kern/kern_shutdown.c:238 #1 0xc01ab1ca in boot (howto=260) at ../../../kern/kern_shutdown.c:370 #2 0xc01ab483 in panic () at ../../../kern/kern_shutdown.c:543 #3 0xc1064926 in freerq (rq=0xc166c4c0) at /usr/src/sys/dev/vinum/vinuminterrupt.c:252 #4 0xc106482a in complete_rqe (bp=0xc12a6c24) at /usr/src/sys/dev/vinum/vinuminterrupt.c:230 #5 0xc01eda81 in bufdone (bp=0xc12a6c24) at ../../../kern/vfs_bio.c:3086 #6 0xc01ed984 in bufdonebio (bp=0x0) at ../../../kern/vfs_bio.c:3034 #7 0xc01ed7e2 in biodone (bp=0xc12a6c24) at ../../../kern/vfs_bio.c:2961 #8 0xc017d4be in g_dev_done (bp2=0xc1552120) at ../../../geom/geom_dev.c:391 #9 0xc01ed7e2 in biodone (bp=0xc1552120) at ../../../kern/vfs_bio.c:2961 #10 0xc017fc62 in g_io_schedule_up (tp=0xc0607e40) at ../../../geom/geom_io.c:365 #11 0xc017fe58 in g_up_procbody () at ../../../geom/geom_kern.c:91 #12 0xc01986ce in fork_exit (callout=0xc017fe30 , arg=0x0, frame=0x0) at ../../../kern/kern_fork.c:768 (kgdb) quit ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: panic with panic: kmem_malloc(4096): kmem_map too small...
[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 set it to the same value as used for 2G (appros 13), I phk> think your machine should survive with 3G RAM. Thank you for the clarification. I notice that the panic happens when numvnodes becomes more than about 185000. When kern.maxvnodes=13 (198799 by default) is specified, the system works fine under heavy loads during this week. Is anyone else suffering from it? If it happens on all of >2GB systems, I think it should be solved (or described in relnotes) before the release. -- | Hiroki SATO <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic with panic: kmem_malloc(4096): kmem_map too small...
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 this size of spare space such a large threshold really required?? > >And IF i would like to experiment, where do I look for the knop to turn?? > > Basically you don't need to reserve anything, but as you get closer to > filling the disk the time to find a free space increases rapidly and > your files get very fragmented. Trouble is: they never get defragmented > unless you copy them (or do a full dump/restore). > > I'm not sure how to nail the "right" number of % down, and I'm sure > that both Kirk and I would like to hear your numbers :-) If someone is interested in investigating this in detail, Margo Setzer et alii did a study a few years ago on aging filesystems in order to measure fragmentation. Their intent was not to measure the effect of free space on fragmentation, but their methodology could be applied for that purpose. They happen to have a graph that suggests that large file throughput drops about 20% for a filesystem that is 75% full versus a nearly empty filesystem. http://www.eecs.harvard.edu/~vino/fs-perf/papers/sigmetrics.ps.gz I don't think you'll find that it's a good idea to have a filesystem more than 90% full. At that load factor, even a uniform hash will take on average 2.5 probes to locate free space, and performance can only exponentially decrease from there. No filesystem can avoid fragmentation and perform well without a bit of breathing room. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic with panic: kmem_malloc(4096): kmem_map too small...
> 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 bandwidth.
>
> > I'm not sure how to nail the "right" number of % down, and I'm sure
> > that both Kirk and I would like to hear your numbers :-)
>
> I postprocess output from Kirk's block number printing program to
> produce fragmentation estimates. All (non-null) seeks are considered
> to be fragmentation. A (logical) non-null seek seems to be normal for
> about 10% of (logical) i/o's even in the favourable case of files
> created by copying to an initially empty filesystem (this is for
> small files like the ones in FreeBSD's src tree).
I'd be interested in that block number printing program too
After some discussion offline with Poul-Henning that was exactly what is one of the
basic needs to do any analysis in this area:
A way to determing a fragmentation degree/index.
Poul suggested then bean-counting in fsck, so I started looking there. But the 'block
number printing' would generate even better data.
I'm building a system just for running some of these test on it.
Feel free to suggest or discuss the approach.
--WjW
èR{.nÇ+·¬zwfj)m¢f£¢·hkyàRàÂ+aº{.nÇ+·ç±×.®·§¶)í
æèw* ¶¦zË
Re: panic with panic: kmem_malloc(4096): kmem_map too small...
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 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 this size of spare space such a large threshold really required?? > >And IF i would like to experiment, where do I look for the knop to turn?? > > Basically you don't need to reserve anything, but as you get closer to > filling the disk the time to find a free space increases rapidly and > your files get very fragmented. Trouble is: they never get defragmented > unless you copy them (or do a full dump/restore). 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 bandwidth. > I'm not sure how to nail the "right" number of % down, and I'm sure > that both Kirk and I would like to hear your numbers :-) I postprocess output from Kirk's block number printing program to produce fragmentation estimates. All (non-null) seeks are considered to be fragmentation. A (logical) non-null seek seems to be normal for about 10% of (logical) i/o's even in the favourable case of files created by copying to an initially empty filesystem (this is for small files like the ones in FreeBSD's src tree). Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic with panic: kmem_malloc(4096): kmem_map too small...
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. >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 this size of spare space such a large threshold really required?? >And IF i would like to experiment, where do I look for the knop to turn?? Basically you don't need to reserve anything, but as you get closer to filling the disk the time to find a free space increases rapidly and your files get very fragmented. Trouble is: they never get defragmented unless you copy them (or do a full dump/restore). I'm not sure how to nail the "right" number of % down, and I'm sure that both Kirk and I would like to hear your numbers :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic with panic: kmem_malloc(4096): kmem_map too small...
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. tunefs lets me bring that down to 5% = 8,5Gb without speed penalty. But is for this size of spare space such a large threshold really required?? And IF i would like to experiment, where do I look for the knop to turn?? Thanx for the support, --WjW > 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 mean? Is something leaking in the kernel. > >IF so how do I help it go away. > > > >I'm copy 100G from a W2K system to my vinum file server with a 170G raid5. > >Current is as of 28 dec... > > Please try to move up to current as of today. On Dec 29th I commited > code to make the desiredvnodes a limit rather than a vague suggestion > and that should solve your problem I hope. > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > [EMAIL PROTECTED] | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. > > ¡Iì¹» ®&Þ±éݨ¥¶Ý¢jçH:+éì¹» ®&Þ~·nÇ\ººÞا¶¡Ü¨~Ø^ë,j
Re: panic with panic: kmem_malloc(4096): kmem_map too small...
[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 option, > > the panic disappears (but I don't know why...). > > Now that's different from the previous poster. > > The problem in this case is that some of the system constants are sized > based on the amount of RAM and appearantly we do this wrong for large > RAM configurations. > > I only have 2G ram and that's what I have tested (extensively). If we're > still broken for >2G ram, somebody needs to revist this. > > One thing you can try is reduce the value of the > sysctl kern.maxvnodes > > If you set it to the same value as used for 2G (appros 13), I > think your machine should survive with 3G RAM. You can also increase the maximum number of open files, which will cause the number to be scaled larger. You can do this in the boot loader (e.g. loader.rc). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic with panic: kmem_malloc(4096): kmem_map too small...
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 why...). Because the kmem map is a fixed segment of virtual space for which page mappings are established, and adding more memory increases the amount of page mappings required, without increasing the space available for the mappings. It is not something which can be easily tuned automatically. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: VM page queue mutex not locked panic (WAS:Re: panic with panic: kmem_malloc(4096): kmem_map too small... )
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 screen] > >Is this related, our should this start a new thread? This is unrelated I think, and sounds like some of the stuff alc@ is working on. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
VM page queue mutex not locked panic (WAS:Re: panic with panic: kmem_malloc(4096): kmem_map too small... )
> 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 mean? Is something leaking in the kernel.
> >IF so how do I help it go away.
> >
> >I'm copy 100G from a W2K system to my vinum file server with a 170G raid5.
> >Current is as of 28 dec...
>
> Please try to move up to current as of today. On Dec 29th I commited
> code to make the desiredvnodes a limit rather than a vague suggestion
> and that should solve your problem I hope.
It seams easy to repeat, AND I haven't copied the whole disk yet.
So there plenty test material. I'll keep you posted.
Today means European saturday during the day? (I'm auto-build everything, cvsup-ing at
6:00)
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 screen]
Is this related, our should this start a new thread?
--WjW
èR{.nÇ+·¬zwfj)m¢f£¢·hkyàRàÂ+aº{.nÇ+·ç±×.®·§¶)í
æèw* ¶¦zË
Re: panic with panic: kmem_malloc(4096): kmem_map too small...
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 disappears (but I don't know why...). Now that's different from the previous poster. The problem in this case is that some of the system constants are sized based on the amount of RAM and appearantly we do this wrong for large RAM configurations. I only have 2G ram and that's what I have tested (extensively). If we're still broken for >2G ram, somebody needs to revist this. One thing you can try is reduce the value of the sysctl kern.maxvnodes If you set it to the same value as used for 2G (appros 13), I think your machine should survive with 3G RAM. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic with panic: kmem_malloc(4096): kmem_map too small...
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 I've foun little extra info in the archive. phk> > phk> >What dows this actually mean? Is something leaking in the kernel. phk> >IF so how do I help it go away. phk> > phk> >I'm copy 100G from a W2K system to my vinum file server with a 170G raid5. phk> >Current is as of 28 dec... phk> phk> Please try to move up to current as of today. On Dec 29th I commited phk> code to make the desiredvnodes a limit rather than a vague suggestion phk> and that should solve your problem I hope. 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 why...). -- | Hiroki SATO <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic with panic: kmem_malloc(4096): kmem_map too small...
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 mean? Is something leaking in the kernel. >IF so how do I help it go away. > >I'm copy 100G from a W2K system to my vinum file server with a 170G raid5. >Current is as of 28 dec... Please try to move up to current as of today. On Dec 29th I commited code to make the desiredvnodes a limit rather than a vague suggestion and that should solve your problem I hope. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
panic with panic: kmem_malloc(4096): kmem_map too small...
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.
I'm copy 100G from a W2K system to my vinum file server with a 170G raid5.
Current is as of 28 dec...
System has 96Mb and runs on a P-II 200Mhz/realtek ethernet.
It just runs: kernel/nfs/ssh/samba/sendmail
The other problem the system suffers from is running a backgrounded fsck on
the vinum raid. That is a shure way to freeze the system.
Running it in the forground always works fine. So that problem could be the one that
was discussed on the list before??
Regards,
--WjW
N
'²æìr¸zǧvf¢Ú&j:+v¨· è® "¶§²æìr¸yúÞy» rêëz{bØ^nr¡ûazg¬±¨
Re: Kernel panic with panic: kmem_malloc(4096): kmem_map too small...
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. > > jroberson> How much memory is in this machine? What are you using it > jroberson> for? > > It has 256MB memory, and is used for 5-current release buildbox. > I suspect that there is some other bug then. 1/2 of your memory should not be consumed by kernel malloc. Do you have an abnormally large MD or something? Jeff To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel panic with panic: kmem_malloc(4096): kmem_map too small...
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 the same. What am I > missing something? > You are using 100mb of KVA for malloc(9)? Are you certain that you don't have a memory leak? How much memory is in this machine? What are you using it for? Thanks! Jeff To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel panic with panic: kmem_malloc(4096): kmem_map too small...
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 > missing something? This was recently discussed on -current. I posted a dumb patch that "fixes" the problem. Jeff Roberson is looking at fixing the problem "the right way" right now. Until then, though, you can still use my patch (it makes UMA use kmem_alloc_wait, instead of kmem_malloc). See the archive of the posting, for more details: <http://docs.freebsd.org/cgi/getmsg.cgi?fetch=1612532+0+archive/2002/freebsd-current/20021013.freebsd-current> -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Kernel panic with panic: kmem_malloc(4096): kmem_map too small...
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' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: kmem_malloc(4096): kmem_map too small
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 cvsupped/rebuilt 5 Oct, but it's only up for 14 hours. In any case, here's my dmesg. Also note the 'could sleep' warnings for if_xl. They have been there for over half a year I think. I've reported them before. There's also a duplicate lock in udp_usrreq that's new to me. 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. All rights reserved. FreeBSD 5.0-CURRENT #5: Sun Oct 6 01:50:54 CEST 2002 [EMAIL PROTECTED]:/var/obj/usr/src/sys/TERMINUS Preloaded elf kernel "/boot/kernel/kernel" at 0xc04dc000. Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 233865126 Hz CPU: Pentium II/Pentium II Xeon/Celeron (233.87-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x634 Stepping = 4 Features=0x80f9ff real memory = 67108864 (65536K bytes) avail memory = 59920384 (58516K bytes) Pentium Pro MTRR support enabled npx0: on motherboard npx0: INT 16 interface Using $PIR table, 6 entries at 0xc00fdc00 pcib0: at pcibus 0 on motherboard pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0xf000-0xf00f at device 7.1 on pci0 atapci0: Busmastering DMA not supported ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: port 0x6400-0x641f irq 11 at device 7.2 on pci0 usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered pci0: at device 7.3 (no driver attached) sym0: <875> port 0x6800-0x68ff mem 0xe800-0xe8000fff,0xe8001000-0xe80010ff irq 12 at device 11.0 on pci0 sym0: Symbios NVRAM, ID 7, Fast-20, SE, parity checking sym0: open drain IRQ line driver, using on-chip SRAM sym0: using LOAD/STORE-based firmware. xl0: <3Com 3c905-TX Fast Etherlink XL> port 0x6c00-0x6c3f irq 9 at device 13.0 on pci0 /usr/src/sys/vm/uma_core.c:1307: could sleep with "xl0" locked from /usr/src/sys/pci/if_xl.c:1264 /usr/src/sys/vm/uma_core.c:1307: could sleep with "xl0" locked from /usr/src/sys/pci/if_xl.c:1264 lock order reversal 1st 0xc0ba1bd4 xl0 (network driver) @ /usr/src/sys/pci/if_xl.c:1264 2nd 0xc03d2b00 allproc (allproc) @ /usr/src/sys/kern/kern_fork.c:318 /usr/src/sys/vm/uma_core.c:1307: could sleep with "xl0" locked from /usr/src/sys/pci/if_xl.c:1264 /usr/src/sys/vm/uma_core.c:1307: could sleep with "xl0" locked from /usr/src/sys/pci/if_xl.c:1264 /usr/src/sys/vm/uma_core.c:1307: could sleep with "xl0" locked from /usr/src/sys/pci/if_xl.c:1264 xl0: Ethernet address: 00:60:08:a5:d4:ff miibus0: on xl0 nsphy0: on miibus0 nsphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto /usr/src/sys/vm/uma_core.c:1307: could sleep with "xl0" locked from /usr/src/sys/pci/if_xl.c:647 pci0: at device 15.0 (no driver attached) orm0: at iomem 0xc8000-0xcbfff,0xc-0xc7fff on isa0 atkbdc0: at port 0x64,0x60 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 fdc0: at port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode lpt0: on ppbus0 lpt0: Interrupt-driven port sc0: on isa0 sc0: VGA <16 virtual consoles, flags=0x200> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 unknown: can't assign resources (port) unknown: can't assign resources (port) unknown: can't assign resources (port) unknown: can't assign resources (port) unknown: can't assign resources (port) Timecounters tick every 10.000 msec ipfw2 initialized, divert enabled, rule-based forwarding enabled, default to deny, logging unlimited Waiting 5 seconds for SCSI devices to settle (noperiph:sym0:0:-1:-1): SCSI BUS reset delivered. Mounting root from ufs:/dev/da0s1a da2 at sym0 bus 0 target 3 lun 0 da2: Fixed Direct Access SCSI-2 device da2: 20.000MB/s transfers (20.000MHz, offset 15), Tagged Queueing Enabled da2: 3067MB (6281856 512 byte sectors: 255H 63S/T 391C) da1 at sym0 bus 0 target 2 lun 0 da1: Fixed Direct Access SCSI-2 device da1: 20.000MB/s transfers (20.000MHz, offset 15), Tagged Queueing Enabled da1: 3090MB (6328861 512 byte sectors: 255H 63S/T 393C) da0 at sym0 bus 0 target 1 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 40.000MB/s transfers (20.000MHz, offset 15, 16bit) da0: 4134MB (8467200 512 byte sectors: 255H 63S/T 527C) acquiring duplicate lock of same type: "inp" 1st inp @ /usr/src/sys/netinet/udp_usrreq.c:288 2nd inp @
Re: panic: kmem_malloc(4096): kmem_map too small
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, which seems to be suffering because all its > memory is real... > > BTW, what happened to the NO_SWAPPING kernel option? Nothing. I always use it, and it just works. Note that it only disables swapping (of UPAGES) and has little effect on paging to swap, and was never intended to. This is is documented very clearly in cvs history and very unclearly in NOTES: %%% RCS file: /home/ncvs/src/sys/vm/vm_glue.c,v Working file: vm_glue.c head: 1.157 ... revision 1.39 date: 1996/02/22 10:57:36; author: davidg; state: Exp; lines: +4 -3 Add a "NO_SWAPPING" option to disable swapping. This was originally done to help diagnose a problem on wcarchive (where the kernel stack was sometimes not present), but is useful in its own right since swapping actually reduces performance on some systems (such as wcarchive). Note: swapping in this context means making the U pages pageable and has nothing to do with generic VM paging, which is unaffected by this option. Reviewed by: NOTES: ... # # Disable swapping. This option removes all code which actually performs # swapping, so it's not possible to turn it back on at run-time. # # This is sometimes usable for systems which don't have any swap space # (see also sysctls "vm.defer_swapspace_pageouts" and # "vm.disable_swapspace_pageouts") # #!options NO_SWAPPING %%% I doubt that swapping is useful for many systems that are newer than the commit that added NO_SWAPPING. If there aren't many processes then swapping doesn't do much, and if there are a lot of processes (as on wcarchive), then you don't want to swap. The memory for the UPAGES of wcarchive's 1500 (?) processes was a whole 12MB. Much larger number of processes are common now, but memories are larger too. Work is under weigh (sic) to bloat the number of UPAGES (including kernel stack pages) and the number of processes (there are almost 100 in the kernel alone now), but hopefully it won't progress as fast as memories grow. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: kmem_malloc(4096): kmem_map too small
îÅĦÌÑ 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, this is my laptop :-) > did you get a backtrace ? . . . to vfs allocations > . . . and a second panic on syncing disks ? 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, which seems to be suffering because all its memory is real... BTW, what happened to the NO_SWAPPING kernel option? -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: kmem_malloc(4096): kmem_map too small
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 second panic on syncing disks ? -- t t z msg44097/pgp0.pgp Description: PGP signature
panic: kmem_malloc(4096): kmem_map too small
... 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
