[Qemu-devel] [Bug 893208] Re: qemu on ARM hosts can't boot i386 image

Indeed, I had no problem booting the images this time around: https://asciinema.org/a/d2m42g5c0n3z2pnbskhirdv5j -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/893208 Title: qemu on ARM hosts can't

[Qemu-devel] [Bug 1529226] Re: qemu-i386-user on 32-bit Linux: uncaught target signal 11

compiled output, the build process is interrupted: qemu: uncaught target signal 11 (Segmentation fault) - core dumped i686-unknown-linux-gnu/stage0/bin/rustc: line 1: 7474 Segmentation fault /usr/local/bin/qemu-i386 -cpu qemu32 /home/petevine/stage0/rustc.bin -C target-cpu=pentium2 -L /home

[Qemu-devel] [Bug 1529226] Re: qemu-i386-user on 32-bit Linux: uncaught target signal 11

gnu/stage0/bin/rustc: line 1: 7474 Segmentation fault /usr/local/bin/qemu-i386 -cpu qemu32 /home/petevine/stage0/rustc.bin -C target-cpu=pentium2 -L /home/petevine/unpacked/rust-master/i686-unknown-linux-gnu/stage0/lib/rustlib/i686-unknown-linux-gnu/lib/ "$@" make: *** [i686-unkn

[Qemu-devel] [Bug 1568107] [NEW] setup_rt_frame: not implemented

Public bug reported: Trying to run this binary (https://github.com/ethcore/parity/releases/download/v1.0.1/parity_linux_1.0.1-0_amd64.deb) under qemu-x86_64 on ARM, ends like this: $ qemu-x86_64 parity --pruning fast setup_rt_frame: not implemented qemu: uncaught target signal 11 (Segmentation

[Qemu-devel] [Bug 893208] Re: qemu on ARM hosts can't boot i386 image

FWIW: Program received signal SIGINT, Interrupt. 0xb644f73c in seqlock_read_retry (sl=0xb6b2acc8 , start=0) at /tmp/qemu/include/qemu/seqlock.h:69 69 return unlikely(atomic_read(>sequence) != start); (gdb) bt #0 0xb644f73c in seqlock_read_retry (sl=0xb6b2acc8

[Qemu-devel] [Bug 893208] Re: qemu on ARM hosts can't boot i386 image

Unfortunately that doesn't seem to work. Qemu immediately goes into infinite loop and has to be killed -9. Building anything besides qemu-system-i386 leads to link errors: LINK x86_64-linux-user/qemu-x86_64 /usr/bin/ld.gold.real: error: ../libqemustub.a(cpu-get-icount.o): multiple definition

[Qemu-devel] [Bug 1556044] Re: Redox GUI hangs with 100% CPU on ARM

** Summary changed: - Redox GUI hangs with 100% CPU + Redox GUI hangs with 100% CPU on ARM -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1556044 Title: Redox GUI hangs with 100% CPU on ARM

[Qemu-devel] [Bug 1556044] [NEW] Redox GUI hangs with 100% CPU

Public bug reported: Booting into Redox OS cli on ARM with qemu-system-i386 works fine. However, starting the Redox GUI (orbital) brings up the graphical interface and then starts using 100% CPU. I'd guess it's related to mouse detection and handling. The OS image is fully usable on x86.

[Qemu-devel] [Bug 893208] Re: qemu on ARM hosts can't boot i386 image

Another OS that works: https://static.redox-os.org/redox-installer.iso -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/893208 Title: qemu on ARM hosts can't boot i386 image Status in QEMU:

[Qemu-devel] [Bug 1529226] [NEW] qemu-i386-user on 32-bit Linux: uncaught target signal 11

-gnu/stage0/bin/rustc: line 1: 7474 Segmentation fault /usr/local/bin/qemu-i386 -cpu qemu32 /home/petevine/stage0/rustc.bin -C target-cpu=pentium2 -L /home/petevine/unpacked/rust-master/i686-unknown-linux-gnu/stage0/lib/rustlib/i686-unknown-linux-gnu/lib/ "$@" make: *** [i686-unk

[Qemu-devel] [Bug 893208] Re: qemu on ARM hosts can't boot i386 image

Still present in 2.5. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/893208 Title: qemu on ARM hosts can't boot i386 image Status in QEMU: New Status in Linaro QEMU: New Bug description: If

[Qemu-devel] [Bug 1519037] Re: qemu-i386 32-bit segfault

It seems this crash only happens in xterm (and not normal console). Having compared the respective environment vars the culprit turned out to be: TERM=xterm-color You're welcome. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU.

[Qemu-devel] [Bug 1519037] [NEW] qemu-i386 32-bit segfault

Public bug reported: I'm getting segfaults on 32-bit linux trying to run binaries using qemu-i386 from git. These segfaults go away when run in gdb or strace - could it be about the environment somehow? In contrast qemu-x86_64 works fine. How can I pinpoint the cause of this? Thanks! **

[Qemu-devel] [Bug 893208] Re: qemu on ARM hosts can't boot i386 image

I tried installing openbsd yesterday from an official image to another raw image disk - no problem and the installed system works flawlessly. Hurd also boots fine (via grub) along with a few toy x86 kernels. It almost begins to look as if the raw images are ok whereas the qcow2 format is the

[Qemu-devel] [Bug 893208] Re: qemu on ARM hosts can't boot i386 image

BTW, it seems the more expensive (but vastly less popular) odroids like the xu4 are built around kvm enabled processors which is why this bug doesn't affect them. The most popular C1/C1+'s processor doesn't support kvm though so any update would be appreciated. -- You received this bug

[Qemu-devel] [Bug 1498144] Re: Failure booting hurd with qemu-system-i386 on ARM

In case anyone's interested I've just discovered booting in recovery mode (root already logged in) doesn't exhibit the problem with non- working keyboard. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU.

[Qemu-devel] [Bug 1469342] Re: qemu-i386 pentium3/athlon incorrect instruction set

I think I may have found the culprit - athlon is defined as 'PPRO_FEATURES + some additional features'. If PPRO_FEATURES is what I think it is (pentium pro) why does it have SSE and SSE2 defined? It should end with MMX. -- You received this bug notification because you are a member of qemu-

[Qemu-devel] [Bug 1498144] Re: Failure booting hurd with qemu-system-i386 on ARM

I've just tried again with the latest commits - hurd boots, hooray! -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1498144 Title: Failure booting hurd with qemu-system-i386 on ARM Status in

[Qemu-devel] [Bug 1498144] Re: Failure booting hurd with qemu-system-i386 on ARM

Even though not related to the original issue (was also happening on i386 a few days ago), after getting to the login prompt inside hurd the keyboard doesn't work and the only clue from the kernel at boot time might be this: 'Unexpected ACK from keyboard' or this: '/bin/console: could not

[Qemu-devel] [Bug 1498144] Re: Failure booting hurd with qemu-system-i386 on ARM

Lastly, the machine 'power down' button doesn't work and a new message appeared inside hurd: 'kdb: queue full' -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1498144 Title: Failure booting hurd

[Qemu-devel] [Bug 1498144] Re: Failure booting hurd with qemu-system-i386 on ARM

I can't get any more useful info - either the script is expecting some outdated version of python or there's simply nothing else to see cause qemu failed to start. For example: (gdb) source qemu-gdb.py (gdb) run Starting program: /usr/bin/qemu-system-i386 -m 512 -hda

[Qemu-devel] [Bug 1498144] Re: Failure booting hurd with qemu-system-i386 on ARM

All right, I'll rebuild and try qemu-gdb.py if still necessary. Do any fancy CFLAGS make a difference in performance or should they be avoided altogether on ARM? -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU.

[Qemu-devel] [Bug 893208] Re: qemu on ARM hosts can't boot i386 image

What a funny coincidence, just before getting all of that bug email (telepathy?), I decided to also try a debian hurd image, but it immediately aborts: qemu-system-i386: qemu-coroutine-lock.c:91: qemu_co_queue_restart_all: Assertion `qemu_in_coroutine()' failed. Aborted Is this known and/or

[Qemu-devel] [Bug 1498144] Re: Failure booting hurd with qemu-system-i386 on ARM

** Description changed: Trying to boot debian-hurd-20150320.img ends with: qemu-system-i386: qemu-coroutine-lock.c:91: qemu_co_queue_restart_all: Assertion `qemu_in_coroutine()' failed. Program received signal SIGABRT, Aborted. __libc_do_syscall () - at

[Qemu-devel] [Bug 1498144] [NEW] Failure booting hurd with qemu-system-i386 on ARM

Public bug reported: Trying to boot debian-hurd-20150320.img ends with: qemu-system-i386: qemu-coroutine-lock.c:91: qemu_co_queue_restart_all: Assertion `qemu_in_coroutine()' failed. Program received signal SIGABRT, Aborted. __libc_do_syscall () at

[Qemu-devel] [Bug 1469342] Re: qemu-i386 pentium3 incorrect instruction set

Still there in the latest master. To clarify, running the binary with the -cpu athlon switch (same instruction set as P3) also exhibits the problem whereas a real athlon SIGILL's correctly. ** Description changed: Running a binary containing a movsd instruction (SSE2) in 32-bit - qemu-i386

[Qemu-devel] [Bug 1469342] Re: qemu-i386 pentium3/athlon incorrect instruction set

After looking at target-i386/cpu.c, it's clear to me CPUID_SSE and CPUID_SSE2 are defined seperately and neither pentium3 nor athlon have those defines set. This could mean it's a bug not in the instruction set but possibly in the build process somewhere. -- You received this bug notification

[Qemu-devel] [Bug 1469342] Re: qemu-i386 pentium3/athlon incorrect instruction set

In the case it's really unfixable and both pentium3 and athlon are nothing more than aliases for 'QEMU Virtual CPU version 2.4.50' they should be removed from the list the user gets after: qemu-i386 -cpu help so as not to mislead. Thanks! -- You received this bug notification because you are a

[Qemu-devel] [Bug 1469342] Re: qemu-i386 pentium3/athlon incorrect instruction set

I'm pretty sure you're right regarding entire instruction sets - but surely simply disabling SSE2 is possible even now? (after all pentium2 and below doesn't have it) That could solve this problem with a simple hack like, eg. : pentium3 = $pentium3 - SSE2 -- You received this bug notification

[Qemu-devel] [Bug 893208] Re: qemu on ARM hosts can't boot i386 image

Just for laughs I 've tested my qemu build with this guy's x86 kernel and it's working as expected: https://github.com/mopp/Axel the difference being it was using -cdrom switch to boot from an .iso image -- You received this bug notification because you are a member of qemu- devel-ml, which is

[Qemu-devel] [Bug 893208] Re: qemu on ARM hosts can't boot i386 image

I was about to file a bug with the exact symptoms. I can't boot a (possibly the very one) debian wheezy standard qcow2 image on my Odroid C1 (works fine on x86-32 with the same command line) using qemu-system-i386 that I built yesterday from git source. Is there a workaround or has nobody needed

[Qemu-devel] [Bug 1469342] [NEW] qemu-i386 pentium3 incorrect instruction set

Public bug reported: Running a binary containing a movsd instruction (SSE2) in 32-bit qemu-i386 -cpu pentium3 from 20150609 results in flawless execution whereas it should crash with SIGILL as P3 only had SSE. ** Affects: qemu Importance: Undecided Status: New -- You received