Messages in this thread | | | Date | Mon, 28 Sep 2009 09:53:22 +0800 | Subject | Re: [2.6.31-git17] WARNING: at kernel/hrtimer.c:648 hres_timers_resume+0x40/0x50()/WARNING: at drivers/base/sys.c:353 __sysdev_resume+0xc3/0xe0() | From | Yong Zhang <> |
| |
On Sun, Sep 27, 2009 at 11:46 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote: > On Sunday 27 September 2009, Yong Zhang wrote: >> On Sun, Sep 27, 2009 at 6:25 PM, Maciej Rutecki >> <maciej.rutecki@gmail.com> wrote: >> > 2009/9/27 Yong Zhang <yong.zhang0@gmail.com>: >> >> >> >> Oops, TABLE is corrupted. Please use the attachment. >> > >> > kernel/time/timekeeping.c: In function ‘timekeeping_resume’: >> > kernel/time/timekeeping.c:577: error: ‘xtime_locks’ undeclared (first >> > use in this function) >> > kernel/time/timekeeping.c:577: error: (Each undeclared identifier is >> > reported only once >> > kernel/time/timekeeping.c:577: error: for each function it appears >> > in.) >> > make[3]: *** [kernel/time/timekeeping.o] Błąd 1 >> > make[2]: *** [kernel/time] Błąd 2 >> > >> > >> > I change: >> > write_seqlock(&xtime_locks); >> > to: >> > write_seqlock(&xtime_lock); >> > >> >> Oh, typo error. >> >> > Corrected patch in attachment. >> > >> > First warning has gone, but still I have this: >> > [ 120.868049] SMP alternatives: switching to UP code >> > [ 120.872570] CPU0 attaching NULL sched-domain. >> > [ 120.872574] CPU1 attaching NULL sched-domain. >> > [ 120.872581] CPU0 attaching NULL sched-domain. >> > [ 120.872787] CPU1 is down >> > [ 120.872846] Extended CMOS year: 2000 >> > [ 120.872945] PM: Creating hibernation image: >> > [ 120.876009] PM: Need to copy 107120 pages >> > [ 120.872009] PM: Restoring platform NVS memory >> > [ 120.872009] CPU0: Thermal monitoring handled by SMI >> > [ 120.872009] Extended CMOS year: 2000 >> > [ 120.872009] ------------[ cut here ]------------ >> > [ 120.872009] WARNING: at drivers/base/sys.c:353 >> > __sysdev_resume+0xc3/0xe0() >> > [ 120.872009] Hardware name: HP Compaq nx6310 (EY501ES#AKD) >> > [ 120.872009] Interrupts enabled after timekeeping_resume+0x0/0x1c0 >> >> Irq is enabled after timekeeping_resume(), the previous patch do something >> sensible. But we even don't know when the irq is enabled. such as in >> timekeeping_resume() or before enter timekeeping_resume(). But it >> seem that this is not due to timekeeping_resume(). Instead I'm afraid >> it's caused by buggy driver. > > Interrupts are disabled by the suspend core code right before sysdev_suspend(),
You are quite right. Thanks for your clarification.
-Yong
> so device drivers cannot make this happen. One of the sysdevs is doing this. > > Thanks, > Rafael > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |