* Andrew Morton <[EMAIL PROTECTED]> wrote:
> But I'll sit on this patch for a while until this gets sorted out.
> Meanwhile, please double-check the elapsed-time arithmetic in there,
> maybe do a bit of runtime testing?
btw., could you apply the patch below as well? Maybe sched_clock() is
misbehaving on your box? (with this i have 5 softlockup patches in my
tree - and they are working fine so far.)
Ingo
---------------->
Subject: [patch] softlockup: use a reliable global time source
From: Ingo Molnar <[EMAIL PROTECTED]>
using sched_clock() for the soft-lockups was a bad idea, sched_clock()
is not a reliable global time-source.
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
---
kernel/softlockup.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
Index: linux/kernel/softlockup.c
===================================================================
--- linux.orig/kernel/softlockup.c
+++ linux/kernel/softlockup.c
@@ -37,13 +37,11 @@ static struct notifier_block panic_block
};
/*
- * Returns seconds, approximately. We don't need nanosecond
- * resolution, and we don't need to waste time with a big divide when
- * 2^30ns == 1.074s.
+ * Returns seconds.
*/
static unsigned long get_timestamp(void)
{
- return sched_clock() >> 30; /* 2^30 ~= 10^9 */
+ return jiffies / HZ;
}
void touch_softlockup_watchdog(void)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
