Dana H. Myers wrote: > 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. I was thinking of something else. Raising the spl will not help.
>> >> 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. The ACPI interfaces need to be used to halt the processor into ACPI C2 and C3. The idle thread cannot block on a mutex because the idle thread must always be dispatch-able. It would be much simpler if the idle thread can use the ACPI interface instead of alternatives such as creating a new block-able thread to do this. AcpiGbl_HardwareLock is defined as an ACPI_"SPIN"LOCK. :-) On the other hand, changing AcpiGbl_HardwareLock does sound risky. >> 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? This is a related but different issue than the above idle thread blocking in the ACPI interfaces. The current idle loop services interrupts from the HALT state before continuing with the idle loop. CPUs in deep C-state will have to execute some code to cleanup cpu state before servicing interrupts. One option is to have the hardware return control to the idle thread with interrupts masked. Another option is to check for deep c-state cleanup in the interrupt path similar to tlb_service(). Thank you, Bill >> 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 >>> >> >
