On Saturday 31 March 2007 18:51:11 Thomas Gleixner wrote:
> On Thu, 2007-03-29 at 15:46 +0200, Maxim Levitsky wrote:
> > Subject: Add suspend/resume for HPET
> > This adds support of suspend/resume on i386 for HPET
> > Signed-off-by: Maxim Levitsky <maximlevitsky@xxxxxxxxx>
> >
> > +static struct sysdev_class hpet_class = {
> > + set_kset_name("hpet"),
> > + .suspend = hpet_suspend,
> > + .resume = hpet_resume,
> > +};
> > +
> > +static struct sys_device hpet_device = {
> > + .id = 0,
> > + .cls = &hpet_class,
> > +};
>
> Sorry for being inresponsive. I was travelling and unexpectedly cut off
> from the internet for some days.
>
> While I agree in principle with the patch, I'm a bit uncomfortable. The
> sys device suspend / resume ordering is not guaranteed and relies on the
> registering order.
>
> Jeff still seems to have problems with CONFIG_NO_HZ=n and it might be
> caused by time keeping / tick management resume happening before the
> HPET resume.
>
> The required resume order is:
>
> clocksources
> timekeeping
> clockevents
> tick management
>
> I'm not sure how to do this properly with the sys device facilities, but
> I look into it.
>
> /me goes off to understand the sys device magic.
>
> tglx
>
>
>
Hi,
So maybe I was right afrer all,
Maybe it is better to add a suspend/resume hook to each clock source and call
it from timekeeping_resume() ?
Or maybe even unite clocksources with clockevents, don't know
By the way I want to report maybe a bug / maybe a feature :-) :
(sorry for long explanation)
Basically I have two clockevent sources : PIT(HPET) and APIC
(Actually I it seems that in next version of kernel HPET will be switched out
of 'legacy replacement mode' , so PIT and HPET and RTC could coexist of same system,
But HPET won't be able to generate IRQ0, and it will be assigned some IRQ, possibly shared with other devices)
APIC timer is chosen by default and works fine,
since I don't have C2/C2 states on my system (ICH8 doesn't support them :-( )
But if I force it off (nolapic_timer) HPET or PIC is chosen and strangely they are
put in _periodic_ mode although they are capable of one-shot mode
Is this a bug ?
Secondary I am getting a very strange behavior if I use CONFIG_NOHZ + !CONFIG_HIGH_RES_TIMERS
and try to suspend to ram:
System resumes, but gets crazy:
'top' shows that ksoftirqd consumes 9999 % of cpu time (this is not a typo)
And other 'normal' programs that are running show same 9999 too.
System slows to crawl.
Also I found that one of APICS is in periodic mode, and second is in one shoot mode.
And I tested this with or without my patch (thank goodness it is not my fault)
CONFIG_NOHZ + CONFIG_HIGH_RES_TIMERS work just fine.
Best regards,
Maxim Levitsky
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
