[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20081118065957.7769c8ba@infradead.org>
Date: Tue, 18 Nov 2008 06:59:57 -0800
From: Arjan van de Ven <arjan@...radead.org>
To: linux-kernel@...r.kernel.org
Cc: rjw@...k.pl, torvalds@...ux-foundation.org
Subject: [PATCH] help kerneloops.org dianogse suspend_test_finish better
Hi Linus,
please apply this patch to the 2.6.28-rc series; it will help kerneloops.org
to better diagnose the warning in suspend_test_finish(), which is currently
very hot but is lacking the essential detail of which component is causing
the badness...
From: Arjan van de Ven <arjan@...ux.intel.com>
Date: Tue, 18 Nov 2008 06:56:51 -0800
Subject: [PATCH] suspend: use WARN not WARN_ON to print the message
By using WARN(), kerneloops.org can collect which component is causing
the delay and make statistics about that. suspend_test_finish() is
currently the number 2 item but unless we can collect who's causing
it we're not going to be able to fix the hot topic ones..
Signed-off-by: Arjan van de Ven <arjan@...ux.intel.com>
---
kernel/power/main.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/kernel/power/main.c b/kernel/power/main.c
index 19122cf..b8f7ce9 100644
--- a/kernel/power/main.c
+++ b/kernel/power/main.c
@@ -174,7 +174,7 @@ static void suspend_test_finish(const char *label)
* has some performance issues. The stack dump of a WARN_ON
* is more likely to get the right attention than a printk...
*/
- WARN_ON(msec > (TEST_SUSPEND_SECONDS * 1000));
+ WARN(msec > (TEST_SUSPEND_SECONDS * 1000), "Component: %s\n", label);
}
#else
--
1.6.0.3
--
Arjan van de Ven Intel Open Source Technology Centre
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
--
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