OpenBIOS April 2011

openbios@openbios.org

10 participants
28 discussions

Solaris 8 - fun with CPUs :)
by Mark Cave-Ayland 21 Apr '11

21 Apr '11

Hi all, With the previous commit in place, we now get here trying to boot my Solaris 8 ISO image under OpenBIOS: Configuration device id QEMU version 1 machine id 32 CPUs: 1 x FMI,MB86904 UUID: 00000000-0000-0000-0000-000000000000 Welcome to OpenBIOS v1.0 built on Apr 5 2011 08:40 Type 'help' for detailed information 0 > boot cdrom:d -v Not a bootable ELF image Loading a.out image... Loaded 7680 bytes entry point is 0x4000 bootpath: /iommu/sbus/espdma/esp/sd@2,0:d Jumping to entry point 00004000 for type 00000005... switching to new context: Size: 259040+54154+47486 Bytes SunOS Release 5.8 Version Generic_108528-09 32-bit Copyright 1983-2001 Sun Microsystems, Inc. All rights reserved. Ethernet address = 52:54:0:12:34:56 Using default device instance data vac: enabled in write through mode mem = 131072K (0x8000000) avail mem = 110419968 root nexus = SUNW,SPARCstation-5 iommu0 at root: obio 0x10000000 sbus0 at iommu0: obio 0x10001000 dma0 at sbus0: SBus slot 5 0x8400000 dma0 is /iommu@0,10000000/sbus@0,10001000/espdma@5,8400000 /iommu@0,10000000/sbus@0,10001000/espdma@5,8400000/esp@5,8800000 (esp0): esp-options=0x46 esp0 at dma0: SBus slot 5 0x8800000 sparc ipl 4 esp0 is /iommu@0,10000000/sbus@0,10001000/espdma@5,8400000/esp@5,8800000 sd2 at esp0: target 2 lun 0 sd2 is /iommu@0,10000000/sbus@0,10001000/espdma@5,8400000/esp@5,8800000/sd@2,0 root on /iommu@0,10000000/sbus@0,10001000/espdma@5,8400000/esp@5,8800000/sd@2,0:b fstype ufs obio0 at root obio0 at obio0: obio 0x100000, sparc ipl 12 zs0 is /obio/zs@0,100000 obio1 at obio0: obio 0x0, sparc ipl 12 zs1 is /obio/zs@0,0 (here we freeze) According to Artyom's OBP output, the next line displayed should identify the CPU but we don't ever seem to get there. Looking at various symbols within the kernel, it appears as if we spend a short time in some kind of CPU speed detection routine (a loop of several seconds with lots of get_hrtime* type calls) before bailing out. Alas at the moment, kadb doesn't work which means since these calls are coming from a module, I don't have much in the symbol names to work with. Talking of kadb, if I try and invoke it at the moment, I get this: Configuration device id QEMU version 1 machine id 32 CPUs: 1 x FMI,MB86904 UUID: 00000000-0000-0000-0000-000000000000 Welcome to OpenBIOS v1.0 built on Apr 5 2011 08:40 Type 'help' for detailed information 0 > boot cdrom:d kadb -kdv Not a bootable ELF image Loading a.out image... Loaded 7680 bytes entry point is 0x4000 bootpath: /iommu/sbus/espdma/esp/sd@2,0:d Jumping to entry point 00004000 for type 00000005... switching to new context: Size: 119204+222573+28987 Bytes kadb: kadb: kernel/unix Size: 259040+54154+47486 Bytes /platform/SUNW,SPARCstation-5/kernel/unix loaded - 0x95000 bytes used kadb[0]: :c Begin traceback... sp = 12f9e0 Called from fbd01700, fp=12fa50, args=9 f0086444 f0086438 0 f0258f2c 0 Called from f00859e0, fp=12fad8, args=f0258fc0 44 12fbf8 0 f0258f2c f0258f70 Called from f0082518, fp=12fb38, args=f0258fc0 0 44 0 0 fbd039e4 Called from f0081c48, fp=12fb98, args=12fbf8 f0258de8 12fbf8 fbd58800 f0040000 f0240000 Called from f00819c0, fp=12fff8, args=130168 f0258f70 f0258ed8 f0258ed0 2 130168 Called from f007ff0c, fp=130058, args=f0258c00 f0258c00 fbd54860 130168 f0258d08 f End traceback... fault and calling cmd: trap 9 sp 12f9e0 pc f0086444 npc f0086438 stopped at: kadb[0]: I think trap #9 is "data access error" but it only occurs when booting the kernel with kadb. Looks like this will need a bit more investigation. ATB, Mark. -- Mark Cave-Ayland - Senior Technical Architect PostgreSQL - PostGIS Sirius Corporation plc - control through freedom http://www.siriusit.co.uk t: +44 870 608 0063 Sirius Labs: http://www.siriusit.co.uk/labs

