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 15:37:57 +0100
From:	Pavel Machek <pavel@....cz>
To:	Thomas Gleixner <tglx@...utronix.de>
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

Hi!

> > I'm trying to use the "sleepy test" here, unfortunately it locks for
> > 10-or-so seconds.
> > 
> > Problem is in wait_event_timeout: timeouts take about 100x as long as
> > they should. Code in drivers/input/serio/libps2.c:
> > 
> > +       printk("ps2_command waiting event: %d\n", timeout);
> >         timeout = wait_event_timeout(ps2dev->wait,
> >                                      !(ps2dev->flags & PS2_FLAG_CMD1),timeout);
> > 
> >         if (ps2dev->cmdcnt && timeout > 0) {
> > +               printk("wait_event returned: %d\n", timeout);
> > 
> >                 timeout = ps2_adjust_timeout(ps2dev, command, timeout);
> > +
> > +               printk("ps2_command adjust timeout: %d\n", timeout);
> >                 wait_event_timeout(ps2dev->wait,
> >                                    !(ps2dev->flags & PS2_FLAG_CMD), timeout);
> >         }
> > 
> > +       printk("ps2_command receiving\n");
> > 
> > 
> > ...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().

> 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, plus "wrong for 500msec" is still wrong.

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

> > 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.

Anything that enters C2 does not.

Anything that is SMP does not.

So, how many machines do you have with working TSC?
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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/