Liu, Jiang wrote:
> Hi Aubrey,
> Currently solaris ACPICA OSL layer uses adaptive mutex to
> implement ACPI Lock which seems not confirm to ACPICA
> programmer manual.
> Please refer to Section 7.4.5 of "ACPI Component Architecture
> Programmer Reference" as below:
>
> 7.4.5 AcpiOsCreateLock
> Functional Description:
> Create a spin lock. Spin locks are used in the ACPI CA subsystem only
> when there is requirement for mutual exclusion on data structures
> that are accessed by both interrupt handlers and normal code.
Yeah, from ACPICA manual, hardware lock must a spin lock.
Solaris OSL initialize it as MUTEX_DRIVER, which could be either
MUTEX_ADAPTIVE or MUTEX_SPIN depending on the iblock cookie.
Since iblock cookie is NULL for AcpiGbl_HardwareLock, so it's adaptive.
I think it should be initialized as MUTEX_SPIN.
Thanks,
-Aubrey
>
> Aubrey Li <> wrote:
>> On Sat, Jul 12, 2008 at 5:49 AM, Bill Holler <Bill.Holler at sun.com>
>> wrote:
>>> 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().
>>>
>>
>> I think the issue might be different.
>> The following is what idle code doing.
>> cpu_acpi_idle()
>> {
>> value = AcpiGetRegister(); /* need a lock */
>> using value to determine next idle type;
>> cli();
>> place the processor into Cx;
>> sti();
>> }
>>
>> The problem occurs in AcpiGetRegister(), it uses
>> AcpiGbl_HardwareLock. I suspect AcpiGbl_HardwareLock really works as
>> a spin lock. Otherwise it will not go into turnstiles block.
>>
>> Thanks,
>> -Aubrey
>> _______________________________________________
>> tesla-dev mailing list
>> tesla-dev at opensolaris.org
>> http://mail.opensolaris.org/mailman/listinfo/tesla-dev
> _______________________________________________
> tesla-dev mailing list
> tesla-dev at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/tesla-dev
