Yes, this is still a problem (although the dialog is now under
menu->Settings->Settings Manager->Display). I'm using Hardy.
Were you unable to reproduce this, then?
--
xubuntu display preferences: gamma sliders don't stay in sync properly
https://bugs.launchpad.net/bugs/152213
You received this
#10: if that's your entire command line then that's expected behaviour,
and is saying "we just executed a pile of zeros and fell off the end of
RAM". You need to supply a kernel to run.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
h
Public bug reported:
Running the 'rr' make check on Ubuntu Trusty causes the machine to
become unusable because the kernel crashes. (rr build-and-make-check
instructions: https://github.com/mozilla/rr/wiki/Building-And-
Installing)
This is 3.13.0-74-generic #118-Ubuntu for x86_64.
This is rr bug
** 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 notif
** 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 notific
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() under
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.
https://bugs.launchpad.net/bugs/124699
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 fi
I think it's likely to happen eventually; it depends rather on the
balance between this and other work priorities (at least if it's going
to be Linaro doing the work). Regardless, I'm not taking hacky
workarounds like this into mainline (hacks are hard to get out once you
let them in, and they remo
Well, it won't make anything any worse, so it's your call based on how
much it actually improves your failure rate I guess.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1350435
Title:
tcg.c:1693: t
On 9 August 2014 07:15, Erik de Castro Lopo <1042...@bugs.launchpad.net> wrote:
> Unfortunately the test case @pittit submitted is far harder to support
> than the original test case. In this case the timer_create() syscall
> gets passed pointers to functions and data in the target's address space
Patch which seems to at least make the test case work (tested with
i386-on-i386 linux-user): http://patchwork.ozlabs.org/patch/378769/
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1042388
Title:
qe
What cmake is doing is an entirely legitimate and well-recognized Unix
idiom for converting signals into effects on filedescriptors for
select(), and there's no reason for them to change it. This is
absolutely a bug in QEMU, it's just one that's not easy for us to fix.
(Using socketpair would not h
Most rececnt qemu-devel discussion and a promising looking approach (ie it
would work whereas my idea linked from comment #14 would not):
http://lists.gnu.org/archive/html/qemu-devel/2014-02/msg04569.html
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is sub
I think it is in theory supposed to work, but possibly in practice it
doesn't...
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1463172
Title:
destination arm board hangs after migration from x86 sou
Recent patchseries which I think ought to be a proper fix for this bug:
https://lists.gnu.org/archive/html/qemu-devel/2015-09/msg01388.html
It does need some more work to address review comments but it's sound in
principle.
--
You received this bug notification because you are a member of Ubuntu
Public bug reported:
The output of "pkg-config --static --libs gnutls" is the following:
-R/usr/lib/x86_64-linux-gnu -lgnutls -lgcrypt -lgpg-error -ltasn1 -lz
-lp11-kit
However, gcc doesn't understand the "-R" option, so you can't pass the
pkg-config output as a set of gcc command line options t
On 7 May 2014 15:34, Paul Jimenez <1317...@bugs.launchpad.net> wrote:
> Bug description:
> Using the latest version of qemu-user-static from trusty, 2.0.0+dfsg-
> 2ubuntu1.
>
> Reported to qemu and patch submitted long ago by the guy who wrote
> http://www.devttys0.com/2011/12/qemu-vs-sstrip
On 7 May 2014 15:48, Peter Maydell wrote:
> On 7 May 2014 15:34, Paul Jimenez <1317...@bugs.launchpad.net> wrote:
>> Bug description:
>> Using the latest version of qemu-user-static from trusty, 2.0.0+dfsg-
>> 2ubuntu1.
>>
>> Reported to qemu and
On 9 May 2014 09:14, Riku Voipio wrote:
> Hi Craig,
>
> On Wed, May 07, 2014 at 03:53:38PM +0100, Peter Maydell wrote:
>> Original 2011 patch:
>> http://lists.gnu.org/archive/html/qemu-trivial/2011-12/msg00025.html
>
>> (hitting the 'reply' button gets us b
No; this is a a complicated issue to fix that basically requires a
significant restructuring of the linux-user code. Nobody's done that yet
and as far as I know nobody's said they plan to do so either.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscri
** 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
B
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.
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 doesn't
** Changed in: qemu
Status: New => 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/1349277
Title:
AArch64 emulation ignores SPSel=0 when taking (or returning from) an
exception
That patch is not in mainline because it's an appalling hack. If we care
about multi-threaded guests we need to fix them properly, not paper over
the issues by constraining multiple threads to one CPU in the hopes the
race conditions don't bite us so often.
--
You received this bug notification b
Actually, the interesting bit of the stack trace starts just below where
you cut it off, because object_initialize_with_type() is just asserting
that it wasn't called with a NULL pointer, so what we really want to
know is what the caller was...
--
You received this bug notification because you ar
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 manag
Doing this only for aarch64 targets seems like a bad idea to me -- this
isn't an aarch64 specific issue. QEMU needs SIGSEGV to go to its own
handler (so we can unprotect pages we've marked as read-only in order to
catch guest writes to them so we can throw away invalidated translated
code), and tha
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.
https://bugs.launchpad.net/
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 th
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 pr
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 thi
** 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 qemu-arm-
On 3 December 2012 21:20, Alexander Graf 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 the syscal
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 hang
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 imme
If you can provide a simple straightforward reproduce case that would be
useful.
--
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 qemu-arm-static
To manage notifications
On 25 November 2012 20:40, Tim Penhey 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 which isn't necessarily r
On 28 November 2012 08:42, Janne Karhunen <955...@bugs.launchpad.net> wrote:
> Peter, I have qemu chrootable test case under which you could fire one
> command to hit the bug reliably. Only issue is, are you willing to take
> a peek at 100M extractable tarball? If not, I'll try to create a smaller
This bug doesn't seem to have any reproduction instructions, and at
least some of the command lines seem to be asking for 512MB of RAM on a
versatilepb model, which isn't supported and will crash the guest
unhelpfully. I'm marking it 'incomplete' for QEMU...
** Changed in: qemu
Status: New
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 fur
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 thin
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
/jaxp.jar:/build/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin/juh.jar:/bu
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:
http://wiki.qemu.org
> 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
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.
https://bugs.launchpad.net/bugs/5714
(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.
https://bugs.launchpad.net/bugs/39
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 pa
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 hand
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.
https://bugs.launchpad.net/b
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.
https://bugs.launchpad.net/bugs/104
For the record, this bites QEMU compiled on Natty as well (and results
in an immediate crash on startup).
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/721531
Title:
[armel] gcc computes wrong addre
This is the result of a bug in the configure script which was fixed by this
commit:
http://git.linaro.org/gitweb?p=qemu/qemu-linaro.git;a=commitdiff;h=20fa53ece42bec6ce5db801bead125277b26ab8a;hp=4429ab4419609f3a0b470e4b15c37c6cb5a6a400
That is in 2011.07 but not 2011.06.
qemu-linaro-0.15.50-2011
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 wi
Oh, and also you (probably) don't want to set the environment variable
for running 64 bit guests as I suspect it will unnecessarily restrict
the total amount of RAM that they can use.
Re: doing it upstream: the current status of the discussion is here (plus
followups):
http://lists.gnu.org/archi
Loic: You don't want to do it on 32 bit platforms, but for 64 bit hosts
I think it should be OK.
The only thing that I can think of that is likely to break is if the
user has a "ulimit -v" setting which we would now be breaching.
--
You received this bug notification because you are a member of
** Changed in: qemu-linaro
Status: Confirmed => Fix Committed
** Changed in: qemu-linaro
Milestone: None => 2012.03
--
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-linar
Upstream says that apparently Spice does work on 32 bit hosts now (the
FAQ is out of date). I've put the necessary compilation warning fixes
into qemu-linaro pending them being committed upstream.
Steve: this means you'll want to unwind the 'don't build qemu-kvm-spice
on i386' change in the packag
Oh, boehm gc. There are several known problems with that. The OpenSuSE
folks have done some work which deals with this but it's not upstream
yet (and at least one of the fixes is a hack which won't get accepted
upstream and where the right fix is probably at least several weeks
work).
--
You rece
This workaround turns out to cause some regressions in other cases, for example:
http://comments.gmane.org/gmane.comp.emulators.qemu/138180
which seems to be because when we use -R (either explicitly or
implicitly because of this patch) we tend to map the guest stack
immediately above the guest da
Your patch is wrong because the reason we disable use of ucontext on ARM
is because eglibc provides only stub versions which always fail...
The right fix here is to update the gthread code so it uses whatever the
non-deprecated APIs are (plus fallback to the deprecated versions so we
don't break o
I'm not sure. I don't have a feel for whether it has fixed more cases
than it has broken or vice-versa, I'm afraid.
--
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 chroot
I've submitted this patch upstream:
http://patchwork.ozlabs.org/patch/144426/
(only tested compilation on a precise chroot on an i386 box with the configure
test nobbled to always fall back to gthreads, but it should fix the ARM build
problem too). The patch seems kinda ugly, although really it's
NB that that asflags thing is just a work around, not an actual fix.
This bug was addressed in the toolchain:
http://sourceware.org/bugzilla/show_bug.cgi?id=12698
and seems to be fixed in at least some of the linaro toolchain packages --
maybe it just failed to get into the lucid one somehow?
*
** Package changed: ubuntu => armel-cross-toolchain-base (Ubuntu)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/947111
Title:
-march bug when building kernel
To manage notifications about this bug
This time for sure!
** Changed in: qemu-linaro
Status: Triaged => Fix Committed
** Changed in: qemu-linaro
Milestone: None => 2012.04
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/928432
** Changed in: qemu-linaro
Status: New => Invalid
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/696794
Title:
eglibc lacks getcontext() on ARM
To manage notifications about this bug go to:
h
I've committed the fix for missing ppoll on the basis that it is the bug
you've reported. I suspect it's not the bug you actually care about --
if the sigill still persists please file a new bug report, preferably
with a reasonably easy to reproduce test case...
** Changed in: qemu-linaro
Mil
Yes, I've seen the bash failures too. They should be fixed by
http://patchwork.ozlabs.org/patch/144476/ which I'm intending to put
into qemu-linaro for next week's release.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.l
I've committed to qemu-linaro the default-to-R-on-64-bit-hosts patch (so
Steve, you'll want to drop it from the packaging) and also the followup
patch which fixes the bash issues Loic lists. These will both be in
qemu-linaro 2011.03 (due this Thursday!)
** Changed in: qemu-linaro
Status: N
** 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 m
** 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 notif
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
Bu
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 Ubu
...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 becau
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
** 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 notifica
SDL is only of any use for the system emulation targets. If you're just
building a linux-user target there is no point passing --enable-sdl to
configure. Just use "./configure --static --target-list=i386-linux-
user".
--
You received this bug notification because you are a member of Ubuntu
Bugs,
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
Tit
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 spac
#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 setx
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 Pr
LInaro QEMU releases are source tarball downloads, in this case at
https://launchpad.net/qemu-linaro/trunk/2012.01 . "Fix released" for
"Linaro QEMU" means "in the source tarball".
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https:
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 tes
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 r
This was fixed in device-tree-compiler 1.3.0-2, which now produces
libfdt1 and libfdt-dev packages.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/843013
Title:
Split device-tree-compiler and libfdt
We don't generally mark bugs 'fix released' until the final (non-rc)
release is made.
** Changed in: qemu
Status: Fix Released => 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/17
>From upstream QEMU's point of view the status of this bug is "it's an
old bug report that tended to accumulate 'this seems like it's the same
as my bug' extra comments; we have fixed the underlying cause of the
original bug, so leave this one closed and file new ones with proper
reproducer instru
There seem to be two parts to this. Firstly, with a big reserved-region,
which is the default for 32-bit-guest-on-64-bit-host, this code in
main.c:
if (reserved_va) {
mmap_next_start = reserved_va;
}
says to start trying for the next mmap address at the top of the
rese
On 16 March 2018 at 10:34, Richard Henderson
wrote:
> Limit this to 16M; there does not appear to be any special
> support for this in the kernel itself, at least for i686.
>
> Fixes: https://bugs.launchpad.net/bugs/1749393
> Signed-off-by: Richard Henderson
> ---
>
> Commentary in the launchpad
Just a note that the udev rules change from comment 6 seems to be
necessary to reliably get an image booted under QEMU to bring up a getty
on the serial console. What seems to happen without it is that udevd
spends all its time running copies of 'readlink', and it doesn't get
around to telling syst
Yes it did.
** Changed in: qemu
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/1319100
Title:
qemu-arm-static bug in signal handling causes mono and jav
I was able to reproduce this failure with QEMU 2.5, and the code runs OK
under QEMU current master, so I think this is fixed by the
threading/signal handling bugfixes we've done between then and now. I'm
going to close this as will-be-fixed-in-2.11 (though it's quite possible
it's already fixed in
We think we've fixed our linux-user threading issues, so if there are
still problems as of qemu-2.11 or later, please raise a fresh bug report
with repro instructions.
** Changed in: qemu
Status: Confirmed => Fix Committed
--
You received this bug notification because you are a member of
v2 of the patch (https://lists.gnu.org/archive/html/qemu-
devel/2017-11/msg01199.html) has been accepted upstream, though it isn't
in master yet.
** Tags added: linux-user
** Changed in: qemu
Status: New => In Progress
--
You received this bug notification because you are a member of Ub
** Summary changed:
- linux-user mode can't handle guest setting RLIMIT_AS (hangs running gnutls28
configure check code)
+ linux-user mode can't handle guest setting a very small RLIMIT_AS (hangs
running gnutls28, coreutils configure check code)
** Tags added: linux-user
--
You received this
1 - 100 of 235 matches
Mail list logo
