Anthony Liguori wrote:
Alex Williamson wrote:
On Mon, 2008-02-04 at 09:11 -0600, Anthony Liguori wrote:
@@ -97,11 +100,12 @@ static void pm_update_sci(PIIX4PMState *s)
pmsts = get_pmsts(s);
sci_level = (((pmsts & s->pmen) &
(RTC_EN | PWRBTN_EN | GBL_EN | TMROF_EN)) != 0);
- qemu_set_irq(s->dev.irq[0], sci_level);
+ qemu_set_irq(s->irq, sci_level);
/* schedule a timer interruption if needed */
if ((s->pmen & TMROF_EN) && !(pmsts & TMROF_EN)) {
expire_time = muldiv64(s->tmr_overflow_time, ticks_per_sec,
PM_FREQ);
qemu_mod_timer(s->tmr_timer, expire_time);
+ s->tmr_overflow_time += 0x800000;
Hi Anthony,
I'm digging up a patch from a while back. What's the purpose of bumping
tmr_overflow_time here? It seems like this is intended to prevent the
timer overflow status from ever triggering an SCI, but that seems
contrary to the ACPI spec. I've tracked down a case where Vista is
enabling the timer overflow and appears to get stuck if it never gets
the overflow interrupt. Commenting out the last line here fixes it.
Suggestions? Thanks,
Avi is the original author of the patch I believe. Perhaps he can
shed some light on this?
This is
commit ce35c9534137b71327466fa9abc243cbe2d7e8dc
Author: Avi Kivity <[EMAIL PROTECTED]>
Date: Wed Jan 2 12:52:28 2008 +0200
kvm: qemu: fix power management timer overflow handling
The PMSTS overflow bit needs to be set each time bit 23 of the pm
timer
is toggled. This means we need to adjust the overflow time every time
we have an overflow.
Taken from qemu patch by TeLeMan in
http://www.mail-archive.com/[EMAIL PROTECTED]/msg14680.html
And, like the explanation says, we have to advance the overflow time in
order to get an interrupt. Is there something horribly broken?
--
Do not meddle in the internals of kernels, for they are subtle and quick to
panic.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
