I've been trying to track down what makes ACPI kill the system in 2.4.1.
In the acpi_idle function (drivers/acpi/cpu.c), it seems to spend most
of its time with interrupts disabled, only enabling them to check
need_resched occasionally.
In the 'sleep1' state the following code is executed:
for (;;) {
unsigned long time;
unsigned long diff;
__cli();
if (current->need_resched)
goto out;
time = acpi_read_pm_timer();
safe_halt();
diff = acpi_compare_pm_timers(time, acpi_read_pm_timer());
if (diff > acpi_c2_enter_latency
&& acpi_max_c_state >= 2)
goto sleep2;
}
This looks wrong to me. It's basically looping with interrupts
disabled. I can't see how current->need_resched could be updated at
all, so the loop will only terminate when the PM timer tells it to.
Isn't disabling interrupts a bad thing anyway? Wouldn't it be better to
leave them enabled (this is uniprocessor only so there shouldn't be
concurrency issues).
Tony
--
The only secure computer is one that's unplugged, locked in a safe,
and buried 20 feet under the ground in a secret location... and i'm
not even too sure about that one"--Dennis Huges, FBI.
[email protected]
Tony Hoyle wrote:
I'm talking to myself :-)
OK I see that safe_halt() will re-enable interrupts. However this is only
called in S1. If your machine gets as far as S3 you have...
for (;;) {
unsigned long time;
unsigned long diff;
__cli();
if (current->need_resched)
goto out;
if (acpi_bm_activity())
goto sleep2;
time = acpi_read_pm_timer();
inb(acpi_pblk + ACPI_P_LVL3);
/* Dummy read, force synchronization with the PMU */
acpi_read_pm_timer();
diff = acpi_compare_pm_timers(time, acpi_read_pm_timer());
__sti();
if (diff < acpi_c3_exit_latency)
goto sleep2;
}
There is no halt here... the interrupts are enabled for only a couple of
instructions (one comparison and a jump) before being disabled again.
It seems to me if the computer gets into S3 it'll effectively die until
some kind of busmaster device wakes it up (DMA?).
The simple fix is to delete lines 332-337 of cpu.c, which disables the
idle process (and explains why I've had no slowdown on my SMP machine).
Lots of people (like me) only use ACPI for the power-off/shutdown
functionality anyway. Laptop users will probably have to wait for a
proper fix (unfortunately the ACPI4Linux mailing list looks dead - it's
just full of people complaining about 2.4.1...)
Tony
--
The only secure computer is one that's unplugged, locked in a safe,
and buried 20 feet under the ground in a secret location... and i'm
not even too sure about that one"--Dennis Huges, FBI.
[email protected]
> From: Tony Hoyle [mailto:[email protected]]
> OK I see that safe_halt() will re-enable interrupts. However
> this is only
> called in S1. If your machine gets as far as S3 you have...
I think you mean C1 and C3, but I know what you mean.. :)
[C3 code snipped]
> There is no halt here... the interrupts are enabled for only
> a couple of
> instructions (one comparison and a jump) before being disabled again.
> It seems to me if the computer gets into S3 it'll effectively
> die until
> some kind of busmaster device wakes it up (DMA?).
The problem I've had in fixing this code is that it WorksForMe(TM). I cannot
reproduce the problem on my machine (an IBM T20). That's the way the code
was, so I left it (the code I changed/broke was the C2/C3 latency calcs).
Since you have a symtomatic system, if you're willing to do some testing to
either prove or disprove your theory (that entering C2/C3 interrupts enabled
helps things) I would greatly appreciate it.
Also, the next ACPI update will let you disable using this code for idle (so
we have some breathing room while we fix it) and will print some more C
state info on boot, because although you don't say, it sounds like you have
a desktop system, which usually don't support C2/C3, and so should not be
trying to enter them.
Regards -- Andy
(ACPI maintainer)
Grover, Andrew wrote:
> Since you have a symtomatic system, if you're willing to do some testing to
> either prove or disprove your theory (that entering C2/C3 interrupts enabled
> helps things) I would greatly appreciate it.
Leaving interrupts enabled does help a little, but the machine is still
unusably slow, so it's not the fix.
> Also, the next ACPI update will let you disable using this code for idle (so
> we have some breathing room while we fix it) and will print some more C
> state info on boot, because although you don't say, it sounds like you have
> a desktop system, which usually don't support C2/C3, and so should not be
> trying to enter them.
Disabling the idle code definitely fixes it.
Tony
Hi!
> Tony Hoyle wrote:
>
> I'm talking to myself :-)
>
> OK I see that safe_halt() will re-enable interrupts. However this is only
> called in S1. If your machine gets as far as S3 you have...
>
> for (;;) {
> unsigned long time;
> unsigned long diff;
>
> __cli();
> if (current->need_resched)
> goto out;
> if (acpi_bm_activity())
> goto sleep2;
>
> time = acpi_read_pm_timer();
> inb(acpi_pblk + ACPI_P_LVL3);
> /* Dummy read, force synchronization with the PMU */
> acpi_read_pm_timer();
> diff = acpi_compare_pm_timers(time, acpi_read_pm_timer());
>
> __sti();
> if (diff < acpi_c3_exit_latency)
> goto sleep2;
> }
>
> There is no halt here... the interrupts are enabled for only a couple of
> instructions (one comparison and a jump) before being disabled again.
> It seems to me if the computer gets into S3 it'll effectively die until
> some kind of busmaster device wakes it up (DMA?).
No.
If interrupts come in cli-ed section, it will be postponed until
sti. It then comes, and sets need_resched and recovers.
Pavel
--
I'm [email protected]. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at [email protected]