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…
Hi. I am interested in participating in Google Summer of Code - 2014 with
Linaro and working on two of the ideas from Ideas page [1]:
AArch64 porting of Free Software Packages - I am amazed going through the
details mentioned at [2] about the use of assembly in packages. I would
like to discover more, and figure out where I could contribute.
Port UEFI to Low-Cost Embedded Platform - Although I have not used a system
with UEFI before, I want to know more about the low level interaction that
occurs between the kernel and the hardware.
Please help me get started and gain a better understanding of what
implementing each of these ideas would involve.
About me:
I can program with C, Perl, Python, Processing and Shell Scripts. I built a
game for the Intel Perceptual Computing Challenge-2013 [3] and have
experience with development for the Beagleboard and Pandaboard. I am
currently reading Greg K-H's Linux Device Drivers to figure out how drivers
work. I am also learning the x86 assembly language. I have been an open source
user for a long time, and have a commit integrated into GNOME's Anjuta IDE
[4]
I recently worked with Red Hat on testing the effectiveness of random
number generators on a virtual machine with qemu.[5]
I also have a fair know-how of git.
[1] https://wiki.linaro.org/SummerOfCode2014/ProjectIdeas
[2] https://wiki.linaro.org/LEG/Engineering/OPTIM/Assembly
[3]
http://varadgautam.wordpress.com/2013/09/26/bender-a-game-using-the-intel-p…
[4]
https://git.gnome.org/browse/anjuta/commit/?id=eb10532632014b59505c788ffad4…
[5]
http://varadgautam.wordpress.com/2013/12/17/dieharder-tests-on-a-qemu-vm-1-…
Thanks.
Varad
Hi,
After a solid few months of work the QEMU master branch [1] has now reached
instruction feature parity with the suse-1.6 [6] tree that a lot of people
have been using to build various aarch64 binaries. In addition to the
SUSE work we have fixed numerous edge cases and finished off classes of
instructions. All instructions have been verified with Peter's RISU
random instruction testing tool. I have also built and run many
packages as well as built gcc and passed most of the aarch64 specific tests.
I've tested against the following aarch64 rootfs:
* SUSE [2]
* Debian [3]
* Ubuntu Saucy [4]
In my tree the remaining insns that the GCC aarch64 tests need to
implement are:
FRECPE
FRECPX
CLS (2 misc variant)
CLZ (2 misc variant)
FSQRT
FRINTZ
FCVTZS
Which I'm currently working though now. However for most build tasks I
expect the instructions in master [1] will be enough.
If you want the latest instructions working their way to mainline you
are free to use my tree [5] which currently has:
* Additional NEON/SIMD instructions
* sendmsg syscall
* Improved helper scripts for setting up binfmt_misc
* The ability to set QEMU_LOG_FILENAME to /path/to/something-%d.log
- this is useful when tests are failing N-levels deep as %d is
replaced with the pid
Feedback I'm interested in
==========================
* Any instruction failure (please include the log line with the
unsupported message)
* Any aarch64 specific failures (i.e. not generic QEMU threading flakeiness).
If you need to catch me in real time I'm available on #qemu (stsquad)
and #linaro-virtualization (ajb-linaro).
Many thanks to the SUSE guys for getting the aarch64 train rolling. I
hope your happy with the final result ;-)
Cheers,
--
Alex Bennée
QEMU/KVM Hacker for Linaro
[1] git://git.qemu.org/qemu.git master
[2] http://download.opensuse.org/ports/aarch64/distribution/13.1/appliances/ope…
[3] http://people.debian.org/~wookey/bootstrap/rootfs/debian-unstable-arm64.tar…
[4] http://people.debian.org/~wookey/bootstrap/rootfs/saucy-arm64.tar.gz
[5] https://github.com/stsquad/qemu/tree/ajb-a64-working
[6] https://github.com/susematz/qemu/tree/aarch64-1.6
I sent the below to the list before I was a subscriber and I don't think it made it through.
-----
I don't know if I'm having a problem with QEMU or the linaro system image I'm using or something else, so I'm posting it here. Let me know if there's a more appropriate place.
I'm experiencing the following crash:
$ qemu-system-arm -machine beagle -nographic -sd linaro-saucy-nano-20140126.img
qemu: fatal: Trying to execute code outside RAM or ROM at 0x402f0400
R00=40014044 R01=402f0400 R02=00000000 R03=00000000
R04=00000000 R05=00000000 R06=00000000 R07=00000000
R08=00000000 R09=00000000 R10=00000000 R11=00000000
R12=00000000 R13=4020fcb0 R14=00000000 R15=402f0400
PSR=400001df -Z-- A sys32
s00=00000000 s01=00000000 d00=0000000000000000
s02=00000000 s03=00000000 d01=0000000000000000
s04=00000000 s05=00000000 d02=0000000000000000
s06=00000000 s07=00000000 d03=0000000000000000
s08=00000000 s09=00000000 d04=0000000000000000
s10=00000000 s11=00000000 d05=0000000000000000
s12=00000000 s13=00000000 d06=0000000000000000
s14=00000000 s15=00000000 d07=0000000000000000
s16=00000000 s17=00000000 d08=0000000000000000
s18=00000000 s19=00000000 d09=0000000000000000
s20=00000000 s21=00000000 d10=0000000000000000
s22=00000000 s23=00000000 d11=0000000000000000
s24=00000000 s25=00000000 d12=0000000000000000
s26=00000000 s27=00000000 d13=0000000000000000
s28=00000000 s29=00000000 d14=0000000000000000
s30=00000000 s31=00000000 d15=0000000000000000
s32=00000000 s33=00000000 d16=0000000000000000
s34=00000000 s35=00000000 d17=0000000000000000
s36=00000000 s37=00000000 d18=0000000000000000
s38=00000000 s39=00000000 d19=0000000000000000
s40=00000000 s41=00000000 d20=0000000000000000
s42=00000000 s43=00000000 d21=0000000000000000
s44=00000000 s45=00000000 d22=0000000000000000
s46=00000000 s47=00000000 d23=0000000000000000
s48=00000000 s49=00000000 d24=0000000000000000
s50=00000000 s51=00000000 d25=0000000000000000
s52=00000000 s53=00000000 d26=0000000000000000
s54=00000000 s55=00000000 d27=0000000000000000
s56=00000000 s57=00000000 d28=0000000000000000
s58=00000000 s59=00000000 d29=0000000000000000
s60=00000000 s61=00000000 d30=0000000000000000
s62=00000000 s63=00000000 d31=0000000000000000
FPSCR: 00000000
Aborted (core dumped)
Here's how I created the image:
linaro-media-create --dev beagle \
--hwpack hwpack_linaro-beaglebone_20140203-602_armhf_supported.tar.gz \
--binary linaro-saucy-nano-20140126-627.tar.gz \
--image-file linaro-saucy-nano-20140126.img
I get the same error on the following OS/qemu combos:
Ubuntu Trusty
$ qemu-system-arm --version
QEMU emulator version 1.7.0 (Debian 1.7.0+dfsg-3ubuntu1), Copyright (c) 2003-2008 Fabrice Bellard
Ubuntu Saucy
$ qemu --version
QEMU emulator version 1.5.0 (Debian 1.5.0+dfsg-3ubuntu5.2), Copyright (c) 2003-2008 Fabrice Bellard
MacOS 10.8.5
QEMU emulator version 1.7.0 (qemu-linaro 2014.01), Copyright (c) 2003-2008 Fabrice Bellard
I get a similar error at a different address with this highbank image:
http://releases.linaro.org/14.01/ubuntu/highbank/highbank-saucy_server_2014…
$ qemu-system-arm -machine highbank -nographic -sd highbank-saucy_server_20140126-596.img
qemu: fatal: Trying to execute code outside RAM or ROM at 0x08000000
I am able to boot this oneiric image:
http://releases.linaro.org/images/12.03/oneiric/nano/beagle-nano.img.gz
Can somebody supply me with a working qemu beaglebone command line? What does LAVA use?
Thanks,
Dan
I am trying to build valgrind using bitbake. Sometime recently I was trying
to build gmp also using bitbake and these two activties are interleaved.
Now when I switch between these two activities (i.e building valgrind and
building gmp), bitbake is mixing things up as follows. Could anyone help me
on how to get rid of this behavior. As it can be seen, when I use "bitbake
valgrind" it is trying to pull gmp code and is failing. What should I doing
to do a clean build? I thought bitbake take the package name and confines
its tasks only to that package and should never look at the .bb file of
another package, right?
--------------------------------------------------------------------------------------------------------------------------------------------------
anilss@anilss:~/Linaro/tools/OEBldEnv/jenkins-setup/openembedded-core$ .
oe-init-build-env ../build
### Shell environment set up for builds. ###
You can now run 'bitbake <target>'
Common targets are:
core-image-minimal
core-image-sato
meta-toolchain
adt-installer
meta-ide-support
You can also run generated qemu images with a command like 'runqemu qemux86'
anilss@anilss:~/Linaro/tools/OEBldEnv/jenkins-setup/build$ bitbake valgrind
Loading cache: 100%
|#############################################################################################|
ETA: 00:00:00
Loaded 2090 entries from dependency cache.
Parsing recipes: 100%
|###########################################################################################|
Time: 00:00:04
Parsing of 1647 .bb files complete (1644 cached, 3 parsed). 2089 targets,
80 skipped, 0 masked, 0 errors.
WARNING: No recipes available for:
/home/anilss/Linaro/tools/OEBldEnv/jenkins-setup/meta-linaro/meta-linaro-toolchain/recipes-core/eglibc/eglibc_2.18.bbappend
NOTE: Resolving any missing task queue dependencies
NOTE: preferred version 2.18 of eglibc not available (for item virtual/libc)
NOTE: versions of eglibc available: 2.19
NOTE: preferred version 2.18 of eglibc not available (for item eglibc-dbg)
NOTE: versions of eglibc available: 2.19
NOTE: preferred version 2.18 of eglibc not available (for item libsegfault)
NOTE: versions of eglibc available: 2.19
NOTE: preferred version 2.18 of eglibc not available (for item eglibc-dev)
NOTE: versions of eglibc available: 2.19
NOTE: preferred version 2.18 of eglibc not available (for item eglibc)
NOTE: versions of eglibc available: 2.19
NOTE: preferred version 2.18 of eglibc not available (for item
virtual/aarch64-oe-linux-libc-for-gcc)
NOTE: versions of eglibc available: 2.19
NOTE: preferred version 2.18 of eglibc-initial not available (for item
virtual/aarch64-oe-linux-libc-initial)
NOTE: versions of eglibc-initial available: 2.19
NOTE: preferred version 2.18 of eglibc not available (for item
virtual/libiconv)
NOTE: versions of eglibc available: 2.19
Build Configuration:
BB_VERSION = "1.21.1"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING = "Ubuntu-13.04"
TARGET_SYS = "aarch64-oe-linux"
MACHINE = "genericarmv8"
DISTRO = "nodistro"
DISTRO_VERSION = "nodistro.0"
TUNE_FEATURES = "aarch64"
meta-oe
meta-filesystems
meta-initramfs
meta-webserver
meta-networking
meta-gnome = "(nobranch):c95e155780a0cf3a8fb59a2f86db6367d18116fc"
meta-aarch64
meta-bigendian
meta-linaro
meta-linaro-toolchain =
"(nobranch):762394cc968b8229f594f22b3eb4fc69828a64dc"
meta-virtualization = "(nobranch):20accf6d7cf8330f26be3718c96edf6dae14b4f0"
meta-browser = "(nobranch):dc2b7ef7dffb19d4cdf72b3c8f441c0963d40643"
meta = "(nobranch):c325b1470c2e009c6b228aa0720bff05452716e4"
NOTE: Preparing runqueue
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
WARNING: Failed to fetch URL hg://
gmplib.org/repo/gmp-5.1/;rev=15452;module=gmp-5.1, attempting MIRRORS if
available
ERROR: Fetcher failure: Fetch command failed with exit code 255, output:
warning: gmplib.org certificate with fingerprint
64:e1:c3:b7:86:18:4d:1e:bd:ca:43:a5:cd:f0:a0:82:85:1b:71:75 not verified
(check hostfingerprints or web.cacerts config setting)
abort: HTTP Error 404: Not Found
ERROR: Function failed: Fetcher failure for URL: 'hg://
gmplib.org/repo/gmp-5.1/;rev=15452;module=gmp-5.1'. Unable to fetch URL
from any source.
ERROR: Logfile of failure stored in:
/home/anilss/Linaro/tools/OEBldEnv/jenkins-setup/build/tmp-eglibc/work/x86_64-linux/gmp-native/5.1.1-hg/temp/log.do_fetch.32486
ERROR: Task 330
(virtual:native:/home/anilss/Linaro/tools/OEBldEnv/jenkins-setup/openembedded-core/meta/recipes-support/gmp/
gmp_5.1.1_hg.bb, do_fetch) failed with exit code '1'
NOTE: Tasks Summary: Attempted 514 tasks of which 510 didn't need to be
rerun and 1 failed.
No currently running tasks (514 of 741)
Summary: 1 task failed:
virtual:native:/home/anilss/Linaro/tools/OEBldEnv/jenkins-setup/openembedded-core/meta/recipes-support/gmp/
gmp_5.1.1_hg.bb, do_fetch
Summary: There were 2 WARNING messages shown.
Summary: There were 2 ERROR messages shown, returning a non-zero exit code.
anilss@anilss:~/Linaro/tools/OEBldEnv/jenkins-setup/build$
hello Group,
I am trying to boot the Linaro-Ubuntu-13.04 release on Panda, But the
_HDMI_ display is not coming.
- I see the x-server is not started (X doesn't exit, is the window
manager changed?). I installed it and started X. But it says error
message as "no screen found"
- In Xorg.logs i see message, failed to load omap display module.
Any pointers how to get the display? got a dependency on it.
thanks,
sanjay
Hi all,
Apologies if this is the wrong list, and for the somewhat vague
description of my problem.
I've been working on porting Go (via gccgo) to aarch64 and things have
mostly been going well. However, under some circumstances, I'm seeing
crashes. What's happening is that when a signal -- SIGCHLD in this case
-- is being handled, instead of being executed on the stack passed to
sigaltstack, the signal is being handled on some *other* thread's stack,
which unsurprisingly ends badly when a signal context object is smashed
over whatever the original thread had put there.
By setting breakpoints on the signal handler in gdb and printing $sp, I
can actually see that signals are never being executed on the altstack,
but it takes a random number of signals before one is executed somewhere
that causes a crash. So I don't know if signals are always being
handled on other thread's stacks or if it's just at random-ish locations
in the heap. (Goroutines run with stacks allocated in the heap).
Writing a very simple program that calls sigaltstack does behave as
expected, but the go runtime is doing all sorts of things with multiple
threads and getcontext/makecontext/setcontext so I guess something is
getting confused.
There are some more details on this bug:
https://bugs.launchpad.net/ubuntu/+source/gcc-4.8/+bug/1279620 but I
don't have anything like a minimal example unfortunately. I'll try to
come up with one tomorrow, but in the mean time: does this ring any
bells at all with anyone? I couldn't see any obvious reasons for this
behaviour in the kernel code :/
Cheers,
mwh
Someone asked if this worked, and I thought 'that's trivial to test with
multiarch' so I did.
On Saucy (where there is no multiarch version skew issue between binary versions of packages) the
dpkg --add-architecutre armhf
apt-get update
apt-get install links:armhf
part works very nicely. Everything installs as required.
However binaries don't run - they just get killed.
Apparently no-one has tried this for a couple of years since it was
last working...(Or is it working on other platforms? - apparently it's OK
on android)
Turns out that our arm64 kernel config has:
vm.mmap_min_addr=65536
but armhf binaries tend to get mmapped at 0x8000 (32K).
On armhf that value is set to
vm.mmap_min_addr=4096
This difference is to protect page0 even if large pages are enabled
which seems sensible enough, but has this unfortunate side-effect.
So either we need to stop doing that (What would be the consequences of
setting 4096 by default on arm64?) or change something in the loader to
stop mapping things below 64K, which I think involves glibc hackery.
Running 32-bit binaries is quite seriously broken until this is fixed. I
presume this currently isn't on anyone's list to fix? I'm not sure who's
list it should go on.
part2: Once this is fixed with:
sudo sysctl -w vm.mmap_min_addr=4096
some binaries work (hello, bzip2) but fancier things still don't (links,
wget). They segfault after loading libs. I'm still investigating that,
but it looks like we have at least two issues..
So this mail is really to ask what the best fix is and thus who will
deal with it? Do I need to file a bug or a card somewhere?
Possibly more to follow when I work out what else is wrong...
Wookey
--
Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/
