Date: Wed, 15 May 2002 08:37:31 -0400 (EDT) From: John Baldwin <jhb@FreeBSD.org> To: Dag-Erling Smorgrav <des@ofug.org> Cc: current@freebsd.org, alpha@freebsd.org Subject: RE: loader failure Message-ID: <XFMail.20020515083731.jhb@FreeBSD.org> In-Reply-To: <xzpd6vxzjmb.fsf@flood.ping.uio.no>
next in thread | previous in thread | raw e-mail | index | archive | help
On 15-May-2002 Dag-Erling Smorgrav wrote: > Trying to boot with a newly-built loader (make world earlier today > from fresh sources) results in: > > FreeBSD/alpha SRM disk boot, Revision 1.2 > (des@dsa.thinksec.com, Wed May 15 08:01:43 CEST 2002) > Memory: 262144 k > Loading /boot/defaults/loader.conf > /boot/kernel/kernel data=0x283780+0x63670 / > > Hit [Enter] to boot immediately, or any other key for command prompt. > Booting [/boot/kernel/kernel]... > Entering /boot/kernel/kernel at 0xfffffc000032e740... > > halted CPU 0 > > halt code = 2 > kernel stack not valid halt > PC = 200000000 > boot failure > > no matter which kernel I try to boot. Booting my new kernel with the > old loader (from the DP1 dist) works fine until it tries to start > init(8): > > spec_getpages: preposterous offset 0xfff80000f4460000 > exec /sbin/init: error 5 > spec_getpages: preposterous offset 0xfff800001426c000 > exec /sbin/init.bak: error 5 > spec_getpages: preposterous offset 0xfff80000c86c0000 > exec /stand/sysinstall: error 5 > init: not found in path > /sbin/init:/sbin/oinit:/sbin/init.bak:/stand/sysinstall > panic: no init > panic > Stopped at Debugger+0x34: zapnot v0,#0xf,v0 <v0=0x0> > > Booting DP1's GENERIC with the old loader and the new userland works > fine. > > Clean tree, no funny stuff in make.conf (unless 'CPUTYPE?=ev56' counts > as funny stuff) > > <guess type="wild">The loader problem is possibly a compiler issue > (since DP1 was built with gcc 2.95 while my world was built with 3.1). > The init problem is probably a UFS2 f*up; the code has obviously not > been tested on a 64-bit architecture (the UFS2 stuff broke the kernel > build).</guess> The kernel overflowed it's stack. In SRM, you can try to debug this by using 'e sp' to get the stack pointer then get a stack dump and save a copy of it in a log or something, reboot the machine, then use gdb's list command on the kernel.debug to figure out the source:line for all the kernel-text addresses in the stack dump to figure out the backtrace. From that you can figure out where the recursion is happening and fix it. -- John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.20020515083731.jhb>