linux-kernel - Re: tsc breaks atkbd suspend

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 18 Feb 2008 16:12:40 +0100 (CET)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Pavel Machek <pavel@....cz>
cc:	kernel list <linux-kernel@...r.kernel.org>, jikos@...e.cz,
	Ingo Molnar <mingo@...e.hu>, "Rafael J. Wysocki" <rjw@...k.pl>,
	Andrew Morton <akpm@...l.org>
Subject: Re: tsc breaks atkbd suspend

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/