Date: 08 Apr 2003 15:36:56 -0400 From: Lowell Gilbert <freebsd-stable-local@be-well.no-ip.com> To: Lamont Lucas <lamont@cluepon.com> Cc: stable@freebsd.org Subject: Re: kmem_malloc crash with 4.8 Message-ID: <44u1d8pyqv.fsf@be-well.ilk.org> In-Reply-To: <20030407210757.GE70647@clavin.cluepon.com> References: <20030407210757.GE70647@clavin.cluepon.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Lamont Lucas <lamont@cluepon.com> writes: > Hi. I've recently borrowed a SuperMicro 6013P-8 from a vendor > for the purposes of testing it to see if FreeBSD and these machines will > make a good replacements for our current flock of 11 Netra T1s running > solaris. Things are going very well with the tests, with the glaring > exception of the following crash: > > While doing some significant disk operations: du, deleting a different > part of the tree and finally running "sync" the machine locked hard > with the following errors: > > panic: kmem_malloc(4096): kmem_map too small: 230162432 total allocated > mp_lock = 03000001; cpuid = 3; lapic.id = 07000000 > boot() called on cpu#3 > > Then "Synching disks" but no futher output is printed, nor is any > further progress made. > > This machine was installed off of 4.8-release and was rebuilt under > -stable as of april 4th, late in the afternoon. The kernel conf file > is attached, but biggest changes I made were to enable SMP as well as > hyperthreading. It has 2 gigs of ram and 2 2.4 ghz xeon processors > capable of hyperthreading. The drive is a single <SEAGATE ST336753LC 0003> > controlled by a AIC7902 Ultra 320 scsi adapter. > > I saw the previous discussion about the adaptec U320 controllers and > scott long's advice about "lower[ing] the tag depth to 32" using > camcontrol tags. I'm currently planning on removing hyperthread > support and rerunning some of my tests to see if I can reproduce the > error. I'm also going to try some bonnie tests. If I can > consistantly reproduce the error I'll report back, but I'd appreciate > knowing what additional debug info I can give back. I'm not clear > what would cause this type of error. > > Attached are dmesg as well as the kernel config file. > > Can anybody recommend any other steps to try and eliminate or fix > this problem? You might want to reduce the maxusers value...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?44u1d8pyqv.fsf>