On 2009/11/19 at 13:29, Tarl Neustaedter Tarl.Neustaedter@Sun.COM wrote:
Nick Couchman wrote:
[...] Unfortunately the unhandled exception occurs before this check is done:
Then we've broken something else, because we were getting past that before. We aren't getting to do-boot now.
What boot does is essentially:
<boot-device> open-dev 4000 swap " load" rot $call-method
(it's a bit more complicated, but that's the essence). We seem to be dying in either open-dev or "load" now.
So, using gdb, I've managed to come up with a bit more information - whether it's useful or not is beyond my ability to determine, but here goes...
I set up a breakpoint at fcode_load, because that's the C-based function where it appears to be failing. Once we're in that function, I step through:
Breakpoint 1, fcode_load (filename=0xffec3658 "cdrom") at ../arch/sparc64/fcodeload.c:21 21 if (!file_open(filename)) (gdb) next 25 file_seek(offset); (gdb) 32 switch (fcode_header[0]) { (gdb) 25 file_seek(offset); (gdb) 26 if (lfile_read(&fcode_header, sizeof(fcode_header)) (gdb) 32 switch (fcode_header[0]) { (gdb) 24 for (offset = 0; offset < 16 * 512; offset += 512) { (gdb) 32 switch (fcode_header[0]) { (gdb) 25 file_seek(offset); (gdb) 26 if (lfile_read(&fcode_header, sizeof(fcode_header)) (gdb) 32 switch (fcode_header[0]) { (gdb) 52 printf("Loading FCode image...\n"); (gdb) 50 start = 0x4000; (gdb) 47 size = (fcode_header[4] << 24) | (fcode_header[5] << 16) | (gdb) 52 printf("Loading FCode image...\n"); (gdb) 47 size = (fcode_header[4] << 24) | (fcode_header[5] << 16) | (gdb) 52 printf("Loading FCode image...\n"); (gdb) 47 size = (fcode_header[4] << 24) | (fcode_header[5] << 16) | (gdb) 52 printf("Loading FCode image...\n"); (gdb) 47 size = (fcode_header[4] << 24) | (fcode_header[5] << 16) | (gdb) 52 printf("Loading FCode image...\n"); (gdb) 54 file_seek(offset + sizeof(fcode_header)); (gdb) 56 if ((unsigned long)lfile_read((void *)start, size) != size) { (gdb) 61 debug("Loaded %lu bytes\n", size); (gdb) 70 retval = 0; (gdb) 61 debug("Loaded %lu bytes\n", size); (gdb) 63 debug("entry point is %#lx\n", start); (gdb) 64 printf("Evaluating FCode...\n"); (gdb) 35 dstack[++dstackcnt] = (value); (gdb) 68 fword("byte-load"); (gdb) 35 dstack[++dstackcnt] = (value); (gdb) 68 fword("byte-load"); (gdb) 35 dstack[++dstackcnt] = (value); (gdb) 68 fword("byte-load"); (gdb) 35 dstack[++dstackcnt] = (value); (gdb) 68 fword("byte-load"); (gdb) 35 dstack[++dstackcnt] = (value); (gdb) 68 fword("byte-load"); (gdb) 35 dstack[++dstackcnt] = (value); (gdb) 68 fword("byte-load"); (gdb) 35 dstack[++dstackcnt] = (value); (gdb) 68 fword("byte-load"); (gdb) 35 dstack[++dstackcnt] = (value); (gdb) 68 fword("byte-load"); (gdb)
That last entry - fword("byte-load"); - is where I get the Unhandled Exception in Qemu. So, I also set fcode-verbose to true and ran it, again - the output is very, very long, so I won't include it in the e-mail, but the last few lines look like this:
5b82 : b(:) [ 0xb7 ] 5b84 : (compile) parse-bootargs [ 0x8cf ] 5b86 : (compile) halt? [ 0x8ce ] 5b87 : (compile) b?branch [ 0x14 ] (offset) 1d 5b8a : (compile) b(") [ 0x12 ] (const) Halted with -H flag. 5ba1 : (compile) type [ 0x90 ] 5ba2 : (compile) cr [ 0x92 ] 5ba3 : (compile) exit [ 0x33 ] 5ba4 : (compile) b(>resolve) [ 0xb2 ] 5ba6 : (compile) get-bootdev [ 0x8a0 ] 5ba8 : (compile) load-pkg [ 0x89f ] 5baa : (compile) mount-root [ 0x8a1 ] 5bac : (compile) zflag? [ 0x8c4 ] 5bae : (compile) nested? [ 0x892 ] 5baf : (compile) invert [ 0x26 ] 5bb0 : (compile) and [ 0x23 ] 5bb1 : (compile) b?branch [ 0x14 ] (offset) 7 5bb5 : (compile) fs-name$ [ 0x8c6 ] 5bb7 : (compile) open-zfs-fs [ 0x8c7 ] 5bb8 : (compile) b(>resolve) [ 0xb2 ] 5bba : (compile) load-file [ 0x8e4 ] 5bbc : (compile) setup-props [ 0x8e5 ] 5bbe : (compile) exec-file [ 0x8e6 ] 5bbf : (compile) b(;) [ 0xc2 ] 5bc0 : 0 [ 0xa5 ] 5bc1 : b(to) [ 0xc3 ] 5bc5 : do-boot [ 0x8e7 ] Unaligned access to 0x0000000000000014 from 0x00000000ffd10d9c Unhandled Exception 0x0000000000000034
Let me know if you want me to attach the full output, or if this is helpful at all...
-Nick
-------- This e-mail may contain confidential and privileged material for the sole use of the intended recipient. If this email is not intended for you, or you are not responsible for the delivery of this message to the intended recipient, please note that this message may contain SEAKR Engineering (SEAKR) Privileged/Proprietary Information. In such a case, you are strictly prohibited from downloading, photocopying, distributing or otherwise using this message, its contents or attachments in any way. If you have received this message in error, please notify us immediately by replying to this e-mail and delete the message from your mailbox. Information contained in this message that does not relate to the business of SEAKR is neither endorsed by nor attributable to SEAKR.