From: "Jan Beulich" <JBeulich@novell.com>
To: "Rafael Wysocki" <rjw@sisk.pl>, <discuss@x86-64.org>
Cc: "Andrew Morton" <akpm@osdl.org>, "Andi Kleen" <ak@suse.de>,
<linux-kernel@vger.kernel.org>
Subject: Re: 2.6.15-rc5-mm1 (x86_64-hpet-overflow.patch breaks resume from disk)
Date: Fri, 09 Dec 2005 10:15:51 +0100 [thread overview]
Message-ID: <43995957.76F0.0078.0@novell.com> (raw)
In-Reply-To: <200512082335.50417.rjw@sisk.pl>
It's a possible way to address this, but I'd rather just set a flag
indicating that the last-whatever values should not be considered (to
get into a state just like after initial boot). Jan
>>> "Rafael J. Wysocki" <rjw@sisk.pl> 08.12.05 23:35:49 >>>
Update:
On Thursday, 8 December 2005 11:53, Rafael J. Wysocki wrote:
> On Thursday, 8 December 2005 09:43, Jan Beulich wrote:
> > I don't know how resume normally handles the re-syncing of the
wall
> > clock, but the problem here is obvious: do_timer runs a loop to
> > increment jiffies, which may require significant amounts of time
> > (depending how long the system was sleeping).
> >
> > Whatever mechanism was previously used to adjust the wall clock
during
> > resume, this (a) has to happen before enabling interrupts and (b)
has to
> > communicate to the timer interrupt handler to adjust its last time
stamp
> > taken (to compare against in the next run). Clearly, the code was
broken
> > already before, as it doesn't handle the resume case (where the
HPET
> > value read is entirely unrelated to the one read during the last
timer
> > interrupt before suspend) at all, and even in the TSC timer case
it
> > simply checks whether the TSC delta is negative (which is not a
valid
> > condition, as, between the booting of the system and the OS resume
there
> > may elapse more time than the system was running altogether prior
to
> > suspend).
>
> Well, I'm not an expert, but I think I understand your
argumentation.
> However, the problem is that resume _works_ without the patch
> and doesn't work with it, which is a regression. (BTW, without
> the patch the wall clock is evidently correct after resume.)
>
> Frankly I don't know who should fix the broken code,
FWIW, I have tried to fix it myself.
The appended patch seems to work on my box, but I'm afraid
it's not the right fix (at least in general). Please advise.
Greetings,
Rafael
arch/x86_64/kernel/time.c | 15 +++++++++++++++
1 files changed, 15 insertions(+)
Index: linux-2.6.15-rc5-mm1/arch/x86_64/kernel/time.c
===================================================================
---
linux-2.6.15-rc5-mm1.orig/arch/x86_64/kernel/time.c 2005-12-08
21:39:29.000000000 +0100
+++ linux-2.6.15-rc5-mm1/arch/x86_64/kernel/time.c 2005-12-08
22:44:48.000000000 +0100
@@ -1117,6 +1117,7 @@
unsigned long sec;
unsigned long ctime = get_cmos_time();
unsigned long sleep_length = (ctime - sleep_start) * HZ;
+ long offset = 0;
if (vxtime.hpet_address)
hpet_reenable();
@@ -1125,6 +1126,20 @@
sec = ctime + clock_cmos_diff;
write_seqlock_irqsave(&xtime_lock,flags);
+ if (vxtime.hpet_address)
+ offset = hpet_readl(HPET_COUNTER);
+ if (hpet_use_timer) {
+ unsigned int hi1 = hpet64 > 0 ?
hpet_readl(HPET_COUNTER+4) : 0;
+
+ offset = hpet_readl(HPET_T0_CMP) - hpet_tick;
+ if (hpet64 > 0)
+ offset += (long)(offset >= 0 ? hi1 :
hpet_readl(HPET_COUNTER+4)) << 32;
+ else
+ offset = (unsigned int)offset;
+ }
+ if (vxtime.mode == VXTIME_HPET)
+ vxtime.last = offset;
+ rdtscll_sync(&vxtime.last_tsc);
xtime.tv_sec = sec;
xtime.tv_nsec = 0;
write_sequnlock_irqrestore(&xtime_lock,flags);
next prev parent reply other threads:[~2005-12-09 9:15 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-12-05 7:21 2.6.15-rc5-mm1 Andrew Morton
2005-12-05 6:49 ` 2.6.15-rc5-mm1 Carlos Martín
2005-12-06 3:04 ` 2.6.15-rc5-mm1 Andrew Morton
2005-12-06 6:59 ` 2.6.15-rc5-mm1 Ingo Molnar
2005-12-05 19:06 ` 2.6.15-rc5-mm1: git-alsa-vs-git-pcmcia.patch introduces new compile errors Adrian Bunk
2005-12-05 20:05 ` Takashi Iwai
2005-12-05 21:40 ` 2.6.15-rc5-mm1: USB_IP problems Adrian Bunk
2005-12-07 0:02 ` Greg KH
2005-12-07 0:08 ` Adrian Bunk
2005-12-05 23:05 ` 2.6.15-rc5-mm1 J.A. Magallon
2005-12-05 23:06 ` 2.6.15-rc5-mm1 Randy.Dunlap
2005-12-10 23:36 ` 2.6.15-rc5-mm1 Greg KH
2005-12-10 23:46 ` 2.6.15-rc5-mm1 J.A. Magallon
2005-12-11 21:36 ` 2.6.15-rc5-mm1 J.A. Magallon
2005-12-12 22:58 ` 2.6.15-rc5-mm1 Andrew Morton
2005-12-13 3:44 ` [linux-usb-devel] 2.6.15-rc5-mm1 Alan Stern
2005-12-13 13:51 ` J.A. Magallon
2005-12-13 15:35 ` Alan Stern
2005-12-13 16:47 ` David Brownell
2005-12-06 13:33 ` 2.6.15-rc5-mm1 KAMEZAWA Hiroyuki
2005-12-07 0:46 ` 2.6.15-rc5-mm1 (x86_64-hpet-overflow.patch breaks resume from disk) Rafael J. Wysocki
2005-12-07 23:15 ` Rafael J. Wysocki
2005-12-08 8:43 ` [discuss] " Jan Beulich
2005-12-08 10:53 ` Rafael J. Wysocki
2005-12-08 22:35 ` Rafael J. Wysocki
2005-12-09 9:15 ` Jan Beulich [this message]
2005-12-09 9:16 ` Andi Kleen
2005-12-09 11:20 ` Rafael J. Wysocki
2005-12-09 12:41 ` Jan Beulich
2005-12-09 13:10 ` Rafael J. Wysocki
2005-12-09 17:34 ` Rafael J. Wysocki
2005-12-12 7:58 ` Jan Beulich
2005-12-12 8:05 ` [discuss] " Andi Kleen
2005-12-08 22:47 ` Andi Kleen
2005-12-08 23:00 ` Rafael J. Wysocki
2005-12-09 9:08 ` Jan Beulich
2005-12-09 9:16 ` Andi Kleen
2005-12-09 10:57 ` Jan Beulich
2005-12-08 19:09 ` 2.6.15-rc5-mm1 Badari Pulavarty
2005-12-08 21:14 ` 2.6.15-rc5-mm1 James Courtier-Dutton
2005-12-08 23:02 ` 2.6.15-rc5-mm1 Adrian Bunk
2005-12-09 7:15 ` [Alsa-devel] 2.6.15-rc5-mm1 Jaroslav Kysela
2005-12-09 1:09 ` 2.6.15-rc5-mm1 Alexander E. Patrakov
2005-12-09 1:52 ` 2.6.15-rc5-mm1 Jeff Garzik
2005-12-12 16:12 ` 2.6.15-rc5-mm1 Alan Cox
2005-12-13 22:49 ` 2.6.15-rc5-mm1 J.A. Magallon
2005-12-13 23:24 ` 2.6.15-rc5-mm1 Andrew Morton
2005-12-14 0:17 ` 2.6.15-rc5-mm1 J.A. Magallon
2005-12-14 0:22 ` 2.6.15-rc5-mm1 Andrew Morton
2005-12-14 1:33 ` 2.6.15-rc5-mm1 Dmitry Torokhov
2005-12-14 0:31 ` 2.6.15-rc5-mm1 Ben Pfaff
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=43995957.76F0.0078.0@novell.com \
--to=jbeulich@novell.com \
--cc=ak@suse.de \
--cc=akpm@osdl.org \
--cc=discuss@x86-64.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rjw@sisk.pl \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox