LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Pavel Machek <pavel@ucw.cz>
Cc: kernel list <linux-kernel@vger.kernel.org>,
	jikos@suse.cz, Ingo Molnar <mingo@elte.hu>,
	"Rafael J. Wysocki" <rjw@sisk.pl>, Andrew Morton <akpm@osdl.org>
Subject: Re: tsc breaks atkbd suspend
Date: Mon, 18 Feb 2008 16:12:40 +0100 (CET)	[thread overview]
Message-ID: <alpine.LFD.1.00.0802181545090.7583@apollo.tec.linutronix.de> (raw)
In-Reply-To: <20080218143757.GB1960@elf.ucw.cz>

On Mon, 18 Feb 2008, Pavel Machek wrote:
> > > ...and I get hang after "ps2_command adjust timeout" for 10 seconds,
> > > while it should  wait 10msec or so.
> > 
> > When is this code called ?
> 
> from serio_suspend. It is normal device, not a sysdev, AFAICT. 
> 
> > > nohz=off fixes that.
> > > 
> > > notsc fixes that, too... On my system (thinkpad x60 in UP mode) tsc is
> > > normally marked unstable very shortly after boot, so only sleepy test
> > > can trigger this.
> > 
> > I do not understand, what you mean. When exactly is "sleeppy test"
> > running ?
> 
> from late_initcall().

Has the system already switched to highres/nohz mode at this point ?

> > Also the TSC unstable detection is in a 500ms timeframe, so you should
> > never get a 10s delay.
> 
> I'd not expect TSC instability detection to be ran while system is
> suspending

There is nothing which switches it off, except right at the point
where the machine is shutdown. It's definitely active during the
freeze period.

> , plus "wrong for 500msec" is still wrong.

To be wrong for 500ms, the TSC must freeze completely.

> Plus TSC unstable detection is heuristic that can easily go wrong, right?

It should detect it, but I have to check, why it does not work in that
particular case.

> > > I believe fix is very simple:
> > 
> > NAK. 
> > 
> > This kills TSC on machines which have a working TSC and never go into
> > suspend.
> 
> Apart from OLPC, which machines have working TSC?
> 
> Anything that has cpufreq does not.

Wrong. Newer CPUs have TSCs which are not affected by cpu frequency.
 
> Anything that enters C2 does not.

Wrong. C3 stops the TSC everywhere. C2 should not, but it does
unfortunately due to stupid BIOS implementations and on a lot of AMD
CPUs.

> Anything that is SMP does not.

Wrong. I'm writing this mail from a SMP machine with perfectly
sychronized TSCs.

> So, how many machines do you have with working TSC?

At least 5.

One sensible solution would be to force TSC unstable before we
suspend, but I'd like to know why that 10sec delay happens at all.

Can you please provide a dmesg log ?

Thanks,

	tglx

  reply	other threads:[~2008-02-18 15:13 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-18 13:38 Pavel Machek
2008-02-18 14:26 ` Thomas Gleixner
2008-02-18 14:37   ` Pavel Machek
2008-02-18 15:12     ` Thomas Gleixner [this message]
2008-02-19  9:20       ` Pavel Machek
2008-02-19  9:37       ` Pavel Machek
2008-02-19 10:00       ` Pavel Machek
2008-02-19 14:05         ` Ingo Molnar
2008-02-19 16:51           ` Thomas Gleixner
2008-02-20  0:17             ` Len Brown
2008-02-20  6:51               ` Thomas Gleixner
2008-02-19 10:02       ` notsc is ignored on common configurations Pavel Machek
2008-02-19 11:26         ` Ingo Molnar
2008-02-19 11:29           ` Pavel Machek

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=alpine.LFD.1.00.0802181545090.7583@apollo.tec.linutronix.de \
    --to=tglx@linutronix.de \
    --cc=akpm@osdl.org \
    --cc=jikos@suse.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=pavel@ucw.cz \
    --cc=rjw@sisk.pl \
    --subject='Re: tsc breaks atkbd suspend' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).