It looks like pm_lock is only acquired when p-state coordination is CPU_ACPI_HW_ALL. Perhaps most test machines are not using hardware all. I noticed one test machine allows the BIOS to set all 3 coordination types. We need to ensure all 3 types get tested.
Bill On 02/06/09 14:45, bugzilla-daemon at defect.opensolaris.org wrote: > http://defect.opensolaris.org/bz/show_bug.cgi?id=6449 > > Summary: holding an adaptive mutex across P-state change requests > can be dangerous > Classification: Development > Product: power-mgmt > Version: unspecified > Platform: Other > OS/Version: Solaris > Status: ACCEPTED > Severity: minor > Priority: P2 > Component: PAD > AssignedTo: eric.saxe at sun.com > ReportedBy: eric.saxe at sun.com > CC: tesla-dev at opensolaris.org > > > As part of making a power state transition (e.g. P-state transition), > cpupm_state_change() grabs an adaptive lock in the cpupm_state_domains_t > structure. Because this platform routine can be invoked out of dispatcher > context (operating at DISP_LEVEL), it can not permitted to block...otherwise > recursive dispatcher entry could happen, where the kernel would quickly panic. > > I'm actually fairly surprised we haven't hit this yet. Because these locks > exist on a per power domain basis, it must be the case that the lock is fairly > non-contended (which is very good). The events which initiate P-state > transitions in event-mode are generated around atomically maintained > thresholds, so this has probably serialized things enough so that we've been > lucky. Nonetheless, this mutex should really be a MUTEX_SPIN type, since we > cannot yield the CPU. > > Maintaining DISP_LEVEL while holding the mutex will be sufficient. Higher > levels (that would block out receipt of X_CALL_HIPRI) xcalls would be > dangerous, since we could lose a race getting the lock trying to send a xcall > for a P-state change, but never allow the owner of the lock to proceed with > dropping it should the owner be trying to xcall us simultaneously at > X_CALL_HIPRI. > >
