Re: 5.2-RELEASE crash

From: Scott Long (scottl_at_freebsd.org)
Date: 01/31/04

  • Next message: Melvyn Sopacua: "Re: ssh hang"
    Date: Sat, 31 Jan 2004 09:37:42 -0700
    To: Andre Guibert de Bruet <andy@siliconlandmark.com>
    
    

    Andre Guibert de Bruet wrote:
    > On Fri, 30 Jan 2004, Magnus Dahlstedt wrote:
    >
    >
    >>panic: kmem_malloc(16384): kmem_map too small: 275243008 total allocated
    >>cpuid = 1;
    >>Debugger("panic")
    >>Stopped at Debugger+0x4f: xchgl %ebx,in_Debugger.0
    >>db> trace
    >>Debugger(c06c2ccd,1,c06d5a05,e40a6a74,100) at Debugger+0x4f
    >>panic(c06d5a05,4000,1067e000,e40a6aa0,c0518254) at panic+0x14a
    >>kmem_malloc(c10310a0,4000,402,e40a6aec,c064c19e) at kmem_malloc+0x101
    >
    > -- 8< -- snip -- 8< --
    >
    >>real memory = 2146942976 (2047 MB)
    >>avail memory = 2080309248 (1983 MB)
    >
    >
    > You are using a large amount of RAM and using the default kmem_map sizing
    > options. What you want to do to fix this is manually increase the
    > KVA_PAGES tunable to something like 640 (By putting "options
    > KVA_PAGES=640" in your kernel config file).
    >
    > You will also want to grow your kmem_map by changing the following:
    > options VM_KMEM_SIZE_MAX=(512*1048576)
    > options VM_KMEM_SIZE_SCALE=2
    >
    > On a busy system with 3.5GB, I found that using 768MB for VM_KMEM_SIZE_MAX
    > helps it run flawlessly. These values are not set in stone, and should
    > only be used as a guide. In other words, do your own testing! :-)
    >

    Also, the scaling of kern.maxvnodes doesn't work very well. On a large
    memory system, it will typically set this to 200,000-300,000. If you
    don't need this many, then it is easier to just crank it down to a more
    reasonable level than fiddle with the KMEM parameters.

    Scott

    _______________________________________________
    freebsd-current@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-current
    To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"


  • Next message: Melvyn Sopacua: "Re: ssh hang"

    Relevant Pages

    • Re: 5.2-RELEASE crash
      ... > db> trace ... You are using a large amount of RAM and using the default kmem_map sizing ...
      (freebsd-current)
    • Re: efficacy of Linux w/o swap
      ... |> dedicated purpose that will use Linux and commodity hardware. ... | I suppose you could lock into RAM, ... can account for such an extreme amount of time. ... then evetually complete the switch. ...
      (comp.os.linux.development.system)
    • Re: xp pro blue screen
      ... Insufficient RAM. ... the amount of RAM, and performance seems to suffer quite badly if and ... Windows Task Manager is basically useless for this type of assessment ...
      (microsoft.public.windowsxp.help_and_support)
    • Re: xp pro blue screen
      ... Insufficient RAM. ... the amount of RAM, and performance seems to suffer quite badly if and ... Windows Task Manager is basically useless for this type of assessment ...
      (microsoft.public.windowsxp.help_and_support)
    • Re: xp pro blue screen
      ... Insufficient RAM. ... the amount of RAM, and performance seems to suffer quite badly if and ... Windows Task Manager is basically useless for this type of assessment ...
      (microsoft.public.windowsxp.help_and_support)