linux-kernel - Re: strange keyboard lag after suspend testing

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: <20070321201256.GA11560@dreamland.darkstar.lan>
Date:	Wed, 21 Mar 2007 21:12:56 +0100
From:	Luca Tettamanti <kronos.it@...il.com>
To:	Pavel Machek <pavel@....cz>
Cc:	Andreas Mohr <andi@...x01.fht-esslingen.de>, vojtech@...e.cz,
	linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>
Subject: Re: strange keyboard lag after suspend testing

Adding Thomas Gleixner to CC

Pavel Machek <pavel@....cz> ha scritto:
> Hi!
> 
>> > >> > I was testing suspend in 2.6.21-rc4 a lot, and now... machine feels
>> > >> > like someone added 50..100msec delay somewhere in keyboard
>> > >> > handling. Mouse does not seem affected. /proc/interrupts seem to
>> > >> > increase as they should, for both keyboard and mouse. Can someone
>> > >> > reproduce it? Any ideas how to debug it?
>> > >>
>> > >> Probably just asking the obvious:
>> > >> it's not a trivial "failed to re-configure repeat rate upon resume"
>> > >> (which one could rule out by running "kbdrate" again)
>> > >> but a lag in some interrupt handler or somewhere else deeper, right?
>> > >
>> > >No, it is not keyboard rate. Keyboard lags during normal typing,
>> > >sometimes letters come in groups of two or so...
>> > 
>> > I might start looking at embedded controller changes and switches. If
>> > ACPI misbehaves that could starve keyboard controller... But you
>> > said
>> 
>> Mouse _seems_ okay, but I'm not sure if I'd notice lag there.
>> 
>> > that mouse is OK... Hmm, what happens if you load evbug and type while
>> > watching syslog. Do you observe the same delays?
>> 
>> Hmm, seems that it only happens in X... so maybe it is some strange
>> scheduling artefact?
>> 
>> Hmm, something is wrong here:
>> 
>> On console, I get expected 4-5 ticks a second. In x in gnome-terminal,
>> I get this:
> 
> It gets weirder: I killed some tasks and now: (on unloaded system
> running X, notice that top latency was ~1sec at 33:09).
> 
> root@amd:~# while true ; do echo -n . ; sleep .2; date; done
> .Tue Mar 20 17:33:07 CET 2007
> .Tue Mar 20 17:33:07 CET 2007
> .Tue Mar 20 17:33:08 CET 2007
> .Tue Mar 20 17:33:08 CET 2007
> .Tue Mar 20 17:33:08 CET 2007
> .Tue Mar 20 17:33:08 CET 2007
> .Tue Mar 20 17:33:09 CET 2007
> .Tue Mar 20 17:33:10 CET 2007
> .Tue Mar 20 17:33:10 CET 2007
> .Tue Mar 20 17:33:10 CET 2007
> .Tue Mar 20 17:33:10 CET 2007
> .Tue Mar 20 17:33:10 CET 2007
> .Tue Mar 20 17:33:11 CET 2007
> .Tue Mar 20 17:33:11 CET 2007
> .Tue Mar 20 17:33:11 CET 2007
> .Tue Mar 20 17:33:12 CET 2007
> .Tue Mar 20 17:33:12 CET 2007
> 
> As soon as I load the cpu up with while1, machine starts to behave.
> 
> When I turn on bluetooth (USB), ACPI can no longer use C3, and machine
> starts to behave. Hmm?

When the CPU is in C3 the TSC and LAPIC (IIRC) are stopped, sounds like
the problem is here. Maybe after resume kernel fails to fall back to a
"safe" clocksource.

Luca
-- 
Inquietudine sintetica
Solo, davanti all'ignoto
Tienimi stretto a te
-
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/