On Jan 24, 2013, at 1:16, Göran Löwkrantz wrote:
> Search for cam clt kmem in the lists. I had to add
> kern.cam.ctl.disable=1
>
> on a Soekris box with 9.1.
Thanks Göran; that did indeed fix it. Michael Moll sent me the same solution
off-list and a link to
http://freebsd.1045724.n5.nabble.c
tors: 16H 32S/T 980C)
ada0: Previously was known as ad0
Timecounter "TSC" frequency 431653248 Hz quality 800
Root mount waiting for: usbus1 usbus0
uhub0: 4 ports with 4 removable, self powered
Root mount waiting for: usbus1
uhub1: 4 ports with 4 removable, self powered
Trying to mount root fr
Hi everyone,
I upgraded my NanoBSD image from 9.0 (from May 2012) to 9.1 from a few days ago.
Booting the new image on a pcEngines Alix board it panics with a "kmem_map too
small" error when mounting the disk. Any ideas what I'm doing wrong?
Ask
Trying to mount root from u
On Jan 24, 2013, at 0:48, Ask Bjørn Hansen wrote:
> Hi everyone,
>
> I upgraded my NanoBSD image from 9.0 (from May 2012) to 9.1 from a few days
> ago.
>
> Booting the new image on a pcEngines Alix board it panics with a "kmem_map
> too small" error when mou
on 24/09/2010 16:37 Leroy van Logchem said the following:
> On Fri, Sep 24, 2010 at 3:04 PM, Andriy Gapon wrote:
>> On amd64 set your vm.kmem_size to at least the amount of available memory
>> that you
>> got, or even more (1.5x, 2x).
>> An easy way to do that (1x) is to set vm.kmem_size_scale="1
On Fri, Sep 24, 2010 at 3:04 PM, Andriy Gapon wrote:
> On amd64 set your vm.kmem_size to at least the amount of available memory
> that you
> got, or even more (1.5x, 2x).
> An easy way to do that (1x) is to set vm.kmem_size_scale="1".
> In head this is already done automatically, MFC to stable/8
on 24/09/2010 15:33 Jeremy Chadwick said the following:
> As for your questions under "Questions" -- yes you have to tune, no
> there aren't really "reliable guidelines" and I've been asking for such
> since ZFS came out for FreeBSD, but your values look fine.
I can't provide you "reliable" or "au
-
> >> Problem : Kernel panic "kmem_malloc(114688): kmem_map too small
> >> Trigger : Destroy ZFS snapshots (each bigger >80GB)
> >> Version : FreeBSD 8.1-RELEASE (GENERIC AMD64 but with DDB)
> >> ...
> >> panic: kmem_malloc
on 24/09/2010 15:33 Jeremy Chadwick said the following:
> On Fri, Sep 24, 2010 at 01:24:46PM +0200, Leroy van Logchem wrote:
>> -
>> Problem : Kernel panic "kmem_malloc(114688): kmem_map
On Fri, Sep 24, 2010 at 01:24:46PM +0200, Leroy van Logchem wrote:
> -
> Problem : Kernel panic "kmem_malloc(114688): kmem_map too small
> Trigger : Destroy ZFS snapshots (each bigger &g
-
Problem : Kernel panic "kmem_malloc(114688): kmem_map too small
Trigger : Destroy ZFS snapshots (each bigger >80GB)
Version : FreeBSD 8.1-RELEASE (GENERIC AMD64 but with DDB)
Wo
ernel memory (tested on 6.2-R, and 6.4-R):
>>>
>>> db> x/s *panicstr
>>> buf.1: kmem_malloc(4096): kmem_map too small: 335544320 total allocated
>>>
>>> Upping the higher level of vm.kmem_size_max doesn't help much,
>>> postponing tha
ace files quota limit
>> grace
>> /home 6172656 6172672 6172672 14723 0 0
>>
>> Some types of ufs operations running under him lead to kernel
>> panic due to out of kernel memory (tested on 6.2-R, and 6.4-R):
>>
>> db> x/s *
72656 6172672 6172672 14723 0 0
>
> Some types of ufs operations running under him lead to kernel
> panic due to out of kernel memory (tested on 6.2-R, and 6.4-R):
>
> db> x/s *panicstr
> buf.1: kmem_malloc(4096): kmem_map too small: 335544320 total
him lead to kernel
panic due to out of kernel memory (tested on 6.2-R, and 6.4-R):
db> x/s *panicstr
buf.1: kmem_malloc(4096): kmem_map too small: 335544320 total allocated
Upping the higher level of vm.kmem_size_max doesn't help much,
postponing that panic little farther.
db> bt
Traci
On 1/7/08, Pete French <[EMAIL PROTECTED]> wrote:
> > vm.kmem_size="512M"
> > vm.kmem_size_max="512M"
>
> I have similar to this in mine...
>
> vm.kmem_size=629145600
> vm.kmem_size_max=629145600
>
> which is about 600 meg - the machine has 2 gig of RAM.
>
> > vfs.zfs.prefetch_disable="1"
> > vfs.z
I have the following in /boot/loader.conf and it seems to be doing
well for me on FreeBSD-i386 with 1G RAM.
vm.kmem_size="512M"
vm.kmem_size_max="512M"
vfs.zfs.prefetch_disable="1"
vfs.zfs.arc_max="150M"
kern.maxvnodes="40"
Most of these settings came from various mailing list postings. It's
> vm.kmem_size="512M"
> vm.kmem_size_max="512M"
I have similar to this in mine...
vm.kmem_size=629145600
vm.kmem_size_max=629145600
which is about 600 meg - the machine has 2 gig of RAM.
> vfs.zfs.prefetch_disable="1"
> vfs.zfs.arc_max="150M"
> kern.maxvnodes="40"
now these I havent got -
I have been experimenting with ZFS recently, and have been seeing the
occasional reboot with the above error. A quick google shows that this is
a known problem, but that it should go away if you increase kernel
memory. I have done this, but I am still seeing the problem - and not
uunder high load e
В Пт, 16/11/2007 в 09:16 +0100, Kris Kennaway пишет:
> Check the archives, this comes up a lot (you need to increase the amount
> of memory allocated to the kernel).
Already did.
The question actually is how much memory I should allocate for
kernel (exactly, what numbers should be placed
Dear colleagues,
do you have any suggestions about how I should trace what condition
generates kernel panic with reason "kmem_map too small"?
Operating system is FreeBSD 6.2-p8, no unusual software runs on this
machine -- it runs Asterisk with dummy Zapata driver, FreeRAD
Andrew Kolchoogin wrote:
В Пт, 16/11/2007 в 09:16 +0100, Kris Kennaway пишет:
Check the archives, this comes up a lot (you need to increase the amount
of memory allocated to the kernel).
Already did.
The question actually is how much memory I should allocate for
kernel (exactly, what
On Mon, Mar 05, 2007 at 01:14:29PM -0500, Mikhail Teterin wrote:
> On Monday 05 March 2007 08:23, Yar Tikhiy wrote:
> = > How will it break them? swap backing only touches swap if there is
> = > memory pressure, i.e. precisely the situation in which malloc backing
> = > will panic.
> =
> = I forg
Kostik Belousov wrote:
On Mon, Mar 05, 2007 at 10:17:14PM +0300, Yar Tikhiy wrote:
On Mon, Mar 05, 2007 at 01:14:29PM -0500, Mikhail Teterin wrote:
On Monday 05 March 2007 08:23, Yar Tikhiy wrote:
= > How will it break them? swap backing only touches swap if there is
= > memory pressure, i.e.
On Mon, Mar 05, 2007 at 09:30:22PM +0200, Kostik Belousov wrote:
> On Mon, Mar 05, 2007 at 10:17:14PM +0300, Yar Tikhiy wrote:
> > On Mon, Mar 05, 2007 at 01:14:29PM -0500, Mikhail Teterin wrote:
> > > On Monday 05 March 2007 08:23, Yar Tikhiy wrote:
> > > = > How will it break them? swap backing
On Mon, Mar 05, 2007 at 10:17:14PM +0300, Yar Tikhiy wrote:
> On Mon, Mar 05, 2007 at 01:14:29PM -0500, Mikhail Teterin wrote:
> > On Monday 05 March 2007 08:23, Yar Tikhiy wrote:
> > = > How will it break them? swap backing only touches swap if there is
> > = > memory pressure, i.e. precisely the
On Mon, Mar 05, 2007 at 01:14:29PM -0500, Mikhail Teterin wrote:
> On Monday 05 March 2007 08:23, Yar Tikhiy wrote:
> = > How will it break them? swap backing only touches swap if there is
> = > memory pressure, i.e. precisely the situation in which malloc backing
> = > will panic.
> =
> = I forg
On Monday 05 March 2007 08:23, Yar Tikhiy wrote:
= > How will it break them? swap backing only touches swap if there is
= > memory pressure, i.e. precisely the situation in which malloc backing
= > will panic.
=
= I forgot that in BSD swap wouldn't be allocated in advance to its
= consumers. The
On Sun, Mar 04, 2007 at 10:59:46PM -0500, Kris Kennaway wrote:
> On Sun, Mar 04, 2007 at 10:59:46AM +0300, Yar Tikhiy wrote:
> > On Tue, Feb 27, 2007 at 04:03:30PM -0500, Mikhail Teterin wrote:
> > > On Tuesday 27 February 2007 15:53, Alex Kozlov wrote:
> > > = > Yes, I switched to swap-backed md a
On Sun, Mar 04, 2007 at 10:59:46AM +0300, Yar Tikhiy wrote:
> On Tue, Feb 27, 2007 at 04:03:30PM -0500, Mikhail Teterin wrote:
> > On Tuesday 27 February 2007 15:53, Alex Kozlov wrote:
> > = > Yes, I switched to swap-backed md already. But the malloc-based variety
> > is
> > = > currently the _de
On Sun, Mar 04, 2007 at 10:59:46AM +0300, Yar Tikhiy wrote:
> On Tue, Feb 27, 2007 at 04:03:30PM -0500, Mikhail Teterin wrote:
> > On Tuesday 27 February 2007 15:53, Alex Kozlov wrote:
> > = > Yes, I switched to swap-backed md already. But the malloc-based variety
> > is
> > = > currently the _de
On Tue, Feb 27, 2007 at 04:03:30PM -0500, Mikhail Teterin wrote:
> On Tuesday 27 February 2007 15:53, Alex Kozlov wrote:
> = > Yes, I switched to swap-backed md already. But the malloc-based variety
> is
> = > currently the _default_ (see /etc/defaults/rc.conf)...
> = Bad default.
>
> Filing a P
Kris Kennaway wrote:
> On Tue, Feb 27, 2007 at 04:24:21PM -0500, Mikhail Teterin wrote:
>> The strings "panic" and "-o reserve" are mentioned in neither mdmfs(8) nor
>> in
>> rc.conf(5)... Is one supposed to look elsewhere?
>
> Yes, mdconfig, which is what creates the device (mdmfs is a legacy
>
Kris Kennaway wrote:
> On Tue, Feb 27, 2007 at 04:24:21PM -0500, Mikhail Teterin wrote:
>> The strings "panic" and "-o reserve" are mentioned in neither mdmfs(8) nor
>> in
>> rc.conf(5)... Is one supposed to look elsewhere?
>
> Yes, mdconfig, which is what creates the device (mdmfs is a legacy
>
On Tue, Feb 27, 2007 at 04:46:57PM -0500, Michael Proto wrote:
> Kris Kennaway wrote:
> > On Tue, Feb 27, 2007 at 04:24:21PM -0500, Mikhail Teterin wrote:
> >> The strings "panic" and "-o reserve" are mentioned in neither mdmfs(8) nor
> >> in
> >> rc.conf(5)... Is one supposed to look elsewhere?
On Tue, Feb 27, 2007 at 04:24:21PM -0500, Mikhail Teterin wrote:
> On Tuesday 27 February 2007 16:09, Kris Kennaway wrote:
> = Documented in the manpage, use swap backing or reserve enough space.
> =
> = Kris
>
> The strings "panic" and "-o reserve" are mentioned in neither mdmfs(8) nor in
> rc.
On Tuesday 27 February 2007 16:09, Kris Kennaway wrote:
= Documented in the manpage, use swap backing or reserve enough space.
=
= Kris
The strings "panic" and "-o reserve" are mentioned in neither mdmfs(8) nor in
rc.conf(5)... Is one supposed to look elsewhere?
Worse, the use of malloc-based m
OSPC, the entire
> system paniced:
>
> [...]
> g_vfs_done():md0[WRITE(offset=982335488, length=131072)]error = 28
> g_vfs_done():md0[WRITE(offset=982466560, length=131072)]error = 28
> panic: kmem_malloc(16384): kmem_map too small: 259153920 total allocated
> Uptime: 34d21h13m
On Tuesday 27 February 2007 15:53, Alex Kozlov wrote:
= > Yes, I switched to swap-backed md already. But the malloc-based variety is
= > currently the _default_ (see /etc/defaults/rc.conf)...
= Bad default.
Filing a PR.
= > Creation of a 2Gb malloc-based md should've failed on a machine with
= >
On Tue, Feb 27, 2007 at 02:48:11PM -0500, Mikhail Teterin wrote:
> On Tuesday 27 February 2007 11:41, Alex Kozlov wrote:
> = On Tue, Feb 27, 2007 at 10:59:08AM -0500, Mikhail Teterin wrote:
> = > /tmp's space allocation (after reboot) is as follows:
> = >
> = > Filesystem 1K-blocks Used Avail
On Tuesday 27 February 2007 11:41, Alex Kozlov wrote:
= On Tue, Feb 27, 2007 at 10:59:08AM -0500, Mikhail Teterin wrote:
= > /tmp's space allocation (after reboot) is as follows:
= >
= > Filesystem 1K-blocks Used Avail Capacity Mounted on
= > /dev/md0 2026030 3552 1860396 0%/tmp
On Tue, Feb 27, 2007 at 10:59:08AM -0500, Mikhail Teterin wrote:
> /tmp's space allocation (after reboot) is as follows:
>
> Filesystem 1K-blocks Used Avail Capacity Mounted on
> /dev/md0 2026030 3552 1860396 0%/tmp
>
> Note, that it is supposed to hold 2Gb, but was filled up a
)]error = 28
panic: kmem_malloc(16384): kmem_map too small: 259153920 total allocated
Uptime: 34d21h13m21s
Dumping 767 MB (2 chunks)
chunk 0: 1MB (159 pages) ... ok
chunk 1: 767MB (196288 pages) 751 735 719 703 687 671 655 639 623 607 591
575 559 543 527 511 495 479 463 447 431 415 399 383 367
Am 26.10.2006 um 15:47 schrieb Stefan Bethke:
So far, the machines always just hang instead of dumping core; I'll
see if I can get them to write a dump. Can umastat be run against
a live kernel? Then I could try running it as a cron job to record
data up to just before the panic.
Still
TMP]
(Node 0xc63ede00), AE_NO_MEMORY
panic: kmem_malloc(4096): kmem_map too small: 699756544 total allocated
KDB: enter: panic
[thread pid 1119 tid 100074 ]
Stopped at kdb_enter+0x30: leave
db> show uma
Zone AllocsFrees UsedCache
pfosfp
Am 26.10.2006 um 15:37 schrieb Robert Watson:
On Thu, 26 Oct 2006, Stefan Bethke wrote:
acpica 3024 159K 20026966
...
db> show uma
Zone AllocsFrees UsedCache
64 9990754 9986054 4700 9980755
On Thu, 26 Oct 2006, Stefan Bethke wrote:
acpica 3024 159K 20026966
...
db> show uma
Zone AllocsFrees UsedCache
64 9990754 9986054 4700 9980755
Looks like acpica has gone crazy performing a
TMP] (Node
0xc63ee380), AE_NO_MEMORY
ACPI-1304: *** Error: Method execution failed [\_TZ_.THRM._TMP]
(Node 0xc63ede00), AE_NO_MEMORY
panic: kmem_malloc(16384): kmem_map too small: 699756544 total allocated
KDB: enter: panic
[thread pid 1386 tid 100059 ]
Stopped at kdb_enter+0x30: leave
Am 26.10.2006 um 09:32 schrieb Stefan Bethke:
Am 26.10.2006 um 02:34 schrieb Scott Long:
There are no obvious culprits from what you posted. [...] Can you
try the following two commands:
vmstat -m
sysctl hw.busdma
Just reset the machine to run these two commands. Will set up a
cron jo
Am 26.10.2006 um 12:20 schrieb Robert Watson:
After a bit of looking at the output, etc, I agree with your
conclusion that what's there now is lacking. The attached patch,
committed to -CURRENT but not yet to -STABLE, makes the "show
malloc" DDB output a bit more like the "vmstat -m" outpu
On Thu, 26 Oct 2006, Robert Watson wrote:
On Wed, 25 Oct 2006, Scott Long wrote:
There are no obvious culprits from what you posted. The kernel was only
trying to allocate 60 bytes, and the 64-byte bucket didn't look to be
overly used. None of the other zones look terribly over-used either
On Wed, 25 Oct 2006, Scott Long wrote:
There are no obvious culprits from what you posted. The kernel was only
trying to allocate 60 bytes, and the 64-byte bucket didn't look to be overly
used. None of the other zones look terribly over-used either. The 'show
malloc' command doesn't really
Am 26.10.2006 um 02:34 schrieb Scott Long:
There are no obvious culprits from what you posted. [...] Can you
try the following two commands:
vmstat -m
sysctl hw.busdma
Just reset the machine to run these two commands. Will set up a cron
job to log them every five minutes so they're avail
Stefan Bethke wrote:
Am 25.10.2006 um 19:36 schrieb Robert Watson:
On Wed, 25 Oct 2006, Stefan Bethke wrote:
We're consistely getting this panic even under smallish loads. I've
experimented with various values for VM_KMEM_SIZE_MAX (384, 512, 768
and 1024 MB), but the boxes are still panic
Am 25.10.2006 um 19:31 schrieb Jeremy Chadwick:
Try tuning memory parameters via loader.conf:
$ cat /boot/loader.conf
# Increase maximum allocatable memory on a process to 768MB.
# We don't choose 2GB (our amount of RAM) since that would
# exhaust all memory, and result in a kernel panic. Maxi
cannot be initiated, so the
kernel hangs...
Thanks,
Stefan
login: cblock_alloc_cblocks: M_NOWAIT malloc failed, trying M_WAITOK
panic: kmem_malloc(4096): kmem_map too small: 699756544 total allocated
Uptime: 5h4m51s
KDB: enter: Break sequence on console
[thread pid 1545 tid 100066 ]
Stopped at kdb_enter
AE_NO_MEMORY
ACPI-1304: *** Error: Method execution failed [\RTMP] (Node 0xc63ee380),
AE_NO_MEMORY
ACPI-1304: *** Error: Method execution failed [\_TZ_.THRM._TMP] (Node
0xc63ede00), AE_NO_MEMORY
panic: kmem_malloc(4096): kmem_map too small: 699756544 total allocated
Uptime: 1h54m54s
KDB: e
On Wed, Oct 25, 2006 at 07:17:26PM +0200, Stefan Bethke wrote:
> We're consistely getting this panic even under smallish loads. I've
> experimented with various values for VM_KMEM_SIZE_MAX (384, 512, 768
> and 1024 MB), but the boxes are still panicking after even short
> periods (a few hour
led [\RBYT] (Node
0xc63ee1a0), AE_NO_MEMORY
ACPI-1304: *** Error: Method execution failed [\RTMP] (Node
0xc63ee380), AE_NO_MEMORY
ACPI-1304: *** Error: Method execution failed [\_TZ_.THRM._TMP]
(Node 0xc63ede00), AE_NO_MEMORY
panic: kmem_malloc(4096): kmem_map too small: 699756544 total
Kris Kennaway <[EMAIL PROTECTED]> wrote:
> On Wed, Dec 14, 2005 at 05:32:34PM +0100, Fabian Keil wrote:
>
> > I guess you're right. I can fill a 256MB swap-backed disk without
> > panic and without swapping.
>
> FYI, this is documented in the manpage.
I think the panic potential should be menti
On Wed, Dec 14, 2005 at 05:32:34PM +0100, Fabian Keil wrote:
> I guess you're right. I can fill a 256MB swap-backed disk without panic
> and without swapping.
FYI, this is documented in the manpage.
Kris
pgpJ4IsKT7ayY.pgp
Description: PGP signature
Scott Long <[EMAIL PROTECTED]> wrote:
> Gleb Smirnoff wrote:
>
> > On Wed, Dec 14, 2005 at 01:25:30PM +0100, Fabian Keil wrote:
> > F> I triggered a few reproducible panics on FreeBSD 6.0-STABLE.
> > F>
> > F> I created a ramdisk with:
> > F>
> > F> /sbin/mdconfig -a -t malloc -s 256M
Gleb Smirnoff wrote:
On Wed, Dec 14, 2005 at 01:25:30PM +0100, Fabian Keil wrote:
F> I triggered a few reproducible panics on FreeBSD 6.0-STABLE.
F>
F> I created a ramdisk with:
F>
F> /sbin/mdconfig -a -t malloc -s 256M -u 10
F> /sbin/newfs -U /dev/md10
F> /sbin/mount
Gleb Smirnoff <[EMAIL PROTECTED]> wrote:
> On Wed, Dec 14, 2005 at 01:25:30PM +0100, Fabian Keil wrote:
> F> I triggered a few reproducible panics on FreeBSD 6.0-STABLE.
> F>
> F> I created a ramdisk with:
> F>
> F> /sbin/mdconfig -a -t malloc -s 256M -u 10
> F> /sbin/newfs -U /
On Wed, Dec 14, 2005 at 01:25:30PM +0100, Fabian Keil wrote:
F> I triggered a few reproducible panics on FreeBSD 6.0-STABLE.
F>
F> I created a ramdisk with:
F>
F> /sbin/mdconfig -a -t malloc -s 256M -u 10
F> /sbin/newfs -U /dev/md10
F> /sbin/mount /dev/md10 /mnt/ramdisk
F
f the kernel message buffer:
panic: kmem_malloc(16384): kmem_map too small: 172728320 total allocated
Uptime: 2m57s
Dumping 511 MB (2 chunks)
chunk 0: 1MB (158 pages) ... ok
chunk 1: 511MB (130800 pages) 495 479 463 447 431 415 399 383 367 351 335 319
303 287 271 255 239 223 207 191 175 159 143
Confirmed, no more leaks. I put it 1 hour ago onto 1 production server,
and today evening I'll put it to another one. Every server serves up to 2
million SMTP connections per day: load are heavy. Both servers SMP.
Gleb Smirnoff wrote:
GS> please confirm that the attached patch fix your problem.
On Tue, Oct 25, 2005 at 06:04:15PM +0200, Max Laier wrote:
M> On Tuesday 25 October 2005 17:00, Gleb Smirnoff wrote:
M> > Vladimir,
M> >
M> > please confirm that the attached patch fix your problem. The patch is
M> > relative to src/sys tree.
M> >
M> > Kris, Christian, please review it. Thank
On Tuesday 25 October 2005 17:00, Gleb Smirnoff wrote:
> Vladimir,
>
> please confirm that the attached patch fix your problem. The patch is
> relative to src/sys tree.
>
> Kris, Christian, please review it. Thanks.
Are you sure it's safe to free the nlminfo struct before calling to fdfree()
Vladimir,
please confirm that the attached patch fix your problem. The patch is relative
to src/sys tree.
Kris, Christian, please review it. Thanks.
--
Totus tuus, Glebius.
GLEBIUS-RIPN GLEB-RIPE
Index: nfsclient/nfs_lock.c
=
Pete French wrote:
>> I found the sources of the leak: if exim accessess ANY configuration/text
>> files over NFS, there will be leak. And, how often exim will be called, then
>> quicker your system dies.
PF> Surely this has to be a problenm wth NFS in the kernel, not with exim
PF> though? Did
> I found the sources of the leak: if exim accessess ANY configuration/text
> files over NFS, there will be leak. And, how often exim will be called, then
> quicker your system dies.
Surely this has to be a problenm wth NFS in the kernel, not with exim
though? Did you log a FreeBSD PR on this ? I
). Any /ports solution ?
The next question to Philip Hazel: any comments why this happens ?
Vladimir Sharun wrote:
VS> We have 2xOpteron/2Gb RAM server with extensive disk load. Every week or
two
VS> it suddenly hangs with "kmem_malloc(4096): kmem_map too small 335bla-bla
allocate
Kris Kennaway wrote:
>> Looks like kernel leak (thanks for tip to Gleb Smirnov) in lockf.
>> # vmstat -zm | grep lock
>> lockf 2257779 70556K - 19476940 32,64
>> ... and keep raising.
>>
>> That's another one machine with 1Gb RAM, having 512M for vm.kmem_size_max
>> too.
KK> OK,
On Sun, Oct 23, 2005 at 08:07:09PM +0300, Vladimir Sharun wrote:
> Kris Kennaway wrote:
> > >>> We have 2xOpteron/2Gb RAM server with extrensive disk load. Every week
> > >>> or two
> > >>> it suddenly hangs with "kmem_malloc(4096): kmem_map
- 710899 32,64
lockf 80675 2523K - 710930 32,64
(output from while true; do vmstat -m | grep lockf; sleep 1 ; done)
Vladimir Sharun wrote:
VS> We have 2xOpteron/2Gb RAM server with extrensive disk load. Every week or
two
VS> it suddenly hangs with "kmem_malloc(4096): k
Kris Kennaway wrote:
> >>> We have 2xOpteron/2Gb RAM server with extrensive disk load. Every week or
> >>> two
> >>> it suddenly hangs with "kmem_malloc(4096): kmem_map too small 335bla-bla
> >>> allocated".
> >>> I loo
On Sun, Oct 23, 2005 at 12:05:26PM +0300, Vladimir Sharun wrote:
> Kris Kennaway wrote:
> >> We have 2xOpteron/2Gb RAM server with extrensive disk load. Every week or
> >> two
> >> it suddenly hangs with "kmem_malloc(4096): kmem_map too small 335bla-bla
Kris Kennaway wrote:
>> We have 2xOpteron/2Gb RAM server with extrensive disk load. Every week or two
>> it suddenly hangs with "kmem_malloc(4096): kmem_map too small 335bla-bla
>> allocated".
>> I look onto handbook and put vm.kmem_size_max="536870912&qu
uddenly hangs with "kmem_malloc(4096): kmem_map too small 335bla-bla
> >> allocated".
> >> I look onto handbook and put vm.kmem_size_max="536870912" onto
> >> /boot/loader.conf.
> >> Today was the same with the new parameters. Is there any othe
Kris Kennaway wrote:
KK> On Sun, Oct 23, 2005 at 10:43:42AM +0300, Vladimir Sharun wrote:
>> We have 2xOpteron/2Gb RAM server with extrensive disk load. Every week or two
>> it suddenly hangs with "kmem_malloc(4096): kmem_map too small 335bla-bla
>> allocated".
On Sun, Oct 23, 2005 at 10:43:42AM +0300, Vladimir Sharun wrote:
> We have 2xOpteron/2Gb RAM server with extrensive disk load. Every week or two
> it suddenly hangs with "kmem_malloc(4096): kmem_map too small 335bla-bla
> allocated".
> I look onto handbook and put vm.km
We have 2xOpteron/2Gb RAM server with extrensive disk load. Every week or two
it suddenly hangs with "kmem_malloc(4096): kmem_map too small 335bla-bla
allocated".
I look onto handbook and put vm.kmem_size_max="536870912" onto
/boot/loader.conf.
Today was the same with th
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Kris Kennaway
> Sent: 12. juni 2005 03:40
> To: Tom Jensen
> Cc: freebsd-stable@freebsd.org
> Subject: Re: panic: kmem_malloc(4096): kmem_map too small:
> 62877696 totalal
On Sun, Jun 12, 2005 at 01:11:13AM +0200, Tom Jensen wrote:
> Got the following panic on a 5.4 box(i386):
>
> panic: kmem_malloc(4096): kmem_map too small: 62877696 total allocated
>
> Uname: 5.4-RELEASE FreeBSD 5.4-RELEASE #4: Sun May 8 01:57:26 CEST 2005
>
> Had two nt
Got the following panic on a 5.4 box(i386):
panic: kmem_malloc(4096): kmem_map too small: 62877696 total allocated
Uname: 5.4-RELEASE FreeBSD 5.4-RELEASE #4: Sun May 8 01:57:26 CEST 2005
Had two ntfs partitions mounted and was doing a find . -name *.pst on one of
them.
Following info
On Fri, 6 May 2005, Piotr Gnyp <[EMAIL PROTECTED]> wrote:
panic message:
savecore: reboot after panic: kmem_malloc(45056): kmem
_map too small: 334680064 total allocated
Ok, I`ve found:
http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/book.html#KMEM-MAP-TOO-SMALL
when i try to do kgdb i get thi
uname -v
FreeBSD 5.3-RELEASE-p9
panic message:
savecore: reboot after panic: kmem_malloc(45056): kmem
_map too small: 334680064 total allocated
when i try to do kgdb i get this:
kgdb: cannot read PTD
Panic after 31 days of uptime.
I will gladly show more data if needed.
--
"How fortunate the man wi
>> This host has 192 MB of RAM and 512 MB of swap.
>> +/sbin/mdmfs -i 4096 -s $1md $2
5 ноября 2004 г. в 13:54 -0800, Kris Kennaway пишет:
> See the manpage. You don't have enough RAM in your system to do that.
A bug in manpage? "By default, mdmfs creates a swap-based (MD_SWAP) disk".
I'
On Fri, Nov 05, 2004 at 02:08:30PM +0300, [EMAIL PROTECTED] wrote:
> This host has 192 MB of RAM:
>
> > dmesg | grep memory
> real memory = 199753728 (190 MB)
> avail memory = 189919232 (181 MB)
>
> And 512 MB of swap:
>
> > swapinfo -k
> Device 1K-blocks UsedAvail
he memory filesystem if it has not already been created
But I'm still getting panic sometimes
when trying to untar data to /tmp:
> dmesg | grep -A 3 panic
panic: kmem_malloc(4096): kmem_map too small: 63737856 total allocated
Uptime: 1d23h53m0s
Cannot dump. No dump device
(-1077936128): kmem_map too small: 6619136 total allocated
panic messages:
---
panic: kmem_malloc(-1077936128): kmem_map too small: 6619136 total allocated
syncing disks... 67 67 67 67 67 67 67 67 67 67 67 67 67 67 67 67 67 67 67 67
giving up on 64 buffers
Uptime: 25s
dumping to dev #ad/0x20001, offset 24
92 matches
Mail list logo