Messages in this thread | | | Date | Mon, 18 Feb 2008 15:26:10 +0100 (CET) | From | Thomas Gleixner <> | Subject | Re: tsc breaks atkbd suspend |
| |
On Mon, 18 Feb 2008, Pavel Machek wrote: > 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 ?
> I even tried adding: > > + printk("ps2: testing timeouts\n"); > + timeout = wait_event_timeout(ps2dev->wait, 0, 10); > + printk("ps2: testing timeouts\n"); > + timeout = wait_event_timeout(ps2dev->wait, 0, 10); > + printk("ps2: testing timeouts\n"); > + timeout = wait_event_timeout(ps2dev->wait, 0, 10); > + printk("ps2: testing timeouts\n"); > + timeout = wait_event_timeout(ps2dev->wait, 0, 10); > + printk("ps2: testing timeouts\n"); > + timeout = wait_event_timeout(ps2dev->wait, 0, 10); > + printk("ps2: timeouts ok?\n"); > > before that, and yes, those wait too long, too... (but only during > suspend, they work ok during boot).
Again, at which point during suspend is this ?
> 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 ?
Also the TSC unstable detection is in a 500ms timeframe, so you should never get a 10s delay.
> I believe it is very bad idea to use tsc, it does not work on 90%+ of > machines. Yes, we do detect it is broken during runtime, but that's > too late.
Why is it too late ? Can you please describe in detail ?
> I believe fix is very simple:
NAK.
This kills TSC on machines which have a working TSC and never go into suspend.
tglx
| |