Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 24 Jun 2004 16:12:22 -0400
From:      John Baldwin <jhb@FreeBSD.org>
To:        Matthew Dillon <dillon@apollo.backplane.com>
Cc:        Julian Elischer <julian@elischer.org>
Subject:   Re: STI, HLT in acpi_cpu_idle_c1
Message-ID:  <200406241612.22476.jhb@FreeBSD.org>
In-Reply-To: <200406241914.i5OJE7Ae054099@apollo.backplane.com>
References:  <FE045D4D9F7AED4CBFF1B3B813C85337054EC4BB@mail.sandvine.com> <200406241438.29489.jhb@FreeBSD.org> <200406241914.i5OJE7Ae054099@apollo.backplane.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday 24 June 2004 03:14 pm, Matthew Dillon wrote:
> :Nothing pending or currently executing.  Its ok for this one to be halted
> :(CPU3), but neither CPU2 nor CPU1 should be halted.  CPU2 claims to be
> :executing Xhardclock which does an EOI in < 20 instructions after it
> : starts. Does the ISR for CPU 2 clear if you let it continue for a bit?
> :
> :--
> :John Baldwin <jhb@FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
> :"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org
>
>     I wonder if something in the ACPI code is blocking - allowing queued
>     interrupts to be processed and breaking the 'cli' atomicy.  But that
>     would not explain why the ISR shows a delivered but un-EOI'd interrupt.
>
>     Another possibility is that there is some sort of required DELAY before
>     entering into HLT after calling the ACPI idle code.  It is possible
> that whatever the ACPI idle code is doing to the cpu (e.g. delayed effect
> from power management adjustments) does not take effect quickly enough and
> a real interrupt is interrupting the HLT before
>     the hw changes ACPI makes take effect.  The changes then take effect
>     in the middle of the real interrupt.  This would account for the
>     ISR state though I still don't understand how that cpu could return
>     to the HLT without EOI'ing (maybe the reported instruction address is
>     simply wrong?).
>
>     I would try adding a DELAY(10) before the hlt, just to see if it has
>     an effect.

The ACPI C1 state is just a normal hlt.  Only states >= C2 are real 
ACPI-specific states.  Gerritt, did these lockups start happening recently 
and are these boxes running -current or are they running 5.2.1?

-- 
John Baldwin <jhb@FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200406241612.22476.jhb>