Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 10 Jan 2002 23:13:59 -0600 (CST)
From:      "Stephen D. Spencer" <bsd-alpha@boneyard.lawrence.ks.us>
To:        freebsd-alpha@freebsd.org
Subject:   /boot/loader failure 4.5-PR
Message-ID:  <Pine.BSF.4.10.10201102239470.48285-100000@madeline.boneyard.lawrence.ks.us>

next in thread | raw e-mail | index | archive | help

Resetting I/O buses...

ewa0: link up : Negotiated  100BaseTX: full duplex
(boot dqa0.0.0.13.0 -flags a)
block 0 of dqa0.0.0.13.0 is a valid boot block
reading 15 blocks from dqa0.0.0.13.0
bootstrap code read in
base = 200000, image_start = 0, image_bytes = 1e00
initializing HWRPB at 2000
initializing page table at 17f3e000
initializing machine state
setting affinity to the primary CPU
jumping to bootstrap code
Loading /boot/loader
-
halted CPU 0

halt code = 2
kernel stack not valid halt
PC = 545532080018    
boot failure

This is a DS10/466 running -stable as of today.  This issue started, I believe,
between the 4th and 7th of January.  Monday's build was the first to exhibit
this behavior.

I was able to recover by installing the boot programs from a 4.4-R disk.  
There are no compiler related options defined in /etc/make.conf.  The cputype 
was left at the default (ev4) on a second build/install cycle to verify that 
nothing goofy was happening there.

Please let me know if there is any other information I can provide.  This is
easily replicable.

On another topic, I am looking for any documentation that might assist
me in understanding the source and [ more specific ] nature of these 
unaligned access errors that are disturbingly cropping up in base OS 
utilities such as ifconfig.  I've traced it down to where it's running
a logic operator (if) on the if_msghdr struct called ifm in the ifconfig.c
status(). 

Now, I understand machine language concepts (ex. w/ 6502, 8088 and Z80); how-
ever I am not familar with the alpha instructions.  I think I understand the
nature of these misaligned access errors (all memory access must occur on a 
64-bit word boundry?).  Is it a matter of hunting down the offending variable 
in the faulty data structure and widening its data type?

Regards,
Stephen 

--
Stephen Spencer
UNIX Systems Administrator
Electrical Engineering and Computer Science Dept.
University of Kansas



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?Pine.BSF.4.10.10201102239470.48285-100000>