diff options
author | Gabor Juhos <juhosg@openwrt.org> | 2011-11-13 11:26:52 +0000 |
---|---|---|
committer | Gabor Juhos <juhosg@openwrt.org> | 2011-11-13 11:26:52 +0000 |
commit | 819f6df245417fdc72ad1b3f1b49caf9c417a8bf (patch) | |
tree | 02d1026a16ab6c9e288a8a15ecbe9188e0650889 /target/linux/ar71xx/patches-2.6.39/902-fix-occasional-kernel-hangs-during-boot.patch | |
parent | 003cbe35e26efa7b1df844709a4bdeee8f21624c (diff) | |
download | master-187ad058-819f6df245417fdc72ad1b3f1b49caf9c417a8bf.tar.gz master-187ad058-819f6df245417fdc72ad1b3f1b49caf9c417a8bf.tar.bz2 master-187ad058-819f6df245417fdc72ad1b3f1b49caf9c417a8bf.zip |
ar71xx: fix occasional kernel hangs during boot on AR934x
The patch taken from the linux-mips mailing list.
The Kernel hangs occasionally during boot after
"Calibrating delay loop..". This is caused by the
c0_compare_int_usable() routine in cevt-r4k.c
returning false which causes the system to disable
the timer and hang later. The false return happens
because the routine is using a series of four calls
to irq_disable_hazard() as a delay while it waits
for the timer changes to propagate to the cp0 cause
register. On newer MIPS cores, like the 74K, the
series of irq_disable_hazard() calls turn into ehb
instructions and can take as little as a few clock
ticks for all 4 instructions. This is not enough of
a delay, so the routine thinks the timer is not
working.
This fix uses up to a max number of cycle counter
ticks for the delay and uses back_to_back_c0_hazard()
instead of irq_disable_hazard() to handle the hazard
condition between cp0 writes and cp0 reads.
git-svn-id: svn://svn.openwrt.org/openwrt/trunk@29009 3c298f89-4303-0410-b956-a3cf2f4a3e73
Diffstat (limited to 'target/linux/ar71xx/patches-2.6.39/902-fix-occasional-kernel-hangs-during-boot.patch')
-rw-r--r-- | target/linux/ar71xx/patches-2.6.39/902-fix-occasional-kernel-hangs-during-boot.patch | 104 |
1 files changed, 104 insertions, 0 deletions
diff --git a/target/linux/ar71xx/patches-2.6.39/902-fix-occasional-kernel-hangs-during-boot.patch b/target/linux/ar71xx/patches-2.6.39/902-fix-occasional-kernel-hangs-during-boot.patch new file mode 100644 index 0000000000..8150ee4810 --- /dev/null +++ b/target/linux/ar71xx/patches-2.6.39/902-fix-occasional-kernel-hangs-during-boot.patch @@ -0,0 +1,104 @@ +From patchwork Tue Nov 8 14:59:01 2011 +Content-Type: text/plain; charset="utf-8" +MIME-Version: 1.0 +Content-Transfer-Encoding: 7bit +Subject: MIPS: Kernel hangs occasionally during boot. +Date: Tue, 08 Nov 2011 13:59:01 -0000 +From: Al Cooper <alcooperx@gmail.com> +X-Patchwork-Id: 2911 +Message-Id: <1320764341-4275-1-git-send-email-alcooperx@gmail.com> +To: ralf@linux-mips.org, linux-mips@linux-mips.org, + linux-kernel@vger.kernel.org +Cc: "Al Cooper" <alcooperx@gmail.com> + +The Kernel hangs occasionally during boot after +"Calibrating delay loop..". This is caused by the +c0_compare_int_usable() routine in cevt-r4k.c returning false which +causes the system to disable the timer and hang later. The false +return happens because the routine is using a series of four calls to +irq_disable_hazard() as a delay while it waits for the timer changes +to propagate to the cp0 cause register. On newer MIPS cores, like the 74K, +the series of irq_disable_hazard() calls turn into ehb instructions and +can take as little as a few clock ticks for all 4 instructions. This +is not enough of a delay, so the routine thinks the timer is not working. +This fix uses up to a max number of cycle counter ticks for the delay +and uses back_to_back_c0_hazard() instead of irq_disable_hazard() to +handle the hazard condition between cp0 writes and cp0 reads. + +Signed-off-by: Al Cooper <alcooperx@gmail.com> + +--- +arch/mips/kernel/cevt-r4k.c | 38 +++++++++++++++++++------------------- + 1 files changed, 19 insertions(+), 19 deletions(-) + +--- a/arch/mips/kernel/cevt-r4k.c ++++ b/arch/mips/kernel/cevt-r4k.c +@@ -103,19 +103,10 @@ static int c0_compare_int_pending(void) + + /* + * Compare interrupt can be routed and latched outside the core, +- * so a single execution hazard barrier may not be enough to give +- * it time to clear as seen in the Cause register. 4 time the +- * pipeline depth seems reasonably conservative, and empirically +- * works better in configurations with high CPU/bus clock ratios. ++ * so wait up to worst case number of cycle counter ticks for timer interrupt ++ * changes to propagate to the cause register. + */ +- +-#define compare_change_hazard() \ +- do { \ +- irq_disable_hazard(); \ +- irq_disable_hazard(); \ +- irq_disable_hazard(); \ +- irq_disable_hazard(); \ +- } while (0) ++#define COMPARE_INT_SEEN_TICKS 50 + + int c0_compare_int_usable(void) + { +@@ -126,8 +117,12 @@ int c0_compare_int_usable(void) + * IP7 already pending? Try to clear it by acking the timer. + */ + if (c0_compare_int_pending()) { +- write_c0_compare(read_c0_count()); +- compare_change_hazard(); ++ cnt = read_c0_count(); ++ write_c0_compare(cnt); ++ back_to_back_c0_hazard(); ++ while (read_c0_count() < (cnt + COMPARE_INT_SEEN_TICKS)) ++ if (!c0_compare_int_pending()) ++ break; + if (c0_compare_int_pending()) + return 0; + } +@@ -136,7 +131,7 @@ int c0_compare_int_usable(void) + cnt = read_c0_count(); + cnt += delta; + write_c0_compare(cnt); +- compare_change_hazard(); ++ back_to_back_c0_hazard(); + if ((int)(read_c0_count() - cnt) < 0) + break; + /* increase delta if the timer was already expired */ +@@ -145,12 +140,17 @@ int c0_compare_int_usable(void) + while ((int)(read_c0_count() - cnt) <= 0) + ; /* Wait for expiry */ + +- compare_change_hazard(); ++ while (read_c0_count() < (cnt + COMPARE_INT_SEEN_TICKS)) ++ if (c0_compare_int_pending()) ++ break; + if (!c0_compare_int_pending()) + return 0; +- +- write_c0_compare(read_c0_count()); +- compare_change_hazard(); ++ cnt = read_c0_count(); ++ write_c0_compare(cnt); ++ back_to_back_c0_hazard(); ++ while (read_c0_count() < (cnt + COMPARE_INT_SEEN_TICKS)) ++ if (!c0_compare_int_pending()) ++ break; + if (c0_compare_int_pending()) + return 0; + |