From: Pavel Machek <pavel@ucw.cz>
To: Mikael Pettersson <mikpe@it.uu.se>
Cc: johnstul@us.ibm.com, linux-kernel@vger.kernel.org
Subject: Re: [BUG] APM resume breakage from 2.6.18-rc1 clocksource changes
Date: Mon, 10 Jul 2006 09:55:24 +0200 [thread overview]
Message-ID: <20060710075524.GB2174@elf.ucw.cz> (raw)
In-Reply-To: <200607092352.k69NqZuJ029196@harpo.it.uu.se>
On Mon 2006-07-10 01:52:35, Mikael Pettersson wrote:
> On Sun, 09 Jul 2006 14:20:56 -0700, john stultz wrote:
> >> I've traced the cause of this problem to the i386 time-keeping
> >> changes in kernel 2.6.17-git11. What happens is that:
> >> - The kernel autoselects TSC as my clocksource, which is
> >> reasonable since it's a PentiumII. 2.6.17 also chose the TSC.
> >> - Immediately after APM resumes (arch/i386/kernel/apm.c line
> >> 1231 in 2.6.18-rc1) there is an interrupt from the PIT,
> >> which takes us to kernel/timer.c:update_wall_time().
> >> - update_wall_time() does a clocksource_read() and computes
> >> the offset from the previous read. However, the TSC was
> >> reset by HW or BIOS during the APM suspend/resume cycle and
> >> is now smaller than it was at the prevous read. On my machine,
> >> the offset is 0xffffffd598e0a566 at this point, which appears
> >> to throw update_wall_time() into a very very long loop.
> >
> >Huh. It seems you're getting an interrupt before timekeeping_resume()
> >runs (which resets cycle_last). I'll look over the code and see if I can
> >sort out why it works w/ ACPI suspend, but not APM, or if the
> >resume/interrupt-enablement bit is just racy in general.
>
> I forgot to mention this, but I had a debug printk() in apm.c
> which showed that irqs_disabled() == 0 at the point when APM
> resumes the kernel.
/*
* These are the actual BIOS calls. Depending on APM_ZERO_SEGS and
* apm_info.allow_ints, we are being really paranoid here! Not only
* are interrupts disabled, but all the segment registers (except SS)
* are saved and zeroed this means that if the BIOS tries to reference
* any data without explicitly loading the segment registers, the
kernel
* will fault immediately rather than have some unforeseen
circumstances
* for the rest of the kernel. And it will be very obvious! :-)
Doing
* this depends on CS referring to the same physical memory as DS so
that
* DS can be zeroed before the call. Unfortunately, we can't do
anything
* about the stack segment/pointer. Also, we tell the compiler that
* everything could change.
*
* Also, we KNOW that for the non error case of apm_bios_call, there
* is no useful data returned in the low order 8 bits of eax.
*/
#define APM_DO_CLI \
if (apm_info.allow_ints) \
local_irq_enable(); \
else \
local_irq_disable();
...and I think allow_ints was invented because of thinkpads.. So
AFAICT you can't rely on interrupts being off and you can't rely on
interrupts being on.
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
next prev parent reply other threads:[~2006-07-10 17:32 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-07-09 23:52 Mikael Pettersson
2006-07-10 7:55 ` Pavel Machek [this message]
2006-07-10 17:58 ` john stultz
2006-07-10 18:08 ` Pavel Machek
2006-07-10 18:19 ` john stultz
2006-07-10 22:37 ` Roman Zippel
2006-07-10 22:50 ` john stultz
2006-07-10 22:59 ` Roman Zippel
2006-07-11 8:07 ` Thomas Gleixner
2006-07-11 9:29 ` Roman Zippel
2006-07-11 11:07 ` Thomas Gleixner
2006-07-11 23:31 ` Roman Zippel
2006-07-12 0:42 ` john stultz
2006-07-13 20:27 ` Thomas Gleixner
2006-07-13 22:05 ` john stultz
2006-07-14 6:56 ` Thomas Gleixner
2006-07-16 15:52 ` Roman Zippel
2006-07-16 15:50 ` Roman Zippel
2006-07-16 16:09 ` Thomas Gleixner
2006-07-16 16:15 ` Roman Zippel
2006-07-10 23:17 ` Pavel Machek
-- strict thread matches above, loose matches on Subject: below --
2006-07-10 23:36 Mikael Pettersson
2006-07-09 23:53 Mikael Pettersson
2006-07-09 20:58 Mikael Pettersson
2006-07-09 21:20 ` john stultz
2006-07-09 21:31 ` Valdis.Kletnieks
2006-07-09 21:44 ` Pavel Machek
2006-07-09 22:51 ` Alan Cox
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=20060710075524.GB2174@elf.ucw.cz \
--to=pavel@ucw.cz \
--cc=johnstul@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mikpe@it.uu.se \
/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
all inboxes | Powered by JetHome®