Hi Thomas,
I haven't tested it much till now. I am sending this patch just to check if the
initial idea looks fine to you guys or not.
Till now, we weren't migrating a running timer because with migration
del_timer_sync() can't detect that the timer's handler yet has not finished.
Now, when can we actually to reach to the code (inside __mod_timer()) where
base->running_timer == timer ? i.e. We are trying to migrate current timer
I can see only following case:
- Timer re-armed itself. i.e. Currently we are running interrupt handler of a
timer and it rearmed itself from there. At this time user might have called
del_timer_sync() or not. If not, then there is no harm in re-arming the timer?
Now, when somebody tries to delete a timer, obviously he doesn't want to run it
any more for now. So, why should we ever re-arm a timer, which is scheduled for
deletion?
This patch tries to fix "migration of running timer", assuming above theory is
correct :)
So, now when we get a call to del_timer_sync(), we will mark it scheduled for
deletion in an additional variable. This would be checked whenever we try to
modify/arm it again. If it was currently scheduled for deletion, we must not
modify/arm it.
And so, whenever we reach to the situation where:
base->running_timer == timer
We are sure, nobody is waiting in del_timer_sync().
We will clear this flag as soon as the timer is deleted, so that it can be
started again after deleting it successfully.
Waiting for initial comments on it.
Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org>
---
include/linux/timer.h | 1 +
kernel/timer.c | 58 +++++++++++++++++++++++++++++----------------------
2 files changed, 34 insertions(+), 25 deletions(-)
diff --git a/include/linux/timer.h b/include/linux/timer.h
index 8c5a197..ea36ce9 100644
--- a/include/linux/timer.h
+++ b/include/linux/timer.h
@@ -22,6 +22,7 @@ struct timer_list {
unsigned long data;
int slack;
+ int sched_del;
#ifdef CONFIG_TIMER_STATS
int start_pid;
diff --git a/kernel/timer.c b/kernel/timer.c
index 1cf8a91..536e7a3 100644
--- a/kernel/timer.c
+++ b/kernel/timer.c
@@ -620,6 +620,7 @@ static void do_init_timer(struct timer_list *timer, unsigned int flags,
timer->entry.next = NULL;
timer->base = (void *)((unsigned long)base | flags);
timer->slack = -1;
+ timer->sched_del = 0;
#ifdef CONFIG_TIMER_STATS
timer->start_site = NULL;
timer->start_pid = -1;
@@ -727,38 +728,35 @@ __mod_timer(struct timer_list *timer, unsigned long expires,
base = lock_timer_base(timer, &flags);
+ if (timer->sched_del) {
+ /* Don't schedule it again, as it is getting deleted */
+ ret = -EBUSY;
+ goto out_unlock;
+ }
+
ret = detach_if_pending(timer, base, false);
if (!ret && pending_only)
goto out_unlock;
debug_activate(timer, expires);
- /*
- * Should we try to migrate timer?
- * However we can't change timer's base while it is running, otherwise
- * del_timer_sync() can't detect that the timer's handler yet has not
- * finished. This also guarantees that the timer is serialized wrt
- * itself.
- */
- if (likely(base->running_timer != timer)) {
#if defined(CONFIG_NO_HZ) && defined(CONFIG_SMP)
- if (!pinned && get_sysctl_timer_migration())
- cpu = get_nohz_timer_target();
- else
- cpu = smp_processor_id();
-#else
+ if (!pinned && get_sysctl_timer_migration())
+ cpu = get_nohz_timer_target();
+ else
cpu = smp_processor_id();
+#else
+ cpu = smp_processor_id();
#endif
- new_base = per_cpu(tvec_bases, cpu);
-
- if (base != new_base) {
- /* See the comment in lock_timer_base() */
- timer_set_base(timer, NULL);
- spin_unlock(&base->lock);
- base = new_base;
- spin_lock(&base->lock);
- timer_set_base(timer, base);
- }
+ new_base = per_cpu(tvec_bases, cpu);
+
+ if (base != new_base) {
+ /* See the comment in lock_timer_base() */
+ timer_set_base(timer, NULL);
+ spin_unlock(&base->lock);
+ base = new_base;
+ spin_lock(&base->lock);
+ timer_set_base(timer, base);
}
timer->expires = expires;
@@ -1037,9 +1035,11 @@ EXPORT_SYMBOL(try_to_del_timer_sync);
*/
int del_timer_sync(struct timer_list *timer)
{
-#ifdef CONFIG_LOCKDEP
+ struct tvec_base *base;
unsigned long flags;
+#ifdef CONFIG_LOCKDEP
+
/*
* If lockdep gives a backtrace here, please reference
* the synchronization rules above.
@@ -1049,6 +1049,12 @@ int del_timer_sync(struct timer_list *timer)
lock_map_release(&timer->lockdep_map);
local_irq_restore(flags);
#endif
+
+ /* Timer is scheduled for deletion, don't let it re-arm itself */
+ base = lock_timer_base(timer, &flags);
+ timer->sched_del = 1;
+ spin_unlock_irqrestore(&base->lock, flags);
+
/*
* don't use it in hardirq context, because it
* could lead to deadlock.
@@ -1056,8 +1062,10 @@ int del_timer_sync(struct timer_list *timer)
WARN_ON(in_irq() && !tbase_get_irqsafe(timer->base));
for (;;) {
int ret = try_to_del_timer_sync(timer);
- if (ret >= 0)
+ if (ret >= 0) {
+ timer->sched_del = 0;
return ret;
+ }
cpu_relax();
}
}
--
1.7.12.rc2.18.g61b472e
Hello,
I recently acquired a Gumstix Overo Water with a Tobi and decided to put
Node.js on it to turn it into a web server of sorts.
The build dies with an "Illegal instruction" error, and I am thoroughly
confused.
In order to set up the build, I did the following:
1. imaged a microSD card with the Linaro binaries indicated by
http://wiki.gumstix.org/index.php?title=Installing_Linaro_Image
2. booted
3. dd'd/enabled 200MB of swap on the SD card
4. apt-get update/upgrade everything
5. installed various development dependencies (git, libc6-dev, g++, and
many others)
6. cloned Joyent's repo.
7. modified `wscript` in the repo with V8-specific changes for ARM
(including enabling hard-float) (modified the scons invocation in v0.8)
8. ./configure
8. make
9. observed 'illegal instruction' death in the make process:
/root/node/deps/v8/src/arguments.h: In constructor
'v8::internal::CustomArguments::CustomArguments(v8::internal::Isolate*,
v8::internal::Object*, v8::internal::Object*, v8::internal::JSObject*)':
/root/node/deps/v8/src/arguments.h:93:65: internal compiler error: Illegal
instruction
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-4.6/README.Bugs> for instructions.
The bug is not reproducible, so it is likely a hardware or OS problem.
scons: *** [obj/release/runtime-profiler.o] Error 1
scons: building terminated because of errors.
If I restart the build, it works fine for a while (including rebuilding the
object it died building) then dies again. A different portion of the build
is running and it usually receives a segfault:
[ 9/35] cxx: src/node_javascript.cc -> out/Release/src/node_javascript_5.o
/usr/bin/g++ -pthread -g -O3 -DHAVE_OPENSSL=1 -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -DHAVE_FDATASYNC=1 -DARCH="arm" -DPLATFORM="linux"
-D__POSIX__=1 -Wno-unused-parameter -D_FORTIFY_SOURCE=2 -IRelease/src
-I../src -IRelease/deps/http_parser -I../deps/http_parser
-IRelease/deps/uv/include -I../deps/uv/include -IRelease/deps/uv/src/ares
-I../deps/uv/src/ares -IRelease/deps/v8/include -I../deps/v8/include
-Ideps/v8/include ../src/node_javascript.cc -c -o
Release/src/node_javascript_5.o
g++: internal compiler error: Segmentation fault (program as)
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-4.6/README.Bugs> for instructions.
Waf: Leaving directory `/root/node/out'
I am confused. I've made a few observations about my setup:
* Thinking that it might be a thermal problem because it was under heavy
load at 600MHz in open air, I dug out a small heat sink, attached it, and
pointed a small fan at it. It now runs cool to the touch. I still get the
same 'illegal instruction' deaths under load.
* Usually three invocations of 'make' are required before it actually
finishes, but it does finish. I can run the command-line interpreter and it
seems to behave inasmuch as I've used it.
* 'make test' fails, but I think that's a Node.js/ARM problem.
* I run htop to monitor the build, and sometimes the build system works
fine while htop dies with an 'illegal instruction' error.
* Node.js on ARM is presently somewhat sticky, so I checked out the v0.6.6
tag. v0.6.18 encounters the same problem. v0.8.9 simply segfaults instead.
* I have an Overo Water (GS3503W-R2889) on a Tobi.
* MLO version: I haven't the foggiest, but I get the U-Boot version string
twice, once being before u-boot.bin is loaded.
* U-Boot 2012.04.01 (Jul 19 2012 - 17:31:34)
* I moved the SD card to a different Water/Tobi pair and I got the same
error (illegal instruction, Node.js v0.8.9)
It feels like a task swapping bug in the kernel. Perhaps it's related to
errata on the OMAP3530. It could also be read timeouts from the swap file
on the SD card, though dmesg doesn't say anything of the sort. I found a
kernel patch regarding inconsistent caches on ARM, but it hit in 2.6.33 and
I'm running 3.2.1.
Has anyone seen something like this?
Would anyone be willing to replicate the problem? I'd be happy to share my
tweaks to Node.js' build system to get it to build.
Thanks for reading!
Jon Kunkee
The bootwrapper is really doubling as firmware, so it doesn't make
sense for it to drop out of the Secure World before getting a
chance to parse its parameters and configuration.
Instead, it should make sense to delay switching to the Normal
World for as long as possible so that we have a chance to do any
required firmware-level configuration in the Secure World first.
This quick hack is ***completely untested***, since I'm not working
with any suitable kernel tree right now.
If someone with a KVM tree ready to run could give it a try,
that would definitely save me some time.
Review also welcome (naturally)
Changes since v1:
* Don't rely on preservation of lr or sp across enter_hyp (this
doesn't work because those registers are banked per-mode).
I'm still not convinced this series works, due image/model/dtb
mismatches in my testing, but execution at least reaches the kernel
now.
Cheers
---Dave
Dave Martin (3):
bootwrapper: Fix misaligned Hyp mode vector table
bootwrapper: Refactor entry into Hyp mode to be more reusable
bootwrapper: Delay switch to Hyp mode until kernel entry
boot.S | 58 +++++++++++++++++++++++++++++++++++++-------------------
semi_loader.h | 6 +++-
2 files changed, 42 insertions(+), 22 deletions(-)
--
1.7.4.1
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Dave Martin (3):
bootwrapper: Fix misaligned Hyp mode vector table
bootwrapper: Refactor entry into Hyp mode to be more reusable
bootwrapper: Delay switch to Hyp mode until kernel entry
boot.S | 58 +++++++++++++++++++++++++++++++++++++-------------------
semi_loader.h | 6 +++-
2 files changed, 42 insertions(+), 22 deletions(-)
--
1.7.4.1
Hi there
I'm looking for the correct RT patch (http://www.kernel.org/pub/linux/kernel/projects/rt/) for a Linaro Linux source. Just for a start I tried with linux-linaro-3.4-2012.05-1 with the RT patch patch-3.4-rc2-rt1.patch.bz2 and got some build errors due to undeclared methods/variables. I would like to ask which of these two (linaro-linux and RT patch) goes together ?
ps. I checked out question http://ask.linaro.org/questions/336/do-real-time-patches-work-on-ubuntu-bui… and am wondering if that describes it or what ?
Regards
Einar M. Bjorgvinsson
Embedded Software Engineer
Marel ehf.
Iceland
Currently we don't support migration of currently running timers. Current code
flow in __mod_timer() is:
- Find a cpu where we should migrate the timer
- Check if timer is currently running
- If yes, don't migrate.
In this process, the first step is a unnecessary activiy, if the timer is
currently running. This patch tries to avoid it in such cases.
Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org>
---
kernel/timer.c | 26 +++++++++++++-------------
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/kernel/timer.c b/kernel/timer.c
index 8c5e7b9..6e5bf98 100644
--- a/kernel/timer.c
+++ b/kernel/timer.c
@@ -755,23 +755,23 @@ __mod_timer(struct timer_list *timer, unsigned long expires,
debug_activate(timer, expires);
- cpu = smp_processor_id();
+ /*
+ * Should we try to migrate timer?
+ * However we can't change timer's base while it is running, otherwise
+ * del_timer_sync() can't detect that the timer's handler yet has not
+ * finished. This also guarantees that the timer is serialized wrt
+ * itself.
+ */
+ if (likely(base->running_timer != timer)) {
+ cpu = smp_processor_id();
#if defined(CONFIG_NO_HZ) && defined(CONFIG_SMP)
- if (!pinned && get_sysctl_timer_migration() && idle_cpu(cpu))
- cpu = get_nohz_timer_target();
+ if (!pinned && get_sysctl_timer_migration() && idle_cpu(cpu))
+ cpu = get_nohz_timer_target();
#endif
- new_base = per_cpu(tvec_bases, cpu);
+ new_base = per_cpu(tvec_bases, cpu);
- if (base != new_base) {
- /*
- * We are trying to schedule the timer on the local CPU.
- * However we can't change timer's base while it is running,
- * otherwise del_timer_sync() can't detect that the timer's
- * handler yet has not finished. This also guarantees that
- * the timer is serialized wrt itself.
- */
- if (likely(base->running_timer != timer)) {
+ if (base != new_base) {
/* See the comment in lock_timer_base() */
timer_set_base(timer, NULL);
spin_unlock(&base->lock);
--
1.7.12.rc2.18.g61b472e
For people trying to build Linaro Android 12.08 there's an issue with an
unknown reference in powertop2.0.
Here's what to do:
cd android
edit .repo/manifest.xml
Find:
<project groups="path:external/powertop,name:tools/powertop-2.0"
name="tools/powertop-2.0" path="exter\
nal/powertop" remote="linaro-other"
revision="c80f55d9d1b823b7f6ff447eefc8a6ba04b939c4"/>
...and remove the line. Then
cp .repo/manifest.xml ../
cd ..
rm -rf android/
edit linaro_android_build_cmds.sh
and change
curl -k
http://snapshots.linaro.org/android/~linaro-android/vexpress-jb-gcc47-armlt…
>
.repo/manifest.xml
to
cp ../manifest.xml .repo/
and rerun linaro_android_build_cmds.sh
You can also take a tip build which is not susceptible to this problem. Tip
builds that have been booted are listed at:
https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AnpUtxWjZbP9dGg0d…
If you still get errors after this, then its a general git timeout error.
Just delete the android/ directory and start again or cd android/; repo
./sync
--
Zach Pfeffer
Android Platform Team Lead, Linaro Platform Teams
Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linarohttp://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
This patchset adds support for AArch64 in all required classes:
- insane
- kernel-arch
- siteinfo
Everything is from public available information (binutils, linux).