2 7

[PATCH] Implement new v3_memalloc romvec interface for allocating aligned memory.
by Mark Cave-Ayland 20 Apr '11

20 Apr '11

When attempting to load kadb from a Solaris 8 CD at boot, it seems that in order for kadb to allocate enough memory to load the kernel (and its modules) the /openprom/aligned-allocator property must be present with length zero. This has the additional side-effect that OpenBIOS memory allocations are redirected to a new romvec offset when this property is detected, which appears to have a similar interface to obp_dumb_memalloc() but with an extra alignment parameter. Hence we include a simple implementation which seems to be enough to be able to get kadb to load and attach to the kernel. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)siriusit.co.uk> --- openbios-devel/arch/sparc32/call-romvec.S | 1 + openbios-devel/arch/sparc32/lib.c | 28 +++++++++++++++++----------- openbios-devel/arch/sparc32/openprom.h | 5 ++++- openbios-devel/arch/sparc32/romvec.c | 2 ++ openbios-devel/arch/sparc32/romvec.h | 2 ++ openbios-devel/arch/sparc32/tree.fs | 3 +++ 6 files changed, 29 insertions(+), 12 deletions(-) diff --git a/openbios-devel/arch/sparc32/call-romvec.S b/openbios-devel/arch/sparc32/call-romvec.S index 1e8f754..dff730e 100644 --- a/openbios-devel/arch/sparc32/call-romvec.S +++ b/openbios-devel/arch/sparc32/call-romvec.S @@ -89,4 +89,5 @@ ROMVEC_HANDLER(obp_proplen) ROMVEC_HANDLER(obp_getprop) ROMVEC_HANDLER(obp_setprop) ROMVEC_HANDLER(obp_nextprop) +ROMVEC_HANDLER(obp_memalloc) diff --git a/openbios-devel/arch/sparc32/lib.c b/openbios-devel/arch/sparc32/lib.c index 01fa570..020f781 100644 --- a/openbios-devel/arch/sparc32/lib.c +++ b/openbios-devel/arch/sparc32/lib.c @@ -347,10 +347,25 @@ void ofmem_arch_early_map_pages(phys_addr_t phys, ucell virt, ucell size, ucell map_pages(phys, virt, size, mode); } -char *obp_dumb_memalloc(char *va, unsigned int size) +char *obp_memalloc(char *va, unsigned int size, unsigned int align) { phys_addr_t phys; ucell virt; + + /* Claim physical memory */ + phys = ofmem_claim_phys(-1, size, align); + + /* Claim virtual memory */ + virt = ofmem_claim_virt(pointer2cell(va), size, 0); + + /* Map the memory */ + ofmem_map(phys, virt, size, ofmem_arch_default_translation_mode(phys)); + + return cell2pointer(virt); +} + +char *obp_dumb_memalloc(char *va, unsigned int size) +{ unsigned long align; int i; @@ -371,16 +386,7 @@ char *obp_dumb_memalloc(char *va, unsigned int size) align++; } - /* Claim physical memory */ - phys = ofmem_claim_phys(-1, size, align); - - /* Claim virtual memory */ - virt = ofmem_claim_virt(pointer2cell(va), size, 0); - - /* Map the memory */ - ofmem_map(phys, virt, size, ofmem_arch_default_translation_mode(phys)); - - return cell2pointer(virt); + return obp_memalloc(va, size, align); } void obp_dumb_memfree(__attribute__((unused))char *va, diff --git a/openbios-devel/arch/sparc32/openprom.h b/openbios-devel/arch/sparc32/openprom.h index 0a2074b..0311964 100644 --- a/openbios-devel/arch/sparc32/openprom.h +++ b/openbios-devel/arch/sparc32/openprom.h @@ -135,7 +135,10 @@ struct linux_romvec { struct linux_bootargs_v2 pv_v2bootargs; struct linux_dev_v2_funcs pv_v2devops; - int filler[15]; + /* Prom version 3 memory allocation */ + char * (*v3_memalloc)(char *va, unsigned int size, unsigned int align); + + int filler[14]; /* This one is sun4c/sun4 only. */ void (*pv_setctxt)(int ctxt, char *va, int pmeg); diff --git a/openbios-devel/arch/sparc32/romvec.c b/openbios-devel/arch/sparc32/romvec.c index 843b9f4..2e154c1 100644 --- a/openbios-devel/arch/sparc32/romvec.c +++ b/openbios-devel/arch/sparc32/romvec.c @@ -508,6 +508,8 @@ init_openprom(void) fword("open-dev"); obp_fd_stdout = POP(); + romvec0.v3_memalloc = obp_memalloc_handler; + romvec0.v3_cpustart = obp_cpustart_handler; romvec0.v3_cpustop = obp_cpustop_handler; romvec0.v3_cpuidle = obp_cpuidle_handler; diff --git a/openbios-devel/arch/sparc32/romvec.h b/openbios-devel/arch/sparc32/romvec.h index d5103d1..a16115d 100644 --- a/openbios-devel/arch/sparc32/romvec.h +++ b/openbios-devel/arch/sparc32/romvec.h @@ -74,3 +74,5 @@ int obp_setprop_handler(__attribute__((unused)) int node, __attribute__((unused)) int len); const char *obp_nextprop(int node, const char *name); const char *obp_nextprop_handler(int node, const char *name); +char *obp_memalloc(char *va, unsigned int size, unsigned int align); +char *obp_memalloc_handler(char *va, unsigned int size, unsigned int align); diff --git a/openbios-devel/arch/sparc32/tree.fs b/openbios-devel/arch/sparc32/tree.fs index c0b08bd..f9a0406 100644 --- a/openbios-devel/arch/sparc32/tree.fs +++ b/openbios-devel/arch/sparc32/tree.fs @@ -125,3 +125,6 @@ finish-device " /options" find-device " disk" encode-string " boot-from" property + +" /openprom" find-device + 0 0 " aligned-allocator" property -- 1.7.2.5

2 1

[PATCH] Implement new pv_align_mem_alloc romvec interface for allocating aligned memory.
by Mark Cave-Ayland 20 Apr '11

20 Apr '11

When attempting to load kadb from a Solaris 8 CD at boot, it seems that in order for kadb to allocate enough memory to load the kernel (and its modules) the /openprom/aligned-allocator property must be present with length zero. This has the additional side-effect that OpenBIOS memory allocations are redirected to a new romvec offset when this property is detected, which appears to have a similar interface to obp_dumb_memalloc() but with an extra alignment parameter. Hence we include a simple implementation which seems to be enough to be able to get kadb to load and attach to the kernel. --- openbios-devel/arch/sparc32/call-romvec.S | 1 + openbios-devel/arch/sparc32/lib.c | 28 +++++++++++++++++----------- openbios-devel/arch/sparc32/openprom.h | 5 ++++- openbios-devel/arch/sparc32/romvec.c | 2 ++ openbios-devel/arch/sparc32/romvec.h | 2 ++ openbios-devel/arch/sparc32/tree.fs | 3 +++ 6 files changed, 29 insertions(+), 12 deletions(-) diff --git a/openbios-devel/arch/sparc32/call-romvec.S b/openbios-devel/arch/sparc32/call-romvec.S index 1e8f754..2b2dfe0 100644 --- a/openbios-devel/arch/sparc32/call-romvec.S +++ b/openbios-devel/arch/sparc32/call-romvec.S @@ -89,4 +89,5 @@ ROMVEC_HANDLER(obp_proplen) ROMVEC_HANDLER(obp_getprop) ROMVEC_HANDLER(obp_setprop) ROMVEC_HANDLER(obp_nextprop) +ROMVEC_HANDLER(obp_align_memalloc) diff --git a/openbios-devel/arch/sparc32/lib.c b/openbios-devel/arch/sparc32/lib.c index 01fa570..b975fd4 100644 --- a/openbios-devel/arch/sparc32/lib.c +++ b/openbios-devel/arch/sparc32/lib.c @@ -347,10 +347,25 @@ void ofmem_arch_early_map_pages(phys_addr_t phys, ucell virt, ucell size, ucell map_pages(phys, virt, size, mode); } -char *obp_dumb_memalloc(char *va, unsigned int size) +char *obp_align_memalloc(char *va, unsigned int size, unsigned int align) { phys_addr_t phys; ucell virt; + + /* Claim physical memory */ + phys = ofmem_claim_phys(-1, size, align); + + /* Claim virtual memory */ + virt = ofmem_claim_virt(pointer2cell(va), size, 0); + + /* Map the memory */ + ofmem_map(phys, virt, size, ofmem_arch_default_translation_mode(phys)); + + return cell2pointer(virt); +} + +char *obp_dumb_memalloc(char *va, unsigned int size) +{ unsigned long align; int i; @@ -371,16 +386,7 @@ char *obp_dumb_memalloc(char *va, unsigned int size) align++; } - /* Claim physical memory */ - phys = ofmem_claim_phys(-1, size, align); - - /* Claim virtual memory */ - virt = ofmem_claim_virt(pointer2cell(va), size, 0); - - /* Map the memory */ - ofmem_map(phys, virt, size, ofmem_arch_default_translation_mode(phys)); - - return cell2pointer(virt); + return obp_align_memalloc(va, size, align); } void obp_dumb_memfree(__attribute__((unused))char *va, diff --git a/openbios-devel/arch/sparc32/openprom.h b/openbios-devel/arch/sparc32/openprom.h index 0a2074b..5f05014 100644 --- a/openbios-devel/arch/sparc32/openprom.h +++ b/openbios-devel/arch/sparc32/openprom.h @@ -135,7 +135,10 @@ struct linux_romvec { struct linux_bootargs_v2 pv_v2bootargs; struct linux_dev_v2_funcs pv_v2devops; - int filler[15]; + /* Allocate memory to specified alignment */ + char * (*pv_align_mem_alloc)(char *va, unsigned int size, unsigned int align); + + int filler[11]; /* This one is sun4c/sun4 only. */ void (*pv_setctxt)(int ctxt, char *va, int pmeg); diff --git a/openbios-devel/arch/sparc32/romvec.c b/openbios-devel/arch/sparc32/romvec.c index 843b9f4..463181d 100644 --- a/openbios-devel/arch/sparc32/romvec.c +++ b/openbios-devel/arch/sparc32/romvec.c @@ -508,6 +508,8 @@ init_openprom(void) fword("open-dev"); obp_fd_stdout = POP(); + romvec0.pv_align_mem_alloc = obp_align_memalloc_handler; + romvec0.v3_cpustart = obp_cpustart_handler; romvec0.v3_cpustop = obp_cpustop_handler; romvec0.v3_cpuidle = obp_cpuidle_handler; diff --git a/openbios-devel/arch/sparc32/romvec.h b/openbios-devel/arch/sparc32/romvec.h index d5103d1..816109c 100644 --- a/openbios-devel/arch/sparc32/romvec.h +++ b/openbios-devel/arch/sparc32/romvec.h @@ -74,3 +74,5 @@ int obp_setprop_handler(__attribute__((unused)) int node, __attribute__((unused)) int len); const char *obp_nextprop(int node, const char *name); const char *obp_nextprop_handler(int node, const char *name); +char *obp_align_memalloc(char *va, unsigned int size, unsigned int align); +char *obp_align_memalloc_handler(char *va, unsigned int size, unsigned int align); diff --git a/openbios-devel/arch/sparc32/tree.fs b/openbios-devel/arch/sparc32/tree.fs index c0b08bd..f9a0406 100644 --- a/openbios-devel/arch/sparc32/tree.fs +++ b/openbios-devel/arch/sparc32/tree.fs @@ -125,3 +125,6 @@ finish-device " /options" find-device " disk" encode-string " boot-from" property + +" /openprom" find-device + 0 0 " aligned-allocator" property -- 1.7.2.5

2 2

[commit] r1034 - trunk/openbios-devel/arch/sparc32
by repository service 08 Apr '11

08 Apr '11

Author: mcayland Date: Fri Apr 8 11:03:59 2011 New Revision: 1034 URL: http://tracker.coreboot.org/trac/openbios/changeset/1034 Log: Enforce physical alignment based upon size for the SPARC32 romvec obp_dumb_memalloc() function. It appears that Solaris assumes that the resulting memory is physically aligned based upon the value of size. Make sure we also respect this alignment, so that memory allocated using this interface can be correctly used for the Solaris IOMMU page tables. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)siriusit.co.uk> Modified: trunk/openbios-devel/arch/sparc32/lib.c Modified: trunk/openbios-devel/arch/sparc32/lib.c ============================================================================== --- trunk/openbios-devel/arch/sparc32/lib.c Fri Feb 18 21:26:57 2011 (r1033) +++ trunk/openbios-devel/arch/sparc32/lib.c Fri Apr 8 11:03:59 2011 (r1034) @@ -351,9 +351,28 @@ { phys_addr_t phys; ucell virt; + unsigned long align; + int i; + + /* Solaris seems to assume that the returned value is physically aligned to size. For + example, not having this here causes the Solaris 8 kernel to fault because the + IOMMU page table base address is calculated incorrectly. */ + + /* Enforce a minimum alignment of CONFIG_OFMEM_MALLOC_ALIGN, and choose an alignment + which is the next power of 2 higher than the specified size */ + align = size; + if (align <= CONFIG_OFMEM_MALLOC_ALIGN) { + align = CONFIG_OFMEM_MALLOC_ALIGN; + } else { + align--; + for (i = 1; i < sizeof(unsigned long) * 8; i<<=1) { + align |= align >> i; + } + align++; + } /* Claim physical memory */ - phys = ofmem_claim_phys(-1, size, CONFIG_OFMEM_MALLOC_ALIGN); + phys = ofmem_claim_phys(-1, size, align); /* Claim virtual memory */ virt = ofmem_claim_virt(pointer2cell(va), size, 0);

1 0

[PATCH] Enforce physical alignment based upon size for the SPARC32 romvec obp_dumb_memalloc() function.
by Mark Cave-Ayland 07 Apr '11

07 Apr '11

It appears that Solaris assumes that the resulting memory is physically aligned based upon the value of size. Make sure we also respect this alignment, so that memory allocated using this interface can be correctly used for the Solaris IOMMU page tables. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)siriusit.co.uk> --- openbios-devel/arch/sparc32/lib.c | 21 ++++++++++++++++++++- 1 files changed, 20 insertions(+), 1 deletions(-) diff --git a/openbios-devel/arch/sparc32/lib.c b/openbios-devel/arch/sparc32/lib.c index 5b41dff..01fa570 100644 --- a/openbios-devel/arch/sparc32/lib.c +++ b/openbios-devel/arch/sparc32/lib.c @@ -351,9 +351,28 @@ char *obp_dumb_memalloc(char *va, unsigned int size) { phys_addr_t phys; ucell virt; + unsigned long align; + int i; + + /* Solaris seems to assume that the returned value is physically aligned to size. For + example, not having this here causes the Solaris 8 kernel to fault because the + IOMMU page table base address is calculated incorrectly. */ + + /* Enforce a minimum alignment of CONFIG_OFMEM_MALLOC_ALIGN, and choose an alignment + which is the next power of 2 higher than the specified size */ + align = size; + if (align <= CONFIG_OFMEM_MALLOC_ALIGN) { + align = CONFIG_OFMEM_MALLOC_ALIGN; + } else { + align--; + for (i = 1; i < sizeof(unsigned long) * 8; i<<=1) { + align |= align >> i; + } + align++; + } /* Claim physical memory */ - phys = ofmem_claim_phys(-1, size, CONFIG_OFMEM_MALLOC_ALIGN); + phys = ofmem_claim_phys(-1, size, align); /* Claim virtual memory */ virt = ofmem_claim_virt(pointer2cell(va), size, 0); -- 1.7.2.5

2 1

[PATCH] Enforce physical alignment based upon size for the SPARC32 romvec obp_dumb_memalloc() function.
by Mark Cave-Ayland 06 Apr '11

06 Apr '11

It appears that Solaris assumes that the resulting memory is physically aligned based upon the value of size. Make sure we also respect this alignment, so that memory allocated using this interface can be correctly used for the Solaris IOMMU page tables. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)siriusit.co.uk> --- openbios-devel/arch/sparc32/lib.c | 20 +++++++++++++++++++- 1 files changed, 19 insertions(+), 1 deletions(-) diff --git a/openbios-devel/arch/sparc32/lib.c b/openbios-devel/arch/sparc32/lib.c index 5b41dff..59cd23b 100644 --- a/openbios-devel/arch/sparc32/lib.c +++ b/openbios-devel/arch/sparc32/lib.c @@ -351,9 +351,27 @@ char *obp_dumb_memalloc(char *va, unsigned int size) { phys_addr_t phys; ucell virt; + unsigned int align, i; + + /* Solaris seems to assume that the returned value is physically aligned to size. For + example, not having this here causes the Solaris 8 kernel to fault because the + IOMMU page table base address is calculated incorrectly. */ + + /* Enforce a minimum alignment of CONFIG_OFMEM_MALLOC_ALIGN, and choose an alignment + which is the next power of 2 higher than the specified size */ + align = size; + if (align < CONFIG_OFMEM_MALLOC_ALIGN) { + align = CONFIG_OFMEM_MALLOC_ALIGN; + } else { + align--; + for (i = 1; i < sizeof(unsigned int) * 8; i<<=1) { + align = align | align >> i; + } + align++; + } /* Claim physical memory */ - phys = ofmem_claim_phys(-1, size, CONFIG_OFMEM_MALLOC_ALIGN); + phys = ofmem_claim_phys(-1, size, align); /* Claim virtual memory */ virt = ofmem_claim_virt(pointer2cell(va), size, 0); -- 1.7.2.5 -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

2 2

[PATCH] Enforce physical alignment based upon size for the SPARC32 romvec obp_dumb_memalloc() function.
by Mark Cave-Ayland 05 Apr '11

05 Apr '11

It appears that Solaris assumes that the resulting memory is physically aligned based upon the value of size. Make sure we also respect this alignment, so that memory allocated using this interface can be correctly used for the Solaris IOMMU page tables. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)siriusit.co.uk> --- openbios-devel/arch/sparc32/lib.c | 14 ++++++++++++-- 1 files changed, 12 insertions(+), 2 deletions(-) diff --git a/openbios-devel/arch/sparc32/lib.c b/openbios-devel/arch/sparc32/lib.c index 5b41dff..0219a19 100644 --- a/openbios-devel/arch/sparc32/lib.c +++ b/openbios-devel/arch/sparc32/lib.c @@ -351,9 +351,19 @@ char *obp_dumb_memalloc(char *va, unsigned int size) { phys_addr_t phys; ucell virt; - + unsigned int align; + + /* Solaris seems to assume that the returned value is physically aligned to size. For + example, not having this here causes the Solaris 8 kernel to fault because the + IOMMU page table base address is calculated incorrectly. */ + + /* Enforce a minimum alignment of CONFIG_OFMEM_MALLOC_ALIGN, and also ensure that + only the MSB is set for the alignment value. This prevents spurious + "bad alignment" warnings from OFMEM when running with CONFIG_DEBUG_OFMEM. */ + align = (size + CONFIG_OFMEM_MALLOC_ALIGN - 1) & ~(size - 1); + /* Claim physical memory */ - phys = ofmem_claim_phys(-1, size, CONFIG_OFMEM_MALLOC_ALIGN); + phys = ofmem_claim_phys(-1, size, align); /* Claim virtual memory */ virt = ofmem_claim_virt(pointer2cell(va), size, 0); -- 1.7.2.5 -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

2 2

Solaris 8: ESP device enumeration issue
by Mark Cave-Ayland 04 Apr '11

04 Apr '11

Hi all, So with the previous patch to change the initial timer values applied to SVN trunk, we now get much further on a Solaris 8 boot: Configuration device id QEMU version 1 machine id 32 CPUs: 1 x FMI,MB86904 UUID: 00000000-0000-0000-0000-000000000000 Welcome to OpenBIOS v1.0 built on Feb 17 2011 14:56 Type 'help' for detailed information 0 > boot cdrom:d -v Not a bootable ELF image Loading a.out image... Loaded 7680 bytes entry point is 0x4000 bootpath: /iommu/sbus/espdma/esp/sd@2,0:d Jumping to entry point 00004000 for type 00000005... switching to new context: Size: 259040+54154+47486 Bytes SunOS Release 5.8 Version Generic_108528-09 32-bit Copyright 1983-2001 Sun Microsystems, Inc. All rights reserved. Ethernet address = 52:54:0:12:34:56 Using default device instance data vac: enabled in write through mode mem = 131072K (0x8000000) avail mem = 110419968 root nexus = SUNW,SPARCstation-5 iommu0 at root: obio 0x10000000 sbus0 at iommu0: obio 0x10001000 dma0 at sbus0: SBus slot 5 0x8400000 dma0 is /iommu@0,10000000/sbus@0,10001000/espdma@5,8400000 /iommu@0,10000000/sbus@0,10001000/espdma@5,8400000/esp@5,8800000 (esp0): esp-options=0x46 esp0 at dma0: SBus slot 5 0x8800000 sparc ipl 4 esp0 is /iommu@0,10000000/sbus@0,10001000/espdma@5,8400000/esp@5,8800000 qemu: fatal: Trap 0x29 while interrupts disabled, Error state pc: f004127c npc: f0041280 General Registers: %g0-7: 00000000 f02441a0 04400fc1 00007000 f5af4e40 f0243b88 00000000 f0244020 Current Register Window: %o0-7: ffff8000 00008000 00000f00 044000c0 f5948688 ffebc000 fbe3a4b8 f0041be4 %l0-7: 04400fc0 f0041c78 f0041c7c 00000001 0000010f 00000001 0000002a fbe39f78 %i0-7: ffff8000 00008000 00000f00 044000c1 00000002 ffebc000 fbe3a020 f0041be4 Floating Point Registers: %f00: 000000000.000000 000000000.000000 000000000.000000 000000000.000000 %f04: 000000000.000000 000000000.000000 000000000.000000 000000000.000000 %f08: 000000000.000000 000000000.000000 000000000.000000 000000000.000000 %f12: 000000000.000000 000000000.000000 000000000.000000 000000000.000000 %f16: 000000000.000000 000000000.000000 000000000.000000 000000000.000000 %f20: 000000000.000000 000000000.000000 000000000.000000 000000000.000000 %f24: 000000000.000000 000000000.000000 000000000.000000 000000000.000000 %f28: 000000000.000000 000000000.000000 000000000.000000 000000000.000000 psr: 04000fc0 (icc: ---- SPE: SP-) wim: 00000001 fsr: 00080000 y: 00000000 Aborted From Artyom's OBP output, we can see that the next few lines that should appear on the console look like this: sd2 at esp0: target 2 lun 0 sd2 is /iommu at 0,10000000/sbus at 0,10001000/espdma at 5,8400000/esp at 5,8800000/sd at 2,0 root on /iommu at 0,10000000/sbus at 0,10001000/espdma at 5,8400000/esp at 5,8800000/sd at 2,0:b Therefore the crash is being caused by Solaris either trying to access the esp device or doing some kind of enumeration on the ESP bus. ATB, Mark. -- Mark Cave-Ayland - Senior Technical Architect PostgreSQL - PostGIS Sirius Corporation plc - control through freedom http://www.siriusit.co.uk t: +44 870 608 0063 Sirius Labs: http://www.siriusit.co.uk/labs

3 16