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
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 i
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 PR
> > 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
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 u
> 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
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 "u
> > 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 0xfff8
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 f
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
> Loadi
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 sta
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.c
12 matches
Mail list logo
