Thanks, that was useful information. I now have a stacktrace from the kernal debug.
kaif_enter+7() kdi_dvec_enter+0xd() debug_enter+0x27(fec08f08) panicsys+0x315(fe9ac298, fec35b4c, fec3a564, 1) vpanic+0xdb() panic+0x12(fe9ac298, d9004690, d938a388, 0) vmem_hash_delete+0xd1(d9004690, d938a388, 0) vmem_xfree_+0x2b(d9004690, d938a388, 0) vmem_free+0x1e(d9004690, d938a388, 0) kmem_free+0x36() acpica'AcpiOsFree+0x14() acpica'AcpiUtFreeAndTrack+0x61(d938a3b4, 1, fecaae84, d7) acpica'AcpiOsPurgeCache+0x37(d9117f0c) acpica'AcpiInitializeObjects+0xdf(0) acpica'acpica_init+0x69() acpica'acpi_isa_device_enum+0x96(d9389c68) isa'isa_alloc_nodes+0xf0(d9389c68) isa'isa_attach+0x35(d9389c68, 0) devi_attach+0x6c(d9389c68, 0) attach_node+0x81(d9389c68) i_ndi_config_node+0x84(d9389c68, 6, 0) i_ddi_attachchild+0x48(d9389c68) i_ddi_attach_node_hierarchy+0x4b(d9389c68) attach_driver_nodes+0x4c(78) i_ddi_attach_pseudo_node+0x1f(fec07540) configure+0x3a() startup_end+0x47() startup+0x3a() main+0x1e() That was the stack trace, when I dump the msgbuf I find this: Parsing all Control Methods: Table [SSDT](id 61) - 1 Objects with 0 Devices 1 Methods 0 Regions .. 82 Devices found - executed 0 _STA, 4 _INI methods panic[cpu0]/thread=fec1f820: vmem_hash_delete(d9004690, d9389a388, 0): bad free And last but not least the debug status displays the following debugging live kernel (32-bit) on (not set) operating system: 5.11 snv_36 (i86pc) CPU-specific support: Intel Pentium M DTrace state: inactive stopped on: debugger entry trap I hope this can help give information that someone can find helpful for getting this working. I am not sure what specifically is going on. This message posted from opensolaris.org
