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]
Message-ID: <20080218143757.GB1960@elf.ucw.cz>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