Bill Holler wrote: > Hi Aubrey, > > I suspect we should raise the interrupt priority level high enough > for mutex_enter() to treat AcpiGbl_HardwareLock as a spin lock. > > AcpiGbl_HardwareLock is declared as an ACPI_SPINLOCK. > AcpiOsCreateLock() initializes AcpiGbl_HardwareLock as a > MUTEX_DRIVER. The mutex must be an ADAPTIVE lock. > > > What is the idle code doing with interrupts while it places the > cpu into deeper c-states with the ACPI interface? > I assume it will be like the current cpu_halt() function masks > interrupts before halting the processor? > I'd like to understand better the exposure here. It's true that AcpiOsCreateLock() uses adaptive mutexes; this hasn't appeared to present a problem in the past and I'd like to understand the specific cases where a spin mutex is truly required. Perhaps the problem is better addressed at a higher algorithmic level, for example.
> We need interrupts to be masked when the processor wakes > up, so we can fixup the local APIC state. It sounds like there's a local CPU vs. other CPU issue with respect to masking interrupts then? > > Regards, > Bill > > > Li, Aubrey wrote: >> In idle thread, to support C3, ACPI spec recommends to use several >> ACPI registers like BM_STS, etc. In solaris, we have ACPICA to read >> and write these registers. >> >> AcpiGetRegister ( >> UINT32 RegisterId, >> UINT32 *ReturnValue, >> UINT32 Flags) >> >> AcpiSetRegister ( >> UINT32 RegisterId, >> UINT32 Value, >> UINT32 Flags) >> >> The problem is, osl use mutex to lock these operation in case of the >> multiprocessor race. That means it's possible CPU1 will hit turnstiles >> block if the same time it requires the ACPI register access as CPU0. >> That will cause a ASSERT failure. (t != CPU->cpu_idle_thread); >> I think the interface in acpica need to be fixed. Or I have to implement >> another interface function in c-state driver? >> Before do that, I'll try to see if there is any better suggestions. >> >> Thanks, >> -Aubrey >> >> _______________________________________________ >> tesla-dev mailing list >> tesla-dev at opensolaris.org >> http://mail.opensolaris.org/mailman/listinfo/tesla-dev >> >
