Re: loader failure

[John Baldwin]

On 16-May-2002 Dag-Erling Smorgrav wrote:
> John Baldwin <[EMAIL PROTECTED]> writes:
>> e -n 100 
> 
> Yep, this (well, e -w -n 100 blah, and a number of variations) is what
> I tried.

This works on my PWS 500au but not on the DS20.

>> e -n 100 vmem:
> 
> I guess the address space specifier is what was missing.

This works on the DS20 but not on the PWS 500au.  Yay for consistency. :)

-- 

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

[Bruce Evans]

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 

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

[Dag-Erling Smorgrav]

John Baldwin <[EMAIL PROTECTED]> writes:
> e -n 100 

Yep, this (well, e -w -n 100 blah, and a number of variations) is what
I tried.

> e -n 100 vmem:

I guess the address space specifier is what was missing.

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]

> > 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]>
     
Don't _EVER_ lose your sense of humour !  



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: loader failure

[John Baldwin]

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 

if that doesn't work then try:

e -n 100 vmem:

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]

> 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]>
     
Don't _EVER_ lose your sense of humour !  



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: loader failure

[Dag-Erling Smorgrav]

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]

> > 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  
> > 
> > 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]>
     
Don't _EVER_ lose your sense of humour !  



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: loader failure

[Dag-Erling Smorgrav]

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

[Bernd Walter]

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  
> 
> 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.

> 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).

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

[Andrew Gallatin]

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):
<..>
 > 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).

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

[John Baldwin]

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  
> 
> 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)
> 
> 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).

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