Re: Update: Booting OpenSolaris via gPXE

Hi Moinak,
Here are some results after looking into this using the unix kernel
and ramdisk from milax 0.4 LiveCD (svn_114 32-bit).

/boot/platform/i86pc/kernel/unix
/boot/milax

I am not sure I reproduced the same issue because I get the
DBG_MSG("done\n") after kbm_init() returns whereas your email suggests
the fault happens in kbm_init().  I do get a fault shortly afterwards.
 I was able to identify an issue with ramdisks that may solve your
problem.

The following gPXE script automates the boot:
#!gpxe
dhcp net0
kernel http://10.0.2.2:8000/unix
module http://10.0.2.2:8000/milax
imgargs unix -B
console=ttya,atapi-cd-dma-enabled=0,atapi-other-dma-enabled=0,prom_debug=true,map_debug=true,kbm_debug=true
boot

For reference:
console=ttya enables serial console
prom_debug=true enables debug in dboot and other places
map_debug=true enables memory map debug in dboot
kbm_debug=true enables fakebop debug

I am using QEMU 0.10.4.  The ATAPI DMA settings are recommended for
QEMU by milax.

When I boot using gPXE, the last useful debug output from Solaris is:
Boot properties:
        0x7f1d270 boot-ncpus = len=2 1
        0x7f1d240 cpu_apicid_array = len=1
        0x7f1d210 impl-arch-name = len=6 i86pc
        0x7f1d1f0 mfg-name = len=6 i86pc
        0x7f1d1d0 stdout = len=4
        0x7f1d1b0 bootargs = len=1
        0x7f1d190 boot-args = len=1
        0x7f1d170 kbm_debug = len=5 true
        0x7f1d150 map_debug = len=5 true
        0x7f1d130 prom_debug = len=5 true
        0x7f1d100 atapi-other-dma-enabled = len=2 0
        0x7f1d0d0 atapi-cd-dma-enabled = len=2 0
        0x7f1d0b0 console = len=5 ttya
        0x7f1d090 whoami = len=5 unix
        0x7f1d070 boot-file = len=5 unix
        0x7f1d040 ramdisk_end = len=8 -0xffffffb8--0xffffff89--0xffffffba--0xd-
        0x7f1d010 ramdisk_start = len=8
Unexpected trap
instruction pointer  0xfe841783
error code, optional 0x0
code segment         0x10
flags register       0x6
Attempting stack backtrace:
Stack traceback:
Unexpected trap

That instruction pointer is inside bcopy() called from diskread() in
common/krtld/bootrd.c.  It faults when trying to access the ramdisk.
(Discovered this by placing software breakpoints along the
fakebop.c:_start code path.)

To figure out why ramdisk access is faulting, I compared Solaris'
memory maps between an ISO boot (grub):
Final memlists:
        0: addr=0 size=9f000
        1: addr=100000 size=7ef0000

And HTTP boot (gPXE):
Final memlists:
        0: addr=0 size=9c000
        1: addr=100000 size=5da8000
        2: addr=7f00000 size=f0000

gPXE is hiding the ramdisk [5ea9000,7cff9b8) from the memory map.
This prevents Solaris from mapping the ramdisk memory and causes the
fault.

After changing the following in gPXE multiboot.c:

diff --git a/src/arch/i386/image/multiboot.c b/src/arch/i386/image/multiboot.c
index 1811e91..79ae5fc 100644
--- a/src/arch/i386/image/multiboot.c
+++ b/src/arch/i386/image/multiboot.c
@@ -263,6 +263,11 @@ static struct multiboot_module __bss16_array (
mbmodules, [MAX_MODULES] );
 static int multiboot_exec ( struct image *image ) {
        physaddr_t entry = image->priv.phys;

+       /* Multiboot images may not return and have no callback
+        * interface, so shut everything down prior to booting the OS.
+        */
+       shutdown ( SHUTDOWN_BOOT );
+
        /* Populate multiboot information structure */
        memset ( &mbinfo, 0, sizeof ( mbinfo ) );
        mbinfo.flags = ( MBI_FLAG_LOADER | MBI_FLAG_MEM | MBI_FLAG_MMAP |
@@ -277,11 +282,6 @@ static int multiboot_exec ( struct image *image ) {
        mbinfo.mmap_addr = virt_to_phys ( mbmemmap );
        mbinfo.boot_loader_name = virt_to_phys ( mb_bootloader_name );

-       /* Multiboot images may not return and have no callback
-        * interface, so shut everything down prior to booting the OS.
-        */
-       shutdown ( SHUTDOWN_BOOT );
-
        /* Jump to OS with flat physical addressing */
        DBGC ( image, "MULTIBOOT %p starting execution at %lx\n",
               image, entry );

I now get the following when booting with gPXE:
Final memlists:
        0: addr=0 size=9f000
        1: addr=100000 size=7ef0000

The boot progresses further before stopping, probably because the
kernel can't get at the root filesystem (the ISO) in my test setup.

Does this help?

Stefan

------------------------------------------------------------------------------