I've been using the sendemail.cc config as well, but unfortunately it is
not used by stgit. If you use stgit to send patches you'll have to
copy /usr/share/stgit/templates/patchmail.tmpl to ~/.stgit and add a
'CC: patches(a)linaro.org' line to it.
I guess we should add these two tips to one of the pages under
<https://wiki.linaro.org/Mentoring/Git/>. Any suggestions?
Cheers,
On Tue, 2011-02-22 at 18:38 +0200, Amit Kucheria wrote:
> Hi,
>
> We're required to cc patches(a)linaro.org for all patches that we send
> upstream. bzr/launchpad users are already covered or will be shortly.
>
> For those using git-send-email to send patches (and you really should
> be), it might make sense to use the following command so you don't
> forget
>
> $ git config --global --add sendemail.bcc "patches(a)linaro.org"
>
> Check $HOME/.gitconfig to make sure you see "bcc = patches(a)linaro.org"
> under the [sendemail] section.
> WARNING - this will bcc patches(a)linaro.org on all patches from that
> machine sent using git-send-email.
>
> If you want more control, and your linaro work happens in a single git
> tree, you could do the following:
>
> $ cd <your linaro git tree>
> $ git config --add sendemail.bcc "patches(a)linaro.org"
>
> Check <your linaro git tree>/.git/config for the bcc entry as above.
> Now patches send from that tree will be bcc'ed to patches@linaro.
>
> /Amit
> p.s. There is also a sendemail.cc instead of sendemail.bcc in case you
> want to use that.
--
Guilherme Salgado <https://launchpad.net/~salgado>
Hi Nicolas, hi John,
during tests of hardware watchpoint support for GDB I run into a couple of
Linux kernel issues:
- On (some versions of?) Versatile Express SMP Cortex-A9 SMP boards, a CPU
errata (#720789) causes TLB flushes to sometime fail, which can lead to
random problems when running GDB in SMP mode (and probably elsewhere).
There is a kernel work-around for this problem activated by
CONFIG_ARM_ERRATA_720789, but this is unfortuantely not active on the
Linaro kernels. (On OMAP4, this happens automatically due to an entry in
mach-omap2/Kconfig. There is no such entry in mach-vexpress/Kconfig
currently.)
- On machines that do not support watchpoints (e.g. IGEP with current
kernels), this fact is not reported properly to user space. Will Deacon
posted a patch to fix this:
http://lists.infradead.org/pipermail/linux-arm-kernel/2011-February/041492.…
Can we get fixes for these issues included in the Linaro kernel (git tree
and/or packages ... not sure where the best place would be)?
Mit freundlichen Gruessen / Best Regards
Ulrich Weigand
--
Dr. Ulrich Weigand | Phone: +49-7031/16-3727
STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E.
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk
Wittkopp
Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht
Stuttgart, HRB 243294
"Will Deacon" <will.deacon(a)arm.com> wrote on 02/21/2011 06:56:13 PM:
> > > - On (some versions of?) Versatile Express SMP Cortex-A9 SMP boards,
a CPU
> > > errata (#720789) causes TLB flushes to sometime fail, which can lead
to
> > > random problems when running GDB in SMP mode (and probably
elsewhere).
> > > There is a kernel work-around for this problem activated by
> > > CONFIG_ARM_ERRATA_720789, but this is unfortuantely not active on the
> > > Linaro kernels. (On OMAP4, this happens automatically due to an
entry in
> > > mach-omap2/Kconfig. There is no such entry in mach-vexpress/Kconfig
> > > currently.)
> >
> > Could you send a patch to Russell for that?
>
> I have a patch that enables some other workarounds that we probably
> want enabled for the VE as well.
Great, thanks!
> I can CC you (Ulrich) on that if you'd prefer?
Sure, that's fine with me ...
Mit freundlichen Gruessen / Best Regards
Ulrich Weigand
--
Dr. Ulrich Weigand | Phone: +49-7031/16-3727
STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E.
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk
Wittkopp
Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht
Stuttgart, HRB 243294
Hi there,
When I am trying to use ftrace to measure cpuidle latency, I find that the
timestamp is always ending with 0000, like below.
bash-2.05b# head trace
# tracer: nop
#
# TASK-PID CPU# TIMESTAMP FUNCTION
# | | | | |
<idle>-0 [000] 79.530000: cpu_idle: state=0 cpu_id=0
<idle>-0 [000] 79.530000: cpu_idle: state=4294967295
cpu_id=0
<idle>-0 [000] 79.530000: cpu_idle: state=0 cpu_id=0
<idle>-0 [000] 79.530000: cpu_idle: state=4294967295
cpu_id=0
<idle>-0 [000] 79.530000: cpu_idle: state=0 cpu_id=0
<idle>-0 [000] 79.530000: cpu_idle: state=4294967295
cpu_id=0
But it is supposed to be more accurate like:
<idle>-0 [000] 270.396210: cpu_idle: state=4294967295 cpu_id=0
<idle>-0 [000] 270.422424: cpu_idle: state=0 cpu_id=0
<idle>-0 [000] 270.427124: cpu_idle: state=4294967295 cpu_id=0
<idle>-0 [000] 270.427185: cpu_idle: state=2 cpu_id=0
Did I miss something in kernel configuration or some certain features?
Thanks
Yong
Hi,
The ondemand delay value is calculated before calling dbs_check_cpu
which can lead to a delay value of sampling_rate*sampling_down_factor
but a frequency set to the lowest value. The main result is a slow
responsiveness during this period. This patch moves the calculation of
delay after the call of dbs_check_cpu. I have seen this problem when
testing cpufreq-bench on my Arm platform.
Vincent
On 7 February 2011 17:14, Vincent Guittot <vincent.guittot(a)linaro.org> wrote:
> calculate ondemand delay after dbs_check_cpu call because it can
> modify rate_mult value
>
> use freq_lo_jiffies value for the sub sample period of powersave_bias mode
>
> Signed-off-by: Vincent Guittot <vincent.guittot(a)linaro.org>
> ---
> drivers/cpufreq/cpufreq_ondemand.c | 20 +++++++++++++-------
> 1 files changed, 13 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/cpufreq/cpufreq_ondemand.c
> b/drivers/cpufreq/cpufreq_ondemand.c
> index 58aa85e..44c2dba 100644
> --- a/drivers/cpufreq/cpufreq_ondemand.c
> +++ b/drivers/cpufreq/cpufreq_ondemand.c
> @@ -641,13 +641,7 @@ static void do_dbs_timer(struct work_struct *work)
> container_of(work, struct cpu_dbs_info_s, work.work);
> unsigned int cpu = dbs_info->cpu;
> int sample_type = dbs_info->sample_type;
> -
> - /* We want all CPUs to do sampling nearly on same jiffy */
> - int delay = usecs_to_jiffies(dbs_tuners_ins.sampling_rate
> - * dbs_info->rate_mult);
> -
> - if (num_online_cpus() > 1)
> - delay -= jiffies % delay;
> + int delay;
>
> mutex_lock(&dbs_info->timer_mutex);
>
> @@ -660,10 +654,22 @@ static void do_dbs_timer(struct work_struct *work)
> /* Setup timer for SUB_SAMPLE */
> dbs_info->sample_type = DBS_SUB_SAMPLE;
> delay = dbs_info->freq_hi_jiffies;
> + } else {
> + /* We want all CPUs to do sampling nearly on
> + * same jiffy
> + */
> + delay = usecs_to_jiffies(dbs_tuners_ins.sampling_rate
> + * dbs_info->rate_mult);
> +
> + if (num_online_cpus() > 1)
> + delay -= jiffies % delay;
> +
> }
> +
> } else {
> __cpufreq_driver_target(dbs_info->cur_policy,
> dbs_info->freq_lo, CPUFREQ_RELATION_H);
> + delay = dbs_info->freq_lo_jiffies;
> }
> schedule_delayed_work_on(cpu, &dbs_info->work, delay);
> mutex_unlock(&dbs_info->timer_mutex);
> --
> 1.7.1
>
2011/2/21 Jason Kridner <jkridner(a)beagleboard.org>:
> How about putting it inside the [PATCH xxx], ie. "[PATCH v3 android]
> device/linaro/beagleboard: Install 0xbench native applications"? When
> I go to git.linaro.org, this would give me enough information to
> figure out to which tree this patch applied. For that matter, isn't
> "device/linaro/beagleboard" redundant as a comment within that tree?
> Why not just do "[PATCH v3 android/device/linaro/beagleboard] Install
> 0xbench native applications"?
hi Jason,
I completely agree with you. Also, your idea matches the layout of
git.linaro.org .
Thanks a lot!
-jserv
