On Wed, Nov 18, 2009 at 9:39 PM, Nick Couchman Nick.Couchman@seakr.com wrote:
On 2009/11/18 at 11:24, Tarl Neustaedter Tarl.Neustaedter@sun.com wrote:
Nick Couchman wrote:
[...] So, for some reason, it cannot step into read-disk for debugging. If I do
"see read-disk":
0 > see read-disk : read-disk dup >r 0 swap cif-seek if " seek failed" die tuck swap r> cif-read <> if " read failed" die ; ok
And, all of these seem to be primitive words - e.g. swap, cif-seek, etc.,
cannot be debugged. I would guess "cif-seek" is where it's failing, which looks like this:
These are part of the forth kernel, where it does file handling operations - they eventually end up generating reads to the HBA.
Where you are in the code itself - line 209 of:
http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/psm/stand/boot... lks/common/util.fth
So we're doing the first cif-seek, which is the client-interface seek. See section 6.3.2.3 in IEEE 1275. That causes the disk to be read so you can cache disk accesses. The question is whether the arguments we are sending are reasonable. What we saw:
00000000ffe318e0: dev-ih ( 8008000 800 8000 ffe4d358 ) 00000000ffe318e8: read-disk
Those arguments we see on the stack are adr, len, off, ihandle. ffe4d358 is a reasonable address for an ihandle. 0x8000 is a reasonable byte offset into the disk to read - and that's all that seek takes (the adr, len get used later by the cif-read, which we don't reach). So somehow, trying to byte offset 0x8000 on the disk is failing - don't know why.
Well, I thought maybe I could use a SCSI-based CD-ROM in Qemu and see if it was the HBA emulation code causing the problem, but qemu doesn't seem to want to boot with a SCSI controller:
OpenBIOS for Sparc64 Cannot manage 'SCSI bus controller' PCI device type '<NULL>': 1000 12 (1 0 0) Segmentation fault
It's OpenBIOS, there is no driver for the HBA. There's a driver for ESP (Sparc32), but I don't think there is a PCI card with ESP chipset.