Re: loader failure
On Wed, 15 May 2002, John Baldwin wrote: On 15-May-2002 Dag-Erling Smorgrav wrote: John Baldwin [EMAIL PROTECTED] writes: 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. How do I get a stack trace? I can't get the 'examine' command to actually print anything... It depends on which machine actually. :-/ First do 'e sp' to get the stack pointer. Then you want to do something like this: e -n 100 value of sp without any leading 0x At least for i386's, it can be useful to set $esp and $eip to non-preposterous values if they are hosed (record the old values first). Bugs in the pagefault handler make the behaviour for invalid pointers very bad. The main one trap_pfault() doesn't give up immediately if the pagefault is from within ddb. In old versions of FreeBSD, this is probably only fatal if trap_pfault() blocks, but in -current is is fatal in the usual case where trap_fault() acquires a sleep lock. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: loader failure
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 ([EMAIL PROTECTED], 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 0xfc32e740... halted CPU 0 halt code = 2 kernel stack not valid halt PC = 2 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 0xfff8f446 exec /sbin/init: error 5 spec_getpages: preposterous offset 0xfff81426c000 exec /sbin/init.bak: error 5 spec_getpages: preposterous offset 0xfff8c86c 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=wildThe 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 [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: loader failure
Dag-Erling Smorgrav writes: Trying to boot with a newly-built loader (make world earlier today from fresh sources) results in: .. 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): .. guess type=wildThe 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 My 2 cents - the kernel world (including loader) were fine as of Friday (both built with gcc3, modulo the atomic fixes for vm_object.c that jhb / alc / jeff came up with on Saturday). Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: loader failure
On Wed, May 15, 2002 at 02:22:04PM +0200, 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 ([EMAIL PROTECTED], 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 0xfc32e740... halted CPU 0 halt code = 2 kernel stack not valid halt PC = 2 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 0xfff8f446 exec /sbin/init: error 5 spec_getpages: preposterous offset 0xfff81426c000 exec /sbin/init.bak: error 5 spec_getpages: preposterous offset 0xfff8c86c 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) I'm running 11th May -current with ev4 on NoName and since yesterday with ev56 on PC164. No problems with /boot/loader. On the PC164 I had an dup alloc ufs panic yesterday :( The filesystem was checked with fsck -y directly after updating. Debugging options in kernel were disabled. guess type=wildThe 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 Some UFS2 preparation parts were commited after I checked out my source, IIRC also a part influencing loader. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: loader failure
John Baldwin [EMAIL PROTECTED] writes: 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. How do I get a stack trace? I can't get the 'examine' command to actually print anything... DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: loader 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 0xfff8f446 exec /sbin/init: error 5 spec_getpages: preposterous offset 0xfff81426c000 exec /sbin/init.bak: error 5 spec_getpages: preposterous offset 0xfff8c86c 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) This was fixed an hour or so ago. Phk backed out the daddr_t size change pending investigation. -- Brian [EMAIL PROTECTED][EMAIL PROTECTED] http://www.Awfulhak.org brian@[uk.]FreeBSD.org Don't _EVER_ lose your sense of humour ! brian@[uk.]OpenBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: loader failure
Brian Somers [EMAIL PROTECTED] writes: This was fixed an hour or so ago. Phk backed out the daddr_t size change pending investigation. Does that fix the loader too, or just the kernel? DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: loader failure
Brian Somers [EMAIL PROTECTED] writes: This was fixed an hour or so ago. Phk backed out the daddr_t size change pending investigation. Does that fix the loader too, or just the kernel? I'm not sure, I'm just rebuilding now. Remember, /boot/loader.old is left around... handy in this situation (I'd forgotten 'till jhb pointed it out). DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] -- Brian [EMAIL PROTECTED][EMAIL PROTECTED] http://www.Awfulhak.org brian@[uk.]FreeBSD.org Don't _EVER_ lose your sense of humour ! brian@[uk.]OpenBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: loader failure
On 15-May-2002 Dag-Erling Smorgrav wrote: John Baldwin [EMAIL PROTECTED] writes: 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. How do I get a stack trace? I can't get the 'examine' command to actually print anything... It depends on which machine actually. :-/ First do 'e sp' to get the stack pointer. Then you want to do something like this: e -n 100 value of sp without any leading 0x if that doesn't work then try: e -n 100 vmem:value of sp w/o leading 0x This should basically do a raw memory dump. However, see if phk's daddr_t reversal fixes it first. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: loader failure
Brian Somers [EMAIL PROTECTED] writes: This was fixed an hour or so ago. Phk backed out the daddr_t size change pending investigation. Does that fix the loader too, or just the kernel? I'm not sure, I'm just rebuilding now. Remember, /boot/loader.old is left around... handy in this situation (I'd forgotten 'till jhb pointed it out). Yes, the daddr_t backout has fixed the loader and the filesystem problems. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] -- Brian [EMAIL PROTECTED][EMAIL PROTECTED] http://www.Awfulhak.org brian@[uk.]FreeBSD.org Don't _EVER_ lose your sense of humour ! brian@[uk.]OpenBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
