linux-kernel - Re: Reading EeePC900 battery info causes stalls (was Re: How how latent should non-preemptive scheduling be?)

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:	Sat, 20 Sep 2008 14:25:41 +0400
From:	Alexey Starikovskiy <astarikovskiy@...e.de>
To:	Sitsofe Wheeler <sitsofe@...oo.com>
CC:	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Ingo Molnar <mingo@...e.hu>,
	Arjan van de Ven <arjan@...radead.org>,
	linux-kernel@...r.kernel.org, Steven Rostedt <rostedt@...dmis.org>,
	lenb@...nel.org
Subject: Re: Reading EeePC900 battery info causes stalls (was Re: How how
 latent should non-preemptive scheduling be?)

Hi Sitsofe,

eeePC is known to be affected by EC GPE storm bug, and there is a patch for 
2.6.27 to workaround the problem. please look at
http://bugzilla.kernel.org/show_bug.cgi?id=11549
for latest patch and bugs 10724/9998 for problem discussion.

Thanks,
Alex.

Sitsofe Wheeler wrote:
> Peter Zijlstra wrote:
>> Its actually function tracer output I'm interested in.. that shows what
>> all its doing to make it take 120+ms.
> 
> I switched the tracer to ftrace and waited for the problem to occur.
> When stall did happen it was far worse than usual with the tracing on
> (instead of looping sound of < 0.5 second it looped it for about 2-3
> seconds). Looking atthe trace it was filled with hald events. Killing 
> off all of hald made the 30 second stalls go away.
> 
> A quick strace showed that what hal was doing every 30 seconds was
> reading various battery stats from /sys. Doing a simple
> cat /sys/class/power_supply/BAT0/manufacturer
> is enough to provoke a stall. The stalls only occur if you are on 
> battery or are on AC and the battery is not reporting that it is 100% 
> charged (but in the latter case the stalls are less pronounced).
> 
> I can reliably hear the stalls at runlevel 1 by running
> speaker-test -b75000
> and
> watch --interval=1 cat /proc/acpi/battery/BAT0/info
> within separate terminals within screen.
> 
> A 5 second ftrace of the stall being provoked is provided on 
> <http://sucs.org/~sits/test/eeepc-ftrace.txt.gz> (it's 6Mbytes 
> uncompressed).
> 
> Putting the alsa buffer size up to 100000 allows you to still hear
> stalls but far less frequently. Putting to 150000 will stop you from
> hearing stalls. Even though xruns is set to 2 alsa not report any buffer
> underruns to syslog.
> 
> Another way of seeing the stalls is to run glxgears and every second the
> gears' spinning will jump (even on an unloaded system).
> 
> (I guess this works as the stalls are over 100ms)
> 
> The xandros provided 2.6.21.4 kernel does not exhibit this problem at 
> all but my hand compiled 2.6.24something and ubuntu 2.6.24 kernels do.
> 
> For some reason latencytop did not really finger ACPI as a cause of
> stalls (although some acpi stuff does show up but never in the top
> spot). Is this simply a part of the kernel that latencytop does not trace?
> 
>> I thought we had a wakeup latency tracer exacty like we have preempt and
>> irq off latency tracers, Steve, where'd that go?
> 
> I rebuilt my kernel after a make clean and wakeup was still not there. 
> It might be a good idea to modify the kernel documentation currently
> provided with 2.6.27 if it has gone away for now (or document the extra
> switches needed to turn it on if that's why it didn't show up for me)...
> 
> -- 
> Sitsofe | http://sucs.org/~sits/

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