I pushed this bad ASSERT into the pad-gate (tested on non-debug kernel). The workaround is to use a non-debug kernel, or disabling ASSERT. The fix will push tomorrow.
panic[cpu0]/thread=fffffffffbc3b2a0: assertion failed: ms_cstate == NULL, file: ../../i86pc/os/cpupm/cpupm_mach.c, line: 476 fffffffffbc5be00 genunix:assfail+7e () fffffffffbc5be20 unix:cpupm_alloc_ms_cstate+53 () fffffffffbc5be90 unix:cpu_idle_init+161 () fffffffffbc5bed0 unix:cpupm_init+128 () fffffffffbc5bef0 unix:post_startup+87 () fffffffffbc5bf30 genunix:main+171 () fffffffffbc5bf40 unix:_locore_start+92 () Regards, Bill On 02/04/09 17:57, bugzilla-daemon at defect.opensolaris.org wrote: > http://defect.opensolaris.org/bz/show_bug.cgi?id=6379 > > > Bill Holler <bill.holler at sun.com> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Status|NEW |CAUSEKNOWN > > > > > --- Comment #1 from Bill Holler <bill.holler at sun.com> 2009-02-04 17:57:55 > --- > cpupm_next_cstate() returns uninitialized data until the first sample > period is over. The cs_next_cstate member should be initialized > in cpupm_alloc_ms_cstate(). > > The ASSERT is also wrong in cpupm_alloc_ms_cstate(). > > Proposed fix: > > void > cpupm_alloc_ms_cstate(cpu_t *cp) > { > cpupm_mach_state_t *mach_state; > cpupm_mach_acpi_state_t *ms_cstate; > > mach_state = (cpupm_mach_state_t *)(cp->cpu_m.mcpu_pm_mach_state); > ms_cstate = &mach_state->ms_cstate; > -- ASSERT(ms_cstate == NULL); > ++ ASSERT(ms_cstate->cma_state.cstate == NULL); > ms_cstate->cma_state.cstate = kmem_zalloc(sizeof (cma_c_state_t), > KM_SLEEP); > ++ ms_cstate->cma_state.cstate->cs_next_cstate = CPU_ACPI_C1; > } > >
