linux-mips
[Top] [All Lists]

RE: SMTC lookup in smtc_distribute_timer

To: "linux-mips@linux-mips.org" <linux-mips@linux-mips.org>
Subject: RE: SMTC lookup in smtc_distribute_timer
From: Mikael Starvik <mikael.starvik@axis.com>
Date: Tue, 10 Nov 2009 12:45:17 +0100
Accept-language: sv-SE
Acceptlanguage: sv-SE
Cc: Jesper Nilsson <Jesper.Nilsson@axis.com>
Original-recipient: rfc822;linux-mips@linux-mips.org
Sender: linux-mips-bounce@linux-mips.org
Thread-index: Acph4gXOS/S88Vv4SZWXqV+QJhpHfwAEkyuw
Thread-topic: SMTC lookup in smtc_distribute_timer
Ok, my guess is something like this:

1. At the end of smtc_distribute_timer, nextstamp is valid and has already 
passed so we goto repeat. 
2. Nothing updates nextstamp (only updated if the timeout is in the future 
And we just decided it is in the past)
3. At the end nextstamp still has the same value so it is still valid and
in the past.
4. This repeats until read_c0_count has a value which causes nextstamp to
be in the future.

One possible patch that seams to solve it for me below. This is probably 
not the correct solution so I'll need help from the SMTC experts to review
it and come up with the correct solution.

Best Regards
/Mikael

Index: cevt-smtc.c
===================================================================
RCS file: /usr/local/cvs/linux/os/linux-2.6/arch/mips/kernel/cevt-smtc.c,v
retrieving revision 1.2
diff -u -r1.2 cevt-smtc.c
--- cevt-smtc.c 2 Sep 2009 10:07:51 -0000       1.2
+++ cevt-smtc.c 10 Nov 2009 11:40:31 -0000
@@ -223,8 +223,10 @@
                write_c0_compare(nextstamp);
                ehb();
                if ((nextstamp - (unsigned long)read_c0_count())
-                       > (unsigned long)LONG_MAX)
+                       > (unsigned long)LONG_MAX) {
+                               nextstamp = 0L;  
                                goto repeat;
+                       }
        }
 }


<Prev in Thread] Current Thread [Next in Thread>