diff options
Diffstat (limited to '')
| -rw-r--r-- | results/classifier/108/other/1625 | 28 | ||||
| -rw-r--r-- | results/classifier/108/other/1625216 | 100 | ||||
| -rw-r--r-- | results/classifier/108/other/1625295 | 301 | ||||
| -rw-r--r-- | results/classifier/108/other/1625987 | 83 |
4 files changed, 512 insertions, 0 deletions
diff --git a/results/classifier/108/other/1625 b/results/classifier/108/other/1625 new file mode 100644 index 000000000..14b250990 --- /dev/null +++ b/results/classifier/108/other/1625 @@ -0,0 +1,28 @@ +files: 0.843 +graphic: 0.817 +device: 0.727 +performance: 0.606 +semantic: 0.586 +network: 0.465 +vnc: 0.402 +debug: 0.382 +PID: 0.329 +socket: 0.271 +KVM: 0.259 +boot: 0.209 +other: 0.183 +permissions: 0.171 + +[7.2.0] Qemu process hang with `defunct` when using `-blockdev` json property which file doesn't exists +Description of problem: +When using `throttle` and `throttle-group` to apply block device QOS, +there is something wrong with check file exists validation. +In upper commands, if the file which located `/mnt/b3b8dfb5-0a7c-4285-81d8-2bf8d33a3297/32c55f5a-96d1-4af4-a149-c95fd6652e3e/b016af76-f6b1-4614-b29a-78917924e55e` doesn't exist, it just hang with `defunct` process. + +Steps to reproduce: +1. Start Guest with upper command. +2. Hanged with defunct process +3. +Additional information: + +- With GDB stack, i can find `no such file` error, but process don't exit diff --git a/results/classifier/108/other/1625216 b/results/classifier/108/other/1625216 new file mode 100644 index 000000000..656135fed --- /dev/null +++ b/results/classifier/108/other/1625216 @@ -0,0 +1,100 @@ +other: 0.827 +graphic: 0.752 +permissions: 0.748 +semantic: 0.736 +device: 0.722 +debug: 0.714 +network: 0.700 +PID: 0.691 +vnc: 0.618 +performance: 0.613 +socket: 0.562 +KVM: 0.511 +files: 0.490 +boot: 0.440 + +memory writes via gdb don't work for memory mapped hardware + +When I remote-debug a qemu-guest and attempt to write to a memory mapped location, the +write-handler for the concerned device will not be called. All write-requiests from +gdb are delegated to cpu_physical_memory_write_rom(...). a function that writes to the +underlying ram-block. + +I believe requests to memory mapped hardware should be delegated to +address_space_rw(). + +example: +;; a memory mapped device. No effect, the write-handler is not called +(gdb) set *0xfff3c000 = 48 + +;; a ram or rom-block. Thos works. The value is changed. +(gdb) set *0x100000 = 48 + + +---------------------------------------- + +Here's my suggested patch. As noted in the comment, it could perhaps be +improved for the (rare) case when the write-request from gdb spans multiple +memory regions. + +$ git diff 85bc2a15121e8bcd9f15eb75794a1eacca9d84bd HEAD ../exec.c +diff --git a/exec.c b/exec.c +index c4f9036..45ef896 100644 +--- a/exec.c ++++ b/exec.c +@@ -3676,6 +3676,7 @@ int cpu_memory_rw_debug(CPUState *cpu, target_ulong addr, + int l; + hwaddr phys_addr; + target_ulong page; ++ bool is_memcpy_access; + + while (len > 0) { + int asidx; +@@ -3691,13 +3692,32 @@ int cpu_memory_rw_debug(CPUState *cpu, target_ulong addr, + if (l > len) + l = len; + phys_addr += (addr & ~TARGET_PAGE_MASK); ++ + if (is_write) { ++ /* if ram/rom region we access the memory ++ via memcpy instead of via the cpu */ ++ hwaddr mr_len, addr1; ++ AddressSpace *as = cpu->cpu_ases[asidx].as; ++ MemoryRegion *mr = address_space_translate(as, phys_addr, &addr1, &mr_len, is_write); ++ is_memcpy_access = memory_region_is_ram(mr) || memory_region_is_romd(mr); ++ if(mr_len < len) { ++ /* TODO, mimic more of the loop over mr chunks as ++ done in cpu_physical_memory_write_internal */ ++ printf("warning: we dont know whether all bytes " ++ "to be written are ram/rom or io\n"); ++ } ++ } ++ else { ++ is_memcpy_access = false; ++ } ++ ++ if (is_write && is_memcpy_access) { + cpu_physical_memory_write_rom(cpu->cpu_ases[asidx].as, + phys_addr, buf, l); + } else { + address_space_rw(cpu->cpu_ases[asidx].as, phys_addr, + MEMTXATTRS_UNSPECIFIED, +- buf, l, 0); ++ buf, l, is_write); + } + len -= l; + buf += l; + +The code has moved around somewhat, but it's still true that writes by gdb don't go to devices -- cpu_memory_rw_debug() calls address_space_write_rom() which calls address_space_write_rom_internal() which simply skips writing for non-ram/rom regions. + +I'm not sure if the gdb accesses should be special cased or if we should just make address_space_write_rom() write to devices (which would also affect eg ELF file loading, which is useful in some odd corner cases). + + + +This is an automated cleanup. This bug report has been moved to QEMU's +new bug tracker on gitlab.com and thus gets marked as 'expired' now. +Please continue with the discussion here: + + https://gitlab.com/qemu-project/qemu/-/issues/213 + + diff --git a/results/classifier/108/other/1625295 b/results/classifier/108/other/1625295 new file mode 100644 index 000000000..2990724e6 --- /dev/null +++ b/results/classifier/108/other/1625295 @@ -0,0 +1,301 @@ +other: 0.833 +semantic: 0.758 +PID: 0.750 +debug: 0.742 +permissions: 0.725 +network: 0.715 +KVM: 0.713 +device: 0.701 +performance: 0.696 +socket: 0.693 +graphic: 0.678 +vnc: 0.677 +boot: 0.612 +files: 0.575 + +qemu-arm dies with libarmmem inside ld.so.preload + +When running raspbian inside qemu,the user has to first comment out the following line from /etc/ld.so.conf: + +/usr/lib/arm-linux-gnueabihf/libarmmem.so + + +Will future qemus will be able to work without changine /etc/ld.so.conf ? + +Which version of QEMU are you using? This is I think due to SETEND emulation, which I thought we had implemented now. + +If this still doesn't work on QEMU 2.7, please can you provide full instructions to reproduce the problem (assume I know nothing about how to get raspbian or run it on QEMU). + + +- I'm on Ubuntu 16.04, and it looks like it's 2.6.1 + +qemu-arm version 2.6.1 (Debian 1:2.6.1+dfsg-0~16.04), Copyright (c) +2003-2008 Fabrice Bellard + +Is there a PPA for qemu 2.7 somewhere ? + + +On 19 September 2016 at 21:27, Peter Maydell <email address hidden> +wrote: + +> Which version of QEMU are you using? This is I think due to SETEND +> emulation, which I thought we had implemented now. +> +> If this still doesn't work on QEMU 2.7, please can you provide full +> instructions to reproduce the problem (assume I know nothing about how +> to get raspbian or run it on QEMU). +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1625295 +> +> Title: +> qemu-arm dies with libarmmem inside ld.so.preload +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1625295/+subscriptions +> + + +On 20 September 2016 at 00:02, Stu <email address hidden> wrote: +> - I'm on Ubuntu 16.04, and it looks like it's 2.6.1 +> +> qemu-arm version 2.6.1 (Debian 1:2.6.1+dfsg-0~16.04), Copyright (c) +> 2003-2008 Fabrice Bellard +> +> Is there a PPA for qemu 2.7 somewhere ? + +You'd need to ask the Ubuntu folks about that. Upstream +we provide source code distributions only. + +thanks +-- PMM + + +Cheers :) + +May as well close this, I'll re-open it if I try 2.7 and find the same bug. + +Testing involves trying stock raspbian in qemu. + + +On 20 September 2016 at 10:26, Peter Maydell <email address hidden> +wrote: + +> On 20 September 2016 at 00:02, Stu <email address hidden> wrote: +> > - I'm on Ubuntu 16.04, and it looks like it's 2.6.1 +> > +> > qemu-arm version 2.6.1 (Debian 1:2.6.1+dfsg-0~16.04), Copyright (c) +> > 2003-2008 Fabrice Bellard +> > +> > Is there a PPA for qemu 2.7 somewhere ? +> +> You'd need to ask the Ubuntu folks about that. Upstream +> we provide source code distributions only. +> +> thanks +> -- PMM +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1625295 +> +> Title: +> qemu-arm dies with libarmmem inside ld.so.preload +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1625295/+subscriptions +> + + +As I say, for providing reproduction instructions you have to assume I know nothing about raspbian, so "trying stock raspbian in qemu" is not detailed enough. I was looking for details more like "download this particular image from this website and then run this specific QEMU commandline, and then in the guest do <this thing> and it fails in <this way>". + + +Are bash scripts OK ? + + +I put everything into some scripts - I'm on ubuntu, debian should be +similar - not sure about other platforms. + + +# Grab scripts +$ git clone https://github.com/stuaxo/raspbian-qemu-scripts +$ cd raspbian-qemu-scripts + +# Download current raspbian lite to /tmp/raspbian: +$ ./download-raspbian.sh + + + + +# Test that may fail - run +/tmp/raspbian/2016-05-27-raspbian-jessie-lite.img in qemu: +$ ./run_qemu.sh + + + +# If the above fails, then it's you can edit /etc/ld.so.preload --- +$ ./mount-raspbian.sh + +^ mounts the image to /tmp/raspbian/ + +Now edit the file /tmp/raspbian/etc/ld.so.preload and comment any lines, +e.g + +$ sudo nano -w /tmp/raspbian/mnt/etc/ld.so.preload + +$ umount /tmp/raspbian + +## Test again in qemu + +$ ./run_qemu.sh + + + +One I get do the edit, qemu works for me. +To get chroot working, one has to mount the image and copy the file + +$ ./mount-raspbian.sh +$ sudo cp /usr/bin/qemu-arm-static /tmp/raspbian/mnt/usr/bin + +# After that chroot works... +$ sudo chroot /tmp/raspbian/mnt + +-- Remember to umount the image before using qemu + but mount for chroot :) + + + + + + + + + + + +On 20 September 2016 at 11:22, Peter Maydell <email address hidden> +wrote: + +> As I say, for providing reproduction instructions you have to assume I +> know nothing about raspbian, so "trying stock raspbian in qemu" is not +> detailed enough. I was looking for details more like "download this +> particular image from this website and then run this specific QEMU +> commandline, and then in the guest do <this thing> and it fails in <this +> way>". +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1625295 +> +> Title: +> qemu-arm dies with libarmmem inside ld.so.preload +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1625295/+subscriptions +> + + +Thanks. I can reproduce this with the current QEMU, so there is still a problem of some kind here. + + +Awesome, cheers :) + +On 20 September 2016 at 14:29, Peter Maydell <email address hidden> +wrote: + +> Thanks. I can reproduce this with the current QEMU, so there is still a +> problem of some kind here. +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1625295 +> +> Title: +> qemu-arm dies with libarmmem inside ld.so.preload +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1625295/+subscriptions +> + + +This turns out to be nothing to do with setend. We're doing something wrong emulating the following nasty hack: +https://github.com/bavison/arm-mem/blob/master/architecture.S + +.arm +architecture: + sub pc, pc, #1 @ is an interworking branch on ARMv7, not ARMv6 + and a1, a4, a1 @ second word interpreted as 'B .+0xA' if Thumb + mov a1, #6 + bx lr +.thumb + mov a1, #7 + bx lr + +so after the 'sub pc, pc, #1' (which in my debug trace is at address 0xb6f086dc) QEMU next tries to execute from 0xb6f086e2 in ARM mode, which is neither of the two expected outcomes. As it happens we hit an undefined instruction pretty much immediately afterwards: + +0xb6f086e2: 0006e003 andeq lr, r6, r3 +0xb6f086e6: ff1ee3a0 undefined instruction 0xff1ee3a0 + + + +Patch which fixes this: http://patchwork.ozlabs.org/patch/672288/ + + +Now fixed in QEMU master, commit 9b6a3ea7a69959416. + + +Awesome, thanks :) + +On 4 October 2016 at 15:55, Peter Maydell <email address hidden> wrote: + +> Now fixed in QEMU master, commit 9b6a3ea7a69959416. +> +> +> ** Changed in: qemu +> Status: In Progress => Fix Committed +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1625295 +> +> Title: +> qemu-arm dies with libarmmem inside ld.so.preload +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1625295/+subscriptions +> + + +Quick followup on this, finally got the time to build this + can confirming I can boot raspbian with the default /etc/ld.so.conf to the command prompt (both raspbian jessie lite and the default distro). + +NB that commit 9b6a3ea7a69959416 had a bug (it broke exception return to Thumb code), so you should also make sure you have commit fb0e8e79a9d77 which fixes that bug. + + +Yup, got it - cheers :) + +On 20 October 2016 at 08:41, Peter Maydell <email address hidden> wrote: + +> NB that commit 9b6a3ea7a69959416 had a bug (it broke exception return to +> Thumb code), so you should also make sure you have commit fb0e8e79a9d77 +> which fixes that bug. +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1625295 +> +> Title: +> qemu-arm dies with libarmmem inside ld.so.preload +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1625295/+subscriptions +> + + +Released with version 2.8 + diff --git a/results/classifier/108/other/1625987 b/results/classifier/108/other/1625987 new file mode 100644 index 000000000..63142c09d --- /dev/null +++ b/results/classifier/108/other/1625987 @@ -0,0 +1,83 @@ +semantic: 0.627 +device: 0.580 +PID: 0.567 +performance: 0.557 +socket: 0.484 +graphic: 0.418 +network: 0.397 +permissions: 0.387 +boot: 0.340 +KVM: 0.333 +vnc: 0.319 +other: 0.288 +files: 0.244 +debug: 0.159 + +target-arm/translate-a64.c:2028: possible coding error ? + +target-arm/translate-a64.c:2028:37: warning: ?: using integer constants in boolean context [-Wint-in-bool-context] + +Source code is + + bool iss_sf = opc == 0 ? 32 : 64; + +Maybe better code + + bool iss_sf = (opc == 0) ? 32 : 64; + +This is clearly a bug, but your suggested change won't deal with the problem, which is that we're trying to set a bool so the ? 32 : 64 construct is just wrong. + + +On 22 September 2016 at 02:53, Peter Maydell <email address hidden> wrote: +> This is clearly a bug, but your suggested change won't deal with the +> problem, which is that we're trying to set a bool so the ? 32 : 64 +> construct is just wrong. + +> Bug description: +> target-arm/translate-a64.c:2028:37: warning: ?: using integer +> constants in boolean context [-Wint-in-bool-context] +> +> Source code is +> +> bool iss_sf = opc == 0 ? 32 : 64; + +Edgar, did you want to look at a fix for this? It was introduced +in your commit aaa1f954d4 adding syndrome info for loads and stores. + +thanks +-- PMM + + +On Thu, Sep 29, 2016 at 06:40:53PM -0700, Peter Maydell wrote: +> On 22 September 2016 at 02:53, Peter Maydell <email address hidden> wrote: +> > This is clearly a bug, but your suggested change won't deal with the +> > problem, which is that we're trying to set a bool so the ? 32 : 64 +> > construct is just wrong. +> +> > Bug description: +> > target-arm/translate-a64.c:2028:37: warning: ?: using integer +> > constants in boolean context [-Wint-in-bool-context] +> > +> > Source code is +> > +> > bool iss_sf = opc == 0 ? 32 : 64; +> +> Edgar, did you want to look at a fix for this? It was introduced +> in your commit aaa1f954d4 adding syndrome info for loads and stores. + +Hi Peter, + +Yes, I've just posted a fix to the list. +It should have been: + +bool iss_sf = opc == 0 ? false : true; + +Cheers, +Edgar + + +Now fixed in master, commit 173ff58580b383a7841. + + +Released with v2.8 + |