Subject: Re: UFS root, how? was Re: 2.0 rc1 default catch
To: Kendall Shaw <queshaw@pacbell.net>
From: Tim Kelly <hockey@dialectronics.com>
List: port-macppc
Date: 10/05/2004 23:38:11
Use http://developer.apple.com/technotes/tn/tn2004.html to learn how to
telnet into Open Firmware. Capture your telnet session and after the catch
(which is being invoked by OF's exception handler at 0x0300, DSI or bad
data address), type

.registers

in Open Firmware. That'll show the current PC (%SRR0), the link register
and the registers the current instruction was trying to access.

By the way, I have found that otherwise perfectly fine kernels, especially
RAMDISK/INSTALL ones, will give 0x0300 and 0x0400 exceptions if they are
fragmented in MSDOS or HFS formatted partitions. OF reads the disk raw and
knows enough of the two file systems to find the start and end points of
the file. It doesn't stop to check for contiguousness. In order to ensure I
don't have problems when I am testing memory based kernels, I use tftpd for
booting (I modified a bootloader to not use NFS for the kernel part, so
both the bootloader and kernel image come via tftpd).

There are two ways to determine if the file is not contiguous. One is to
use a disk editing tool to find the start and top blocks and then calculate
the file size based on blocks. A file larger than the number of bytes
indicates non-contiguousness. The other is to do an objdump -d of the
kernel (uncompressed if RAMDISK), do a disassembly/dump of the instructions
around the PC at the time of the exception, and try to match the
location/offset of the instructions to the location of the PC and also
verify correct instructions. When I finally determined conclusively that a
problem I was having was due to this condition, I was finding correct
instructions at the wrong locations, and instructions/bytes that would be
one or two bits off and sometimes that would occur in the address portion
of an instruction to read data from memory. Norton Disk Editor showed that
the file spanned several dozen more blocks than it should have, and this
was the result of repeated copying of the file to the same media. The
previously written file in the intermediary blocks would get read in and
execute, for a while at least.

tim