hi,
first of all, this isn't meant to be a distro trolling discussion, there
are better places for that ;-)
several days ago google HO started to fail after updating my debian/sid
setup. as discussed on G+ [1] and on googlegroups [2], that seemed to be
impacting anyone on debian/sid. when i realized that it was working on
debian/testing (Jessie) i decided just use 'testing'... however since last
evening update on 'testing', it started to fail too.. leaving me without
any working HO at all, which is quite inconvenient at Linaro..
after bisecting my system using snapshot.debian.org, i figured out which
package was the culprit:
# apt-cache policy libcairo2
libcairo2:
Installed: 1.12.14-4
Candidate: 1.12.14-4
Package pin: 1.12.14-4
Version table:
1.12.16-2 1001
500 http://ftp.fr.debian.org/debian/ testing/main amd64 Packages
*** 1.12.14-4 1001
500 http://snapshot.debian.org/archive/debian/20130927T214600Z/testing/main
amd64 Packages
100 /var/lib/dpkg/status
Simply downgrading libcairo2 [3] 'fixes' the problem. I know it's not
'fixing' it really, but i hope that this will be enough information so that
the real fix is uploaded.
In the mean time, if any of use use Debian , you can use that as a
workaround..
cheers
nico
[1] https://plus.google.com/u/0/108790110407014289037/posts/5q22d1ReavG
[2] https://productforums.google.com/d/msg/hangouts/vYsaeEnXJXs/hOy2HaW5LKoJ
[3]
http://snapshot.debian.org/archive/debian/20130927T214600Z/pool/main/c/cair…
Hello,
I'm new to linaro. so this posting is also to ensure
my listserv access is allowing me to post.
What I was expecting is a matrix to allow new devs to quickly
glean features and decide which boards to purchase or recommend
to clients to purchase, for rapid prototyping.
Since Linaro is flapping loudly about Grub2, I should think
that support for the modern file systems on the 64 Bit arm
offerings would abound, such as ZFS, CEPH, GlusterFS, etc etc.
Anyone clustering arm dev boards into something big? Sharing knowledge?
I've been reading, but I have not found many different boards that are
supported. OK. Maybe folks are working on boards from TI, Freescale
and the other big vendors, but do not list the boards on Linaro? If
so, where would these repositories be located. For example here are a
few boards, built/offered by members of the Linaro alliance, yet I find
no embedded linux repositories for 64 bit systems and modern file
systems, clustering nor distributed applications ?
I did find Arndale 5250 support and a bunch of lesser processors
and NO SATA3 support:
https://wiki.linaro.org/Boards
Mote:
http://www.linaro.org/engineering/getting-started/low-cost-development-boar…
TI:
http://www.phytec.com/products/system-on-modules/phycore/omap5430/http://www.variscite.com/products/system-on-module-som/cortex-a15/var-som-o…http://www.ti.com/tool/omap5432-evm?DCMP=omap-5432evm-130521&HQS=omap-5432e…
You guys are kidding right? Or are the big vendors just here
for promotional (fluff) reasons?
curiously perplexed,
James
Hi,
What is a raw spin lock made by the call: DEFINE_RAW_SPINLOCK
When someone locks - it just keeps looping until it 0 & then set it to 1
and when someone unlocks it makes it 0.
is this how this works?
/Ryan
Hi All,
This is V2 Resend of my sched_select_cpu() work. Resend because didn't got much
attention on V2. Including more guys now in cc :)
In order to save power, it would be useful to schedule work onto non-IDLE cpus
instead of waking up an IDLE one.
To achieve this, we need scheduler to guide kernel frameworks (like: timers &
workqueues) on which is the most preferred CPU that must be used for these
tasks.
This patchset is about implementing this concept.
- The first patch adds sched_select_cpu() routine which returns the preferred
cpu which is non-idle.
- Second patch removes idle_cpu() calls from timer & hrtimer.
- Third patch is about adapting this change in workqueue framework.
- Fourth patch add migration capability in running timer
Earlier discussions over v1 can be found here:
http://www.mail-archive.com/linaro-dev@lists.linaro.org/msg13342.html
Earlier discussions over this concept were done at last LPC:
http://summit.linuxplumbersconf.org/lpc-2012/meeting/90/lpc2012-sched-timer…
Module created for testing this behavior is present here:
http://git.linaro.org/gitweb?p=people/vireshk/module.git;a=summary
Following are the steps followed in test module:
1. Run single work on each cpu
2. This work will start a timer after x (tested with 10) jiffies of delay
3. Timer routine queues a work... (This may be called from idle or non-idle cpu)
and starts the same timer again STEP 3 is done for n number of times (i.e.
queuing n works, one after other)
4. All works will call a single routine, which will count following per cpu:
- Total works processed by a CPU
- Total works processed by a CPU, which are queued from it
- Total works processed by a CPU, which aren't queued from it
Setup:
-----
- ARM Vexpress TC2 - big.LITTLE CPU
- Core 0-1: A15, 2-4: A7
- rootfs: linaro-ubuntu-nano
Results:
-------
Without Workqueue Modification, i.e. PATCH 3/3:
[ 2493.022335] Workqueue Analyser: works processsed by CPU0, Total: 1000, Own: 0, migrated: 0
[ 2493.047789] Workqueue Analyser: works processsed by CPU1, Total: 1000, Own: 0, migrated: 0
[ 2493.072918] Workqueue Analyser: works processsed by CPU2, Total: 1000, Own: 0, migrated: 0
[ 2493.098576] Workqueue Analyser: works processsed by CPU3, Total: 1000, Own: 0, migrated: 0
[ 2493.123702] Workqueue Analyser: works processsed by CPU4, Total: 1000, Own: 0, migrated: 0
With Workqueue Modification, i.e. PATCH 3/3:
[ 2493.022335] Workqueue Analyser: works processsed by CPU0, Total: 1002, Own: 999, migrated: 3
[ 2493.047789] Workqueue Analyser: works processsed by CPU1, Total: 998, Own: 997, migrated: 1
[ 2493.072918] Workqueue Analyser: works processsed by CPU2, Total: 1013, Own: 996, migrated: 17
[ 2493.098576] Workqueue Analyser: works processsed by CPU3, Total: 998, Own: 993, migrated: 5
[ 2493.123702] Workqueue Analyser: works processsed by CPU4, Total: 989, Own: 987, migrated: 2
V2->V2-Resend
-------------
- Included timer migration patch in the same thread.
V1->V2
-----
- New SD_* macros removed now and earlier ones used
- sched_select_cpu() rewritten and it includes the check on current cpu's
idleness.
- cpu_idle() calls from timer and hrtimer removed now.
- Patch 2/3 from V1, removed as it doesn't apply to latest workqueue branch from
tejun.
- CONFIG_MIGRATE_WQ removed and so is wq_select_cpu()
- sched_select_cpu() called only from __queue_work()
- got tejun/for-3.7 branch in my tree, before making workqueue changes.
Viresh Kumar (4):
sched: Create sched_select_cpu() to give preferred CPU for power
saving
timer: hrtimer: Don't check idle_cpu() before calling
get_nohz_timer_target()
workqueue: Schedule work on non-idle cpu instead of current one
timer: Migrate running timer
include/linux/sched.h | 16 ++++++++++--
include/linux/timer.h | 2 ++
kernel/hrtimer.c | 2 +-
kernel/sched/core.c | 69 +++++++++++++++++++++++++++++++--------------------
kernel/timer.c | 50 ++++++++++++++++++++++---------------
kernel/workqueue.c | 4 +--
6 files changed, 91 insertions(+), 52 deletions(-)
--
1.7.12.rc2.18.g61b472e
I have tried this:
$ make CROSS_COMPILE=arm-linux-gnueabihf- distclean
$ make CROSS_COMPILE=arm-linux-gnueabihf- zynq_zed_config
$ make CROSS_COMPILE=arm-linux-gnueabihf-
and that failed with:
arm-linux-gnueabihf-ld.bfd: error:
/opt/gcc-linaro-arm-linux-gnueabihf-4.8-2013.09_linux/bin/../lib/gcc/arm-linux-gnueabihf/4.8.2/libgcc.a(_udivdi3.o)
uses VFP register arguments, u-boot does not
arm-linux-gnueabihf-ld.bfd: failed to merge target specific data of file
/opt/gcc-linaro-arm-linux-gnueabihf-4.8-2013.09_linux/bin/../lib/gcc/arm-linux-gnueabihf/4.8.2/libgcc.a(_udivdi3.o)
So I tried this:
$ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- distclean
$ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- zynq_zed_config
$ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf-
and that failed differently:
arm-linux-gnueabihf-ld.bfd: error:
/opt/gcc-linaro-arm-linux-gnueabihf-4.8-2013.09_linux/bin/../lib/gcc/arm-linux-gnueabihf/4.8.2/libgcc.a(_udivdi3.o)
uses VFP register arguments, u-boot does not
arm-linux-gnueabihf-ld.bfd: failed to merge target specific data of file
/opt/gcc-linaro-arm-linux-gnueabihf-4.8-2013.09_linux/bin/../lib/gcc/arm-linux-gnueabihf/4.8.2/libgcc.a(_udivdi3.o)
The README.txt file that came with the toolchain said:
"In addition to the default configuration, a basic ARMv4T runtime is
included for use when building baremetal projects such as Linux and
u-boot for earlier architectures. To use it, pass the following flags
to GCC:
-marm -march=armv4t -mfloat-abi=soft"
So I tried this:
$ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- "CFLAGS=-marm
-march=armv4t -mfloat-abi=soft" distclean
$ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- "CFLAGS=-marm
-march=armv4t -mfloat-abi=soft" zynq_zed_config
$ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- "CFLAGS=-marm
-march=armv4t -mfloat-abi=soft"
and that failed in autoconf.
Looking more carefully at the Makefile, I think maybe I should set
OBJCFLAGS instead of CFLAGS. That gave me the same error as my first
attempt. Not surprising, since OBJCFLAGS doesn't seem to be used.
FWIW. I'm using the u-boot I cloned from commit
f12f87e205d5cd1c75a0d93770de54ffb8b14343 from git://
git.xilinx.com/u-boot-xlnx.git.
Any tips where I should start looking for clues?
Thanks.
--wpd