: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_at_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. -Matt Matthew Dillon <dillon_at_backplane.com>Received on Thu Jun 24 2004 - 17:14:24 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:58 UTC