** Changed in: qemu-linaro
Status: Fix Committed = Fix Released
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/928555
Title:
qemu-linaro FTBFS on arm because of deprecated gthread calls
To
** Changed in: qemu-linaro
Status: Fix Committed = Fix Released
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/906922
Title:
qemu-arm-static chroots give copious memory errors when setting up
** Changed in: qemu-linaro
Status: Fix Committed = Fix Released
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/928432
Title:
spice backend fails to build on i386 with -Werror
To manage
Oops. My test of this was on a 32 bit oneiric system, where configure now
disables spice completely. Retested and reproduced on a precise-i386 chroot,
and sent a patch upstream:
http://patchwork.ozlabs.org/patch/147207/
--
You received this bug notification because you are a member of Ubuntu
Hmm, this may be as easy as changing the line in linux-user/arm/syscall_nr.h
that reads
/* 336 for ppoll */
to say
#define TARGET_NR_ppoll 336
instead...
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
...although glibc should fall back to its own implementation if there's
no ppoll syscall so probably the underlying crash is some other issue.
It would be useful if you could manage to extract the actual failing
binary as a manageable test/repro case...
--
You received this bug notification
ppoll implementation:
http://patchwork.ozlabs.org/patch/147225/
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/956799
Title:
qemu: Unsupported syscall: 336
To manage notifications about this bug go
Specifically the functions exist but return ENOSYS, which is why this:
if (getcontext (c) 0)
abort ();
will abort.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/937011
Title:
configure test
Trying to get these functions into eglibc for ARM is kind of on the
toolchain group's todo list, but (a) not at a hugely high priority and
(b) it will take a little while for them to percolate through eglibc and
back into distros anyway, so apps/configure scripts need to be prepared
to handle the
I've just checked, and the version of mesa shipped in Oneiric has had
this bug fixed.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/743731
Title:
[i915] SEGV in i915_dri.so:translate_program()
#define __NR_setxattr (__NR_SYSCALL_BASE+226)
#define __NR_fsetxattr (__NR_SYSCALL_BASE+228)
#define __NR_getxattr (__NR_SYSCALL_BASE+229)
#define __NR_fgetxattr (__NR_SYSCALL_BASE+231)
#define __NR_llistxattr (__NR_SYSCALL_BASE+233)
#define __NR_flistxattr (__NR_SYSCALL_BASE+234)
Support for
I've submitted a patchset upstream that adds the missing syscalls (and fixes a
bug with passing a NULL value pointer into setxattr and getxattr):
http://patches.linaro.org/5701/
http://patches.linaro.org/5702/
http://patches.linaro.org/5703/
** Changed in: qemu-linaro
Status: New = In
** Changed in: qemu-linaro
Status: Fix Committed = Fix Released
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/903239
Title:
qemu-arm-static: Unsupported syscall for *xattr
To manage
** Changed in: qemu-linaro
Status: In Progress = Fix Committed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/903239
Title:
qemu-arm-static: Unsupported syscall for *xattr
To manage
An untested workaround you could try: arrange to set the environment
variable QEMU_RESERVED_VA=0xf700 so the qemu in the chroot can see
it.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/906922
Right, so this is really down to qemu not being very good at handling
mmap() in the 32-bit-guest-on-64-bit-host case -- it tends to fail
mmap() even when there's more address space available because it hasn't
managed to get the host kernel to allocate it within the 32-bit region
of the address
For the record, the general consensus on the #ac100 irc channel seems to
be:
(1) if you have a mismatched kernel and eglibc, where the kernel has its
half of the Android erratum workaround enabled but the libc does not,
then you are going to get segfaults (purely as a result of the mismatch
and
Public bug reported:
If mmap() fails mono can crash with a segfault rather than handling the
memory allocation failure cleanly. This cropped up in bug 816791 (where
mono is running under qemu; qemu is prone to returning failure from
mmap()).
This is the function GC_install_header from
So at the moment qemu doesn't support emulating threaded x86 programs in
linux-user mode. (- target_nptl isn't set in configure for x86
targets). I think this is because the target-i386 code doesn't have the
necessary support for bouncing atomic memory access ops up to the linux-
user top level
We only implement the futex syscalls if CONFIG_USE_NPTL. This isn't
defined for the i386 target (the necessary support in target-i386 for
pushing atomic insns up to the linux-user top level loop isn't
implemented). The upshot is that running multithreaded programs in
linux-user i386-target isn't
The fix has been committed upstream and is now in qemu-linaro git.
Steve, you'll want to remove the workaround from the packaging for the
2011.04 release.
** Changed in: qemu-linaro
Status: In Progress = Fix Committed
--
You received this bug notification because you are a member of
I wrote:
The physical memory map on versatile hardware does not allow more than 256MB
of space for RAM. The bug here is just that qemu should exit with a helpful
error message
...and I've just submitted the following two patches upstream which
implement this:
objdump says this axf has:
LOAD off0x8000 vaddr 0x0600 paddr 0x0600 align 2**15
filesz 0x00017cd8 memsz 0x0001ac50 flags rwx
...and address 0x0600 on Versatile Express is in
the 'reserved' area above the remappable 64MB low memory block. (On PBX A9 etc
there is
2011/3/24 Loïc Minier l...@dooz.org:
Would you happen to know where/who to raise this to at ARM?
Try Peter Pearse.
I've built upstream u-boot for vexpress from tip and it shows:
LOAD off 0x8000 vaddr 0x6080 paddr 0x6080 align 2**15
Yep, that's in RAM for vexpress.
and it
The 'qemu' binary (which is for x86 and kvm) is not always the same version as
the one used for ARM user-mode emulation (and in particular it is in a
different package for newer Ubuntu releases). What is the output of:
qemu-arm-static -h | grep version
?
--
You received this bug notification
Note that the approach taken by that patch is that when writing the TLS
register we move bit 20 down into bit 0, and then on reading we move
bit 0 back up into bit 20. So this requires changes to everything that
reads or writes the TLS register. There are Android patches that do this
for libc and
** Changed in: qemu-linaro
Importance: Undecided = Low
** Changed in: qemu-linaro
Status: New = In Progress
** Changed in: qemu-linaro
Milestone: None = 2011.04
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Patch submitted upstream:
http://patchwork.ozlabs.org/patch/87268/
With this it works OK in both usermode and system mode (I tested booting
an x86 system image, which is fine although obviously very sloow.)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which
Public bug reported:
If you try to run the game Scarlet Weather Rhapsody under Wine on Ubuntu
natty, it segfaults on startup. This seems to be a bug that's fixed in
mesa's git repo. This used to work on lucid, but regressed in maverick
and is still present in natty alpha-3.
Sorry the
** Changed in: qemu-linaro
Status: Fix Committed = Fix Released
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/731095
Title:
qemu doesn't work in thumb mode
--
ubuntu-bugs mailing list
Public bug reported:
The latest x-loader (1.5.1) breaks under qemu (you can see this in the
20110718 snapshot, for example). What happens:
* x-loader misprograms the OMAP clocks, specifically by writing values to
CM_CLKSEL1_PLL which are for a 19.2MHz master clock rather than the correct
Public bug reported:
Binary package hint: emacs23
Package: emacs23
Version: 23.1+1-4ubuntu7
Ubuntu release: 10.10
Start emacs. Shift-left-click on the buffer area to bring up the context
menu. Select Change Buffer Font The list of fonts in the dialog
box does not include the X standard
Public bug reported:
Binary package hint: bzr
Package: bzr
Version: 2.2.0-1
Ubuntu version: 10.10
If you try to use 'bzr blame' and you haven't used 'bzr whoami' to tell
bzr who you are then it complains. Actual behaviour:
petma...@linaroe102767:~/linaro/snapshot/linaro-image-tools$ bzr blame
qemu: fatal: cp15 insn ee1d6f70
PSR=2030 --C- T usr32
This is the Thumb2 instruction MRC p15, 0, r6, c13, c0, 3 (which is
accessing a thread / process ID register)
I suspect that if you use a newer qemu with this commit in it:
I have discovered a workaround for this bug. First you need to edit
fontconfig's config files to stop it from filtering out all the monospace
bitmap fonts, for example by replacing /etc/fonts/conf.d/70-no-bitmaps.conf
with the attached file and then running
sudo fc-cache -v -f to rebuild its
I've tested and confirmed that the new package fixes the problem:
* built a Linaro image according to
http://lists.linaro.org/pipermail/linaro-announce/2010-November/25.html and
tested it under qemu's beaglexm model = fails to boot as expected (hwpack has
old version of x-loader-omap)
*
I believe this has already been fixed in bzr (r140):
http://bazaar.launchpad.net/~linaro-maintainers/linaro-image-tools/linaro-image-tools/revision/140
--
linaro-media-create have problems handling hwpacks
https://bugs.launchpad.net/bugs/652669
You received this bug notification because you are
Assignee: (unassigned) = Peter Maydell (pmaydell)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/644961
Title:
Missing emulation for epoll_create syscall
--
ubuntu-bugs mailing list
ubuntu-bugs
Patch tested on the qemu-debootstrap test case, submitted upstream:
http://patchwork.ozlabs.org/patch/83279/
(I'll put it into qemu-linaro 2011.03 anyway even if it hasn't made it into
upstream git by then)
With the new qemu, Loic's testcase no longer aborts in plymouth. (dpkg
doesn't
The fix is already in qemu-linaro 2011.02.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/604872
Title:
qemu-system-arm segfaults emulating versatile machine after running
debootstrap
The commit in qemu-linaro is:
http://git.linaro.org/gitweb?p=qemu/qemu-linaro.git;a=commit;h=98eac7cab4392ab28fa22265e27906f5b9c6c9da
I asked you to undo the status change just because I don't own qemu-
linaro (Ubuntu) and don't know what counts as fix released (eg maybe
that only happens when it
The physical memory map on versatile hardware does not allow more than
256MB of space for RAM. The bug here is just that qemu should exit with
a helpful error message (or maybe clip the requested memory size to the
maximum) rather than crashing.
--
You received this bug notification because you
I think implementing ptrace in user mode qemu would be remarkably
tricky. You'd have to somehow identify that the process you were trying
to attach to was really another user-mode qemu process and not a native
binary, and then you'd need to establish communication with it over some
channel, so you
** Changed in: qemu-linaro
Status: Fix Committed = Fix Released
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/721801
Title:
llseek bug in amd64 host
--
ubuntu-bugs mailing list
** Changed in: qemu-linaro
Status: Fix Committed = Fix Released
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/644961
Title:
Missing emulation for epoll_create syscall
--
ubuntu-bugs
** Changed in: qemu-linaro (Ubuntu)
Status: Triaged = Fix Released
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/604872
Title:
qemu-system-arm segfaults emulating versatile machine after
Suggested patch sent upstream: http://patchwork.ozlabs.org/patch/83964/
I'll put this in qemu-linaro 2011.03 one way or another.
** Changed in: qemu-linaro
Status: New = In Progress
** Changed in: qemu-linaro
Importance: Undecided = Medium
** Changed in: qemu-linaro
Milestone:
** Changed in: qemu-linaro
Status: In Progress = Fix Committed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/644961
Title:
Missing emulation for epoll_create syscall
--
ubuntu-bugs mailing
I can confirm that I can reproduce this bug with qemu-kvm-extras
0.12.3+noroms-0ubuntu9 and 0.12.5+noroms-0ubuntu7 but that it is not present in
qemu-linaro 2011.02. I used the zImage from
http://ftp.linux.org.uk/pub/linux/arm/fedora/qemu/zImage-versatile-2.6.22 for
testing.
The cause of this
I'm pretty sure this is the same issue as bug 584480 but with slightly
different systems -- the debian qemu-kvm-extras package has a Debian-
specific patch which sets the default memory size to 384MB, which in
turn triggers the bug in versatilepb and integrator models where they
misbehave (crash,
Moving back to qemu-kvm as specific to that package.
** Package changed: qemu-linaro (Ubuntu) = qemu-kvm (Ubuntu)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/584480
Title:
qemu-system-arm
Moving back to qemu-kvm as specific to that package.
** Package changed: qemu-linaro (Ubuntu) = qemu-kvm (Ubuntu)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/579227
Title:
[qemu-system-arm]
** Changed in: qemu-linaro
Status: In Progress = Fix Committed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/721801
Title:
llseek bug in amd64 host
--
ubuntu-bugs mailing list
No, it's not fixed in Karmic.
(I personally think that requiring bug submitters to respond to 'please
retest' pings is counterproductive; there are some arguments along these
lines here:
http://www.chiark.greenend.org.uk/ucgi/~cjwatson/blosxom/2009/03/02)
** Changed in: scim-skk (Ubuntu)
** Changed in: scim-skk (Ubuntu)
Status: Incomplete = Confirmed
--
SCIM help dialogue for scim-skk is in Japanese
https://bugs.launchpad.net/bugs/53407
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
I have retested with audacious 2.3-1ubuntu4, and it does seem to have
managed to remove all the debug tracing. So I guess this bug could be
closed.
--
audacious seems to have debug tracing accidentally left in
https://bugs.launchpad.net/bugs/238818
You received this bug notification because you
Public bug reported:
Binary package hint: ttf-wqy-zenhei
(I hope I've picked the right place to start with reporting this bug. I
find fontconfig and CJK font selection issues in general quite
confusing.)
In Karmic, running firefox seems to pick a non-Japanese font for displaying
Japanese web
** Attachment added: Dependencies.txt
http://launchpadlibrarian.net/39108851/Dependencies.txt
** Attachment added: XsessionErrors.txt
http://launchpadlibrarian.net/39108852/XsessionErrors.txt
--
WenQuanYi Zen Hei is prioritised above Japanese fonts for Japanese language text
Results of running firefox with FC_DEBUG=1. Interesting part (I think):
Sort Pattern has 16 elts (size 32)
family: Bitstream Vera Sans(w) DejaVu Sans(w) WenQuanYi Zen
Hei(w) DejaVu Sans(w) Nimbus Sans L(w) AR PL UMing HK(w) AR PL UMing
CN(w) Waree(w) Loma(w) Garuda(w) Umpush(w)
Thanks for pointing me at fontconfig-voodoo, that seems to now give the
right results for Japanese text. However it seems to do this at the
expense of everything else:
without fontconfig-voodoo:
pm...@canth:~/jlptvocab$ fc-match Sans:lang=zh
wqy-zenhei.ttc: WenQuanYi Zen Hei 中等
Qianqian Fang wrote:
download and install the following 3 files
I installed those three files (I also had to remove 44-wqy-zenhei.conf
as you suggested I might). I now get a Japanese font for lang=ja and the
DejaVu Sans font for no-lang-tag, which is exactly what I was hoping
for; thanks!
I
Public bug reported:
Binary package hint: binutils
Package: binutils
Version: 2.20.51.20100813-1ubuntu3
If you type objdump -i the output includes an assertion failure:
cam-vm-266:maverick:qemu-0928$ objdump -i
BFD header file version (GNU Binutils for Ubuntu) 2.20.51-system.20100813
elf32-i386
Public bug reported:
Package: x-loader
Version: 1.4.4git20100713-1ubuntu2
The patch debian/patches/support_micron_and_numonyx_memory.patch
(introduced to fix LP: #628243) includes the new function int
identify_xm_ddr() which ends like this:
nand_readid(mfr, id);
if (mfr == 0)
Public bug reported:
Package: x-loader
Version: 1.4.4git20100713-1ubuntu2
The patch debian/patches/support_micron_and_numonyx_memory.patch adds
support for Numonyx RAM. However when it programs the SDRC it sets up
the two banks CS0 and CS1 so that they overlap in memory:
Also, we ought to put the #defines from drivers/k9f1g08r0a.c in a header file
and use them rather than magic numbers:
#define MT29F1G_MFR 0x2c /* Micron */
#define MT29F1G_MFR20x20 /* numonyx */
#define MT29F1G_ID 0xa1 /* x8, 1GiB */
#define MT29F2G_ID
I'm not sure what the source of the patch is that is being used
It was applied to fix
https://bugs.launchpad.net/ubuntu/+source/x-loader/+bug/628243 which says that
the patch is from this git repo:
Yes, many newer applications share the problem of unwanted stdout/stderr
messages. That doesn't make this not a bug in this application.
** Changed in: audacious (Ubuntu)
Status: Invalid = New
--
audacious seems to have debug tracing accidentally left in
I have a patchset which fixes this bug, which I need to do a bit more
cleanup and testing with before I post it to the list.
** Changed in: qemu
Status: New = In Progress
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Public bug reported:
Binary package hint: strace
Package: strace
Version: 4.5.20-2ubuntu2
strace on i386 does not print the arguments to sync_file_range
correctly:
cam-vm-266:maverick:qemu$ cat /tmp/sync_file_range.c
#define _GNU_SOURCE
#include stdio.h
#include fcntl.h
int main(void) {
int
I've now posted this patchset; it comes in 7 parts:
http://patchwork.ozlabs.org/patch/77887/
http://patchwork.ozlabs.org/patch/77882/
http://patchwork.ozlabs.org/patch/77884/
http://patchwork.ozlabs.org/patch/77885/
http://patchwork.ozlabs.org/patch/77888/
http://patchwork.ozlabs.org/patch/77881/
I've analysed this segfault. The problem is that we're not correctly
taking account of the IT state on entry to a Thumb translation block if
we're retranslating it for cpu_restore_state().
The offending TB here is:
0x0003dc00: movle r2, #0
0x0003dc02: ldrr1, [pc, #644] (0x3de88)
http://lists.gnu.org/archive/html/qemu-devel/2012-05/msg03012.html is my
current proposed long-term upstream-acceptable approach to TrustZone
handling.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
The backtrace indicates that this is a multithreaded application. These
won't work reliably under qemu-user : they tend to crash, as you have
found.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
** Changed in: qemu-linaro
Status: Fix Committed = Fix Released
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/956799
Title:
qemu: Unsupported syscall: 336
To manage notifications about this
** Changed in: qemu-linaro
Status: Fix Committed = Fix Released
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/928432
Title:
spice backend fails to build on i386 with -Werror
To manage
Actually, assuming the guest ARM glibc doesn't have the printf() bug the
code is testing for, we shouldn't take the SIGSEGV anyway, so that's a
red herring. The actual problem here is the setrlimit().
The conftest.c test case works by using rlimit to limit the address
space. This generally
** Summary changed:
- gnutls28 fails to build from source in armhf
+ linux-user mode can't handle guest setting RLIMIT_AS (hangs running gnutls28
configure check code)
** Changed in: qemu
Status: New = Confirmed
--
You received this bug notification because you are a member of Ubuntu
Regarding bug 1042388, those are the posix timer syscalls, and I guess
they've just been around long enough that apt expects them to exist.
Anyway, we should just implement them in QEMU.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Of course, qemu-keymaps coming from linaro may not be a problem if it
would include the en_us map :)
It does include en_us, it's just putting all the keymaps in a different
directory to the one qemu is looking for (/qemu-linaro/ vs /qemu/)
--
You received this bug notification because you are
That test case seems to have very weak reproducibility -- I think I saw
a hang perhaps once in 30+ runs. That's not really usable for debugging,
I'm afraid :-(
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
I'll take the bigger usecase, please. It's pretty hard to debug race
conditions that don't manifest often enough to let you do useful
logging.
From the time or two I caught it hanging, it looks like qemu is sleeping in
poll, and there's a zombie child process. I wonder if what's happening is
Actually I just managed to interact with a hung qemu under a debugger
sufficiently to confirm what is happening here.
CMake's code for running child processes (in kwsys/ProcessUNIX.c) does this:
On UNIX, a child process is forked to exec the program. Three output pipes
are read by the parent
On 1 December 2012 10:29, Janne Karhunen 955...@bugs.launchpad.net wrote:
this blocks forever, because the thing that would wake it up is the
signal handler writing to the pipe we're selecting on, but we will never
run the signal handler until select exits
Duh, makes sense, have to think
** Changed in: qemu
Status: New = Confirmed
** Changed in: qemu-linaro
Status: New = Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/955379
Title:
cmake hangs with
On 3 December 2012 21:20, Alexander Graf ag...@suse.de wrote:
Could you please try and see if this patch makes a difference?
http://repo.or.cz/w/qemu/agraf.git/patch/489924aa0115dc6cfcd4e91b0747da4ff8425d1f
I think the answer will turn out to be no (though it's worth
testing anyway), because
Yes. You can never shut the window completely trying to do it that way,
which is why you need fix the problem properly instead.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/955379
Title:
cmake
On 4 December 2012 11:21, Janne Karhunen 955...@bugs.launchpad.net wrote:
And what would break if we make poll timeout instantly in case there are
signals pending and restart the given syscall after handlers run?
If there are signals pending in the host kernel poll will *already*
return
qemu-system-arm -M versatilepb -kernel u-boot.bin
[...]
Trying to execute code outside RAM or ROM
This almost always means that you tried to execute a guest binary which
wasn't for the VersatilePB. Without more info about exactly what this
u-boot.bin file was this bug report can't progress any
Thanks for the patch. John, since you're going to be doing more QEMU work in
future I'd encourage you to go through the process of submitting it to
upstream's mailing list and shepherding it through the patch review process.
Upstream's patch submission guidelines are here:
John: you might also like to try with this patchset applied:
http://lists.nongnu.org/archive/html/qemu-devel/2013-02/msg04207.html
as that fixes one category of races. There are still other races that can cause
segfaults and other problems (as the cover letter describes) but it's possible
this
John: it would be interesting to try to determine whether that hang has
the same root cause as the cmake and boehm-gc hangs, ie the thing that
is supposed to post the futex is a signal handler whose signal comes in
either just before or during the syscall [either way, the emulated code
for the
cmake bug: LP:955379.
sketch of how to fix signal races:
http://lists.gnu.org/archive/html/qemu-devel/2011-12/msg00384.html
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1129571
Title:
libreoffice
Well, you can try, but I don't think it is very likely to help. The
patch is a hacky workaround for select() in particular, not for the
entire class of hangs.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Does this patch fix this issue?
http://patchwork.ozlabs.org/patch/309529/
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1256546
Title:
qemu-s390x-static: segmentation fault entering chroot
To
I suspect this is a NULL pointer access that happens in procps where it
isn't handling an error path that it's not expecting somehow (either a
syscall we're not implementing, or perhaps something like /proc not
being mounted in your chroot environment, or something about qemu's
emulation of some
Closing as invalid for QEMU because it's an Incomplete bug against an
ancient QEMU version.
** Changed in: qemu
Status: Incomplete = Invalid
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
(ancient distro packaging bug so never valid for QEMU upstream itself;
marking Invalid there)
** Changed in: qemu
Status: Incomplete = Invalid
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Well, the first step would be to provide a reasonably tractable set of
reproduce instructions (at minimum, something like do this to set up a
chroot, then in the chroot run this command and watch it SIGILL.) Also
checking it still repros on 1.4.0 (just released) would be nice (though
I don't think
The actual command from the build log:
/usr/lib/jvm/java-6-openjdk-armhf/bin/java -cp
.:../../unxlngr.pro/class:/usr/lib/jvm/java-6-openjdk-armhf/jre/lib/rt.jar:.:/build/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin
On 25 November 2012 20:40, Tim Penhey tim.pen...@canonical.com wrote:
Peter, if you try to run the cmake file for lp:unity you should hit it.
I'm afraid that's way too little detail. Assume I know nothing about
launchpad, cmake or unity, and give me a set of instructions I
can run on a machine
101 - 200 of 262 matches
Mail list logo
