On Mon, 27 Aug 2007 13:55:57 -0400 Neil Horman wrote: > On Mon, Aug 27, 2007 at 10:28:27AM -0700, Randy Dunlap wrote: > > On Mon, 27 Aug 2007 13:02:53 -0400 Don Zickus wrote: > > > > > On Mon, Aug 27, 2007 at 12:55:38PM -0400, Neil Horman wrote: > > > > > crashkernel=64M at 16M > > > > > > > > > Hmm, well that should be enough. looking at your log, it appears as though you > > > > have a 512k chunk allocatable, which should seem sufficient to go on a little > > > > longer. The fact that your not seems to indicate that you are allocating a > > > > suspiciously large single chunk of ram. I'd configure your initramfs to drop to > > > > a shell prompt before it sets up lp0. Then you can step through the actions of > > > > the init script and monitor the contents of /proc/slabinfo to get an idea of > > > > whats eating up all your lowmem prior to the oom kill. > > > > > > > > Neil > > > > > > > > > > <snipped from Randy's output> > > > > > > Out of memory: kill process 680 (boot) score 309 or a child > > > Killed process 701 (S01boot.udev) > > > > > > Heh, it's udev again. What a surprise! </sarcasm> > > > > Right, that's hardly a surprise. :( > > > > > Neil, didn't we solve this with an init 1 or something (ignoring the whole > > > busybox thing). > > > > I was trying to boot to runlevel 3. I can just boot to runlevel 1 > > for a workaround (I think). > > > Don is correct. If we don't capture a dump from the initramfs, I mount the root > fs and run init. We do wind up booting to Run Level 3, but the kdump script > runs early enough that I don't think udevd has a chance to start, and after we > capture a dump we immediately reboot, so I wouldn't expect to see any udevd > problems here. I see. Thanks again. --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code ***
