From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758817AbYKWNmH (ORCPT ); Sun, 23 Nov 2008 08:42:07 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1757650AbYKWNlz (ORCPT ); Sun, 23 Nov 2008 08:41:55 -0500 Received: from ey-out-2122.google.com ([74.125.78.27]:49053 "EHLO ey-out-2122.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756717AbYKWNly (ORCPT ); Sun, 23 Nov 2008 08:41:54 -0500 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:x-mailer:mime-version :content-type:content-transfer-encoding:sender; b=i0tljhMhjzz/x9krbRb6Uh23em0ZP1KtN+FIpQN4NpRyAnpt5YCLNJnUvCVS850zi1 /36HOFexR7RSZUeYGU5mVlNfbqaFo5yJZGUR5K8Omv58qE++Nu72Q7l+hMJ+zM9ibm/e Q4Kp2FhNNUz5XUH8XsZTdf1Psnp67m7N6v+zg= Date: Sun, 23 Nov 2008 15:41:48 +0200 From: Pekka Paalanen To: Steven Rostedt Cc: Pekka Paalanen , linux-kernel , Ingo Molnar , fweisbec@gmail.com Subject: Mmiotrace regression in 2.6.28-rc6 Message-ID: <20081123154148.04e0851a@daedalus.pq.iki.fi> X-Mailer: Claws Mail 3.5.0 (GTK+ 2.12.11; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Steve, now that the NULL deref bug in ring buffer resize is gone, I found another regression. It seems I am not getting any "buffer overflow" messages anymore. Oh bummer, looks like I completely missed this one: (hope it's not in any .27 kernel) commit 3928a8a2d98081d1bc3c0a84a2d70e29b90ecf1c Author: Steven Rostedt Date: Mon Sep 29 23:02:41 2008 -0400 ftrace: make work with new ring buffer This patch ports ftrace over to the new ring buffer. Signed-off-by: Steven Rostedt Signed-off-by: Ingo Molnar <...> diff --git a/kernel/trace/trace_mmiotrace.c b/kernel/trace/trace_mmiotrace.c index a108c32..bdbf09d 100644 --- a/kernel/trace/trace_mmiotrace.c +++ b/kernel/trace/trace_mmiotrace.c <...> @@ -130,10 +130,14 @@ static unsigned long count_overruns(struct trace_iterator *iter) { int cpu; unsigned long cnt = 0; +/* FIXME: */ +#if 0 for_each_online_cpu(cpu) { cnt += iter->overrun[cpu]; iter->overrun[cpu] = 0; } +#endif + (void)cpu; return cnt; } Steve, how am I going to fix this? I think it's quite crucial to know when the dump is incomplete. There's also another issue, but I am not sure how to reproduce it. The symptom is, that echo whatever > /debug/tracing/trace_marker gets stuck in a loop, bash eats 100% CPU: 10% user, 90% system. I got that twice today, like this: after a fresh boot echoing 64, 200, 70 to trace_entries, switching between nop and mmiotrace tracers, echoing 0 or 1 to tracing_enabled, and running the testmmiotrace module. At some point the user marker got stuck. But then I tried to do that a third time by repeating some usage patterns I thought might trigger it, but it didn't happen. On the positive side, the basic test using testmmiotrace.ko with the basic setup produces the correct output. Thanks. -- Pekka Paalanen http://www.iki.fi/pq/