diff options
Diffstat (limited to 'results/classifier/zero-shot/118/user-level-arm')
4 files changed, 618 insertions, 0 deletions
diff --git a/results/classifier/zero-shot/118/user-level-arm/1829079 b/results/classifier/zero-shot/118/user-level-arm/1829079 new file mode 100644 index 000000000..f75793749 --- /dev/null +++ b/results/classifier/zero-shot/118/user-level-arm/1829079 @@ -0,0 +1,95 @@ +user-level: 0.914 +graphic: 0.894 +mistranslation: 0.889 +architecture: 0.870 +files: 0.858 +semantic: 0.854 +arm: 0.807 +performance: 0.768 +ppc: 0.749 +PID: 0.743 +register: 0.679 +debug: 0.656 +device: 0.644 +vnc: 0.636 +virtual: 0.622 +permissions: 0.613 +kernel: 0.605 +network: 0.516 +socket: 0.505 +x86: 0.465 +peripherals: 0.462 +risc-v: 0.458 +boot: 0.458 +TCG: 0.449 +VMM: 0.421 +hypervisor: 0.390 +assembly: 0.387 +KVM: 0.312 +i386: 0.275 +-------------------- +arm: 0.996 +user-level: 0.981 +files: 0.092 +debug: 0.036 +TCG: 0.027 +network: 0.026 +virtual: 0.015 +register: 0.012 +PID: 0.009 +semantic: 0.006 +device: 0.006 +kernel: 0.005 +architecture: 0.005 +socket: 0.004 +hypervisor: 0.004 +performance: 0.002 +boot: 0.002 +vnc: 0.002 +graphic: 0.002 +VMM: 0.001 +risc-v: 0.001 +permissions: 0.001 +peripherals: 0.001 +assembly: 0.001 +mistranslation: 0.001 +ppc: 0.000 +x86: 0.000 +i386: 0.000 +KVM: 0.000 + +Can't build static on ARM (Raspbian) + +I am trying to build static QEMU on Raspbian, chrooted into using systemd-nspawn with QEMU 4.0.0. +This is how my compiling looks: +https://pastebin.com/PYZYeRCN +Just the problematic part: +https://pastebin.com/7LxWPMxA +How I do the compiling: +https://pastebin.com/pYM17A6R (I plan to share this tutorial when it will work) +It is a coincidence, or the build fails because it cannot find lp11-kit. I did some symlinks: +ln -s /usr/lib/arm-linux-gnueabihf/libp11-kit.so.0 /usr/lib/libp11-kit.so.0 +ln -s /usr/lib/arm-linux-gnueabihf/libp11-kit.so /usr/lib/libp11-kit.so +(should I also symlink libp11.so and libp11.so.2? I think I have installed all required p11 packages! + +Git commit hash: git rev-parse HEAD +e329ad2ab72c43b56df88b34954c2c7d839bb373 + +This looks Debian specific. Not sure why you have to install the p11-kit/libp11-dev/libp11-2 packages although. + +I agree with Philippe - if you have to symlink your libraries like this, it is certainly not a bug in QEMU, but a problem of your distro. So please report this issue in your distro bugtracker instead. + +You might find that adding --disable-tools to your configure line also helps in not trying to statically link random binaries you don't really want. + + +Well, the symlinks didn't resolve the issue. I just tried them to see if this will solve the issue. + +And I installed a lot of packages, blindly trying to solve this issue. Using full Raspbian instead of Raspbian Lite was also an attempt to do so. I'm just an advanced Linux user, not a developer! I will cut the list down to the necessary ones when I get it to compile! + +pmaydell: Thank you a lot, it compiles successfully with --disable-tools in configure. I have one question... does it affect how QEMU static binary works in any way? I'm just curious. + + + + +No, --disable-tools won't change the qemu-* binaries that are built. It just stops us trying to build some binaries like the 'ivshmem-client' one that was causing a problem for you. + diff --git a/results/classifier/zero-shot/118/user-level-arm/1859384 b/results/classifier/zero-shot/118/user-level-arm/1859384 new file mode 100644 index 000000000..509c2c16c --- /dev/null +++ b/results/classifier/zero-shot/118/user-level-arm/1859384 @@ -0,0 +1,390 @@ +user-level: 0.884 +files: 0.856 +debug: 0.847 +arm: 0.845 +assembly: 0.841 +register: 0.838 +device: 0.834 +semantic: 0.828 +peripherals: 0.825 +ppc: 0.804 +permissions: 0.803 +graphic: 0.791 +architecture: 0.791 +boot: 0.783 +PID: 0.782 +risc-v: 0.778 +vnc: 0.772 +performance: 0.749 +VMM: 0.729 +virtual: 0.707 +hypervisor: 0.696 +socket: 0.637 +TCG: 0.617 +mistranslation: 0.609 +kernel: 0.581 +KVM: 0.489 +network: 0.439 +x86: 0.391 +i386: 0.258 +-------------------- +arm: 0.998 +debug: 0.711 +assembly: 0.703 +kernel: 0.670 +register: 0.105 +user-level: 0.102 +architecture: 0.098 +PID: 0.090 +semantic: 0.051 +device: 0.044 +hypervisor: 0.035 +files: 0.035 +virtual: 0.030 +performance: 0.026 +peripherals: 0.008 +TCG: 0.007 +socket: 0.005 +network: 0.004 +graphic: 0.002 +permissions: 0.002 +VMM: 0.001 +boot: 0.001 +vnc: 0.001 +ppc: 0.001 +KVM: 0.001 +risc-v: 0.001 +mistranslation: 0.000 +x86: 0.000 +i386: 0.000 + +arm gic: gic_acknowledge_irq doesn't clear line level for other cores for 1-n level-sensitive interrupts and gic_clear_pending uses GIC_DIST_TEST_MODEL (even on v2 where it always read 0 - "N-N") + +For a 1-N interrupt (any SPI on the GICv2), as mandated by the TRM, only one CPU can acknowledge the IRQ until it becomes inactive. + +The TRM also mandates that SGIs and PPIs follow the N-N model and that SPIs follow the 1-N model. + +However this is not currently the case with QEMU. I have locally (no minimal test case) seen e.g. uart interrupts being acknowledged twice before having been deactivated (expected: irqId on one CPU and 1023 on the other instead). + +I have narrowed the issue down to the following: + +1) arm_gic_common_reset resets all irq_state[id] fields to 0. This means all IRQ will use the N-N model, and if s->revision != REV_11MPCORE, then there's no way to set any interrupt to 1-N. + +**If fixed locally** with a hackjob, I still have the following trace: + +pl011_irq_state 534130.800 pid=2424 level=0x1 +gic_set_irq 2.900 pid=2424 irq=0x21 level=0x1 cpumask=0xff target=0xff +gic_update_set_irq 3.300 pid=2424 cpu=0x0 name=irq level=0x1 +gic_update_set_irq 4.200 pid=2424 cpu=0x1 name=irq level=0x1 +gic_acknowledge_irq 539.400 pid=2424 s=cpu cpu=0x1 irq=0x21 +gic_update_set_irq 269.800 pid=2424 cpu=0x0 name=irq level=0x1 +gic_cpu_read 4.100 pid=2424 s=cpu cpu=0x1 addr=0xc val=0x21 +gic_acknowledge_irq 15.600 pid=2424 s=cpu cpu=0x0 irq=0x21 +gic_cpu_read 265.000 pid=2424 s=cpu cpu=0x0 addr=0xc val=0x21 +pl011_write 1594.700 pid=2424 addr=0x44 value=0x50 +pl011_irq_state 2.000 pid=2424 level=0x0 +gic_set_irq 1.300 pid=2424 irq=0x21 level=0x0 cpumask=0xff target=0xff +pl011_write 30.700 pid=2424 addr=0x38 value=0x0 +pl011_irq_state 1.200 pid=2424 level=0x0 +gic_cpu_write 110.600 pid=2424 s=cpu cpu=0x0 addr=0x10 val=0x21 +gic_cpu_write 193.400 pid=2424 s=cpu cpu=0x0 addr=0x1000 val=0x21 +pl011_irq_state 1169.500 pid=2424 level=0x0 + +This is because: + +2) gic_acknowledge_irq calls gic_clear_pending which uses GIC_DIST_CLEAR_PENDING but this usually has no effect on level-sensitive interrupts. + +With this often being a no-op (ie. assuming ispendr was not written to), any 1-n level-sensitive interrupt is still improperly pending on all the other cores. + +(Also, I don't really know how the qemu thread model works, there might be race conditions in the acknowledgment logic if gic_acknowledge_irq is called by multiple threads, too.) + + +Alex Longwall <email address hidden> writes: + +> Public bug reported: +> +> For a 1-N interrupt (any SPI on the GICv2), as mandated by the TRM, only +> one CPU can acknowledge the IRQ until it becomes inactive. +> +> The TRM also mandates that SGIs and PPIs follow the N-N model and that +> SPIs follow the 1-N model. +> +> However this is not currently the case with QEMU. I have locally (no +> minimal test case) seen e.g. uart interrupts being acknowledged twice +> before having been deactivated (expected: irqId on one CPU and 1023 on +> the other instead). + +You might find there is enough in kvm-unit-tests GIC tests already to +build a test case for what you are seeing. + +> +> I have narrowed the issue down to the following: +> +> 1) arm_gic_common_reset resets all irq_state[id] fields to 0. This means +> all IRQ will use the N-N model, and if s->revision != REV_11MPCORE, then +> there's no way to set any interrupt to 1-N. +> +> If ""fixed"" locally with a hackjob, I still have the following trace: +> +> pl011_irq_state 534130.800 pid=2424 level=0x1 +> gic_set_irq 2.900 pid=2424 irq=0x21 level=0x1 cpumask=0xff target=0xff +> gic_update_set_irq 3.300 pid=2424 cpu=0x0 name=irq level=0x1 +> gic_update_set_irq 4.200 pid=2424 cpu=0x1 name=irq level=0x1 +> gic_acknowledge_irq 539.400 pid=2424 s=cpu cpu=0x1 irq=0x21 +> gic_update_set_irq 269.800 pid=2424 cpu=0x0 name=irq level=0x1 +> gic_cpu_read 4.100 pid=2424 s=cpu cpu=0x1 addr=0xc val=0x21 +> gic_acknowledge_irq 15.600 pid=2424 s=cpu cpu=0x0 irq=0x21 +> gic_cpu_read 265.000 pid=2424 s=cpu cpu=0x0 addr=0xc val=0x21 +> pl011_write 1594.700 pid=2424 addr=0x44 value=0x50 +> pl011_irq_state 2.000 pid=2424 level=0x0 +> gic_set_irq 1.300 pid=2424 irq=0x21 level=0x0 cpumask=0xff target=0xff +> pl011_write 30.700 pid=2424 addr=0x38 value=0x0 +> pl011_irq_state 1.200 pid=2424 level=0x0 +> gic_cpu_write 110.600 pid=2424 s=cpu cpu=0x0 addr=0x10 val=0x21 +> gic_cpu_write 193.400 pid=2424 s=cpu cpu=0x0 addr=0x1000 val=0x21 +> pl011_irq_state 1169.500 pid=2424 level=0x0 +> +> This is because: +> +> 2) gic_acknowledge_irq calls gic_clear_pending which uses +> GIC_DIST_CLEAR_PENDING but this usually has no effect on level-sensitive +> interrupts. +> +> With this often being a no-op (ie. assuming ispendr was not written to), +> any 1-n level-sensitive interrupt is still improperly pending on all the +> other cores. +> +> (Also, I don't really know how the qemu thread model works, there might +> be race conditions in the acknowledgment logic if gic_acknowledge_irq is +> called by multiple threads, too.) + +All updates to the GIC internals should be protected by the BQL which +applies to all mmio emulated devices. + +> +> Option used: +> -nographic -machine virt,virtualization=on,accel=tcg,gic-version=2 -cpu cortex-a57 -smp 4 -m 1024 +> -kernel whatever.elf -d unimp,guest_errors -semihosting-config enable,target=native +> -chardev stdio,id=uart -serial chardev:uart -monitor none +> -trace gic_update_set_irq -trace gic_acknowledge_irq -trace pl011_irq_state -trace pl011_write -trace gic_cpu_read -trace gic_cpu_write +> -trace gic_set_irq +> +> Commit used: dc65a5bdc9fa543690a775b50d4ffbeb22c56d6d "Merge remote- +> tracking branch 'remotes/dgibson/tags/ppc-for-5.0-20200108' into +> staging" +> +> ** Affects: qemu +> Importance: Undecided +> Status: New +> +> +> ** Tags: arm gic +> +> ** Description changed: +> +> For a 1-N interrupt (any SPI on the GICv2), as mandated by the TRM, only +> one CPU can acknowledge the IRQ until it becomes inactive. +> +> The TRM also mandates that SGIs and PPIs follow the N-N model and that +> SPIs follow the 1-N model. +> +> However this is not currently the case with QEMU. I have locally (no +> minimal test case) seen e.g. uart interrupts being acknowledged twice +> before having been deactivated (expected: irqId on one CPU and 1023 on +> the other instead). +> +> I have narrowed the issue down to the following: +> +> 1) arm_gic_common_reset resets all irq_state[id] fields to 0. This means +> all IRQ will use the N-N model, and if s->revision != REV_11MPCORE, then +> there's no way to set any interrupt to 1-N. +> +> **If fixed locally** with a hackjob, I still have the following trace: +> +> pl011_irq_state 534130.800 pid=2424 level=0x1 +> gic_set_irq 2.900 pid=2424 irq=0x21 level=0x1 cpumask=0xff target=0xff +> gic_update_set_irq 3.300 pid=2424 cpu=0x0 name=irq level=0x1 +> gic_update_set_irq 4.200 pid=2424 cpu=0x1 name=irq level=0x1 +> gic_acknowledge_irq 539.400 pid=2424 s=cpu cpu=0x1 irq=0x21 +> gic_update_set_irq 269.800 pid=2424 cpu=0x0 name=irq level=0x1 +> gic_cpu_read 4.100 pid=2424 s=cpu cpu=0x1 addr=0xc val=0x21 +> gic_acknowledge_irq 15.600 pid=2424 s=cpu cpu=0x0 irq=0x21 +> gic_cpu_read 265.000 pid=2424 s=cpu cpu=0x0 addr=0xc val=0x21 +> pl011_write 1594.700 pid=2424 addr=0x44 value=0x50 +> pl011_irq_state 2.000 pid=2424 level=0x0 +> gic_set_irq 1.300 pid=2424 irq=0x21 level=0x0 cpumask=0xff target=0xff +> pl011_write 30.700 pid=2424 addr=0x38 value=0x0 +> pl011_irq_state 1.200 pid=2424 level=0x0 +> gic_cpu_write 110.600 pid=2424 s=cpu cpu=0x0 addr=0x10 val=0x21 +> gic_cpu_write 193.400 pid=2424 s=cpu cpu=0x0 addr=0x1000 val=0x21 +> pl011_irq_state 1169.500 pid=2424 level=0x0 +> +> This is because: +> +> 2) gic_acknowledge_irq calls gic_clear_pending which uses +> GIC_DIST_CLEAR_PENDING but this usually has no effect on level-sensitive +> interrupts. +> +> With this often being a no-op (ie. assuming ispendr was not written to), +> any 1-n level-sensitive interrupt is still improperly pending on all the +> other cores. +> +> (Also, I don't really know how the qemu thread model works, there might +> be race conditions in the acknowledgment logic if gic_acknowledge_irq is +> called by multiple threads, too.) +> + +> + Option used: +> + -nographic -machine virt,virtualization=on,accel=tcg,gic-version=2 -cpu cortex-a57 -smp 4 -m 1024 +> + -kernel whatever.elf -d unimp,guest_errors -semihosting-config enable,target=native +> + -chardev stdio,id=uart -serial chardev:uart -monitor none +> + -trace gic_update_set_irq -trace gic_acknowledge_irq -trace pl011_irq_state -trace pl011_write -trace gic_cpu_read -trace gic_cpu_write +> + -trace gic_set_irq +> + +> + Commit used: dc65a5bdc9fa543690a775b50d4ffbeb22c56d6d "Merge remote- +> + tracking branch 'remotes/dgibson/tags/ppc-for-5.0-20200108' into +> + staging" +> +> ** Description changed: +> +> For a 1-N interrupt (any SPI on the GICv2), as mandated by the TRM, only +> one CPU can acknowledge the IRQ until it becomes inactive. +> +> The TRM also mandates that SGIs and PPIs follow the N-N model and that +> SPIs follow the 1-N model. +> +> However this is not currently the case with QEMU. I have locally (no +> minimal test case) seen e.g. uart interrupts being acknowledged twice +> before having been deactivated (expected: irqId on one CPU and 1023 on +> the other instead). +> +> I have narrowed the issue down to the following: +> +> 1) arm_gic_common_reset resets all irq_state[id] fields to 0. This means +> all IRQ will use the N-N model, and if s->revision != REV_11MPCORE, then +> there's no way to set any interrupt to 1-N. +> +> - **If fixed locally** with a hackjob, I still have the following trace: +> + If ""fixed"" locally with a hackjob, I still have the following trace: +> +> pl011_irq_state 534130.800 pid=2424 level=0x1 +> gic_set_irq 2.900 pid=2424 irq=0x21 level=0x1 cpumask=0xff target=0xff +> gic_update_set_irq 3.300 pid=2424 cpu=0x0 name=irq level=0x1 +> gic_update_set_irq 4.200 pid=2424 cpu=0x1 name=irq level=0x1 +> gic_acknowledge_irq 539.400 pid=2424 s=cpu cpu=0x1 irq=0x21 +> gic_update_set_irq 269.800 pid=2424 cpu=0x0 name=irq level=0x1 +> gic_cpu_read 4.100 pid=2424 s=cpu cpu=0x1 addr=0xc val=0x21 +> gic_acknowledge_irq 15.600 pid=2424 s=cpu cpu=0x0 irq=0x21 +> gic_cpu_read 265.000 pid=2424 s=cpu cpu=0x0 addr=0xc val=0x21 +> pl011_write 1594.700 pid=2424 addr=0x44 value=0x50 +> pl011_irq_state 2.000 pid=2424 level=0x0 +> gic_set_irq 1.300 pid=2424 irq=0x21 level=0x0 cpumask=0xff target=0xff +> pl011_write 30.700 pid=2424 addr=0x38 value=0x0 +> pl011_irq_state 1.200 pid=2424 level=0x0 +> gic_cpu_write 110.600 pid=2424 s=cpu cpu=0x0 addr=0x10 val=0x21 +> gic_cpu_write 193.400 pid=2424 s=cpu cpu=0x0 addr=0x1000 val=0x21 +> pl011_irq_state 1169.500 pid=2424 level=0x0 +> +> This is because: +> +> 2) gic_acknowledge_irq calls gic_clear_pending which uses +> GIC_DIST_CLEAR_PENDING but this usually has no effect on level-sensitive +> interrupts. +> +> With this often being a no-op (ie. assuming ispendr was not written to), +> any 1-n level-sensitive interrupt is still improperly pending on all the +> other cores. +> +> (Also, I don't really know how the qemu thread model works, there might +> be race conditions in the acknowledgment logic if gic_acknowledge_irq is +> called by multiple threads, too.) +> +> Option used: +> -nographic -machine virt,virtualization=on,accel=tcg,gic-version=2 -cpu cortex-a57 -smp 4 -m 1024 +> -kernel whatever.elf -d unimp,guest_errors -semihosting-config enable,target=native +> -chardev stdio,id=uart -serial chardev:uart -monitor none +> -trace gic_update_set_irq -trace gic_acknowledge_irq -trace pl011_irq_state -trace pl011_write -trace gic_cpu_read -trace gic_cpu_write +> -trace gic_set_irq +> +> Commit used: dc65a5bdc9fa543690a775b50d4ffbeb22c56d6d "Merge remote- +> tracking branch 'remotes/dgibson/tags/ppc-for-5.0-20200108' into +> staging" + + +-- +Alex Bennée + + +It would probably help if you were a bit more specific about describing the expected versus actual behaviour you see. I think here that we're talking about the GICD_ICFGR registers and more specifically the bits [2F] that may indicate N-N vs 1-N model. + +The GIC architecture specification says that these GICD_IFCGR bits are only relevant for "some early GIC implementations", which for QEMU means "only for the 11MPcore pre-GICv1 GIC". Our GICv2 implementation follows the architecture in having these bits be RAZ/WI (and we implement the behaviour of the 1-N-for-SPI vs N-N-for-SGI in code rather than by testing the 'model' flag, I think). + +For part (2), I think you're saying that we're missing the bit of functionality that in the arch spec section 3.2.3 is described as "when the GIC recognises an interrupt acknowledge from one of the target processors it clears the pending state on all the other targeted processors" ? Interestingly, this isn't documented in the section 3.2.4 set of conditions where the pending state is removed... + + + +> You might find there is enough in kvm-unit-tests GIC tests already to +build a test case for what you are seeing. + +Right, I will do so as soon as possible. + +For bug 1) however, a simpler test can be made +_start: + // x0=gicd + mov x0, #0x08000000 + // Read icfgr[for irqid=32...] + ldr w1, [x0, #(0xc00+32/4)] + // Try to write to icfgr + mov w1, #3 + str w1, [x0, #(0xc00+32/4)] + // Read back + ldr w1, [x0, #(0xc00+32/4)] + b . + +Running this code through the gdbstub, we can see that the model bits ((2*id+0) mod 16) in icfgr are always 0, no matter what. + +However, even for the GICv2, GIC_DIST_TEST_MODEL is being used in qemu source code, meaning all interrupts, including SPIs, are wrongly treated as N-N. + +The initialization function of the GIC should (at least for GICv2 devices) initialize these bits as 1 for all SPIs; this is currently not the case. + +Oops, yes, missed that use of GIC_DIST_TEST_MODEL because it was in the header file... + + +> about describing the expected versus actual behaviour you see. + +Expected behavior: + +* core 0 (or 1) reads irqId (irqId becomes active/active-pending) +* core 1 (or resp. 0) reads 1023 +* core 0 handles and deactivates the interrupt + +What I am getting instead: + +* core 0 reads irqId +* core 1 also reads irqId +* core 0 handles the interrupt, later deactivates it +* core 1 attempts to handle the interrupt + +In arm-gic.c, reads of GICC_IAR call gic_acknowledge_irq. gic_acknowledge_irq, in turn, calls gic_clear_pending (in gic_internal.h) which eventually evaluates GIC_DIST_TEST_MODEL, line 266 + +For 2): since I've never written to ispendr, the level interrupt is still considered as pending on the other core because GIC_DIST_TEST_LEVEL(...) evaluates to true. + +I believe ack should clear the level on other cores for 1-n interrupts + +> For part (2), I think you're saying that we're missing the bit of functionality that in the arch spec ... + +I do, apologies if what I wrote was confusing. + +"Implications of the 1-N model" provides clearer wording about that functionality + +Err, I meant 3.2 subitem 5 "Note" "In a multiprocessor implementation, the GIC handles(...)" too, sorry + +Please find attached a test case reproducing this issue. (this is a variant of https://github.com/rhdrjones/kvm-unit-tests/blob/master/arm/pl031.c but for multiple CPUs) + + +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/268 + + diff --git a/results/classifier/zero-shot/118/user-level-arm/1936977 b/results/classifier/zero-shot/118/user-level-arm/1936977 new file mode 100644 index 000000000..85356446b --- /dev/null +++ b/results/classifier/zero-shot/118/user-level-arm/1936977 @@ -0,0 +1,72 @@ +arm: 0.949 +user-level: 0.946 +device: 0.903 +graphic: 0.897 +debug: 0.764 +architecture: 0.752 +network: 0.670 +PID: 0.650 +semantic: 0.631 +register: 0.620 +mistranslation: 0.574 +files: 0.565 +ppc: 0.521 +socket: 0.520 +risc-v: 0.514 +TCG: 0.490 +boot: 0.476 +performance: 0.471 +permissions: 0.460 +vnc: 0.459 +peripherals: 0.388 +virtual: 0.382 +VMM: 0.346 +x86: 0.329 +kernel: 0.321 +hypervisor: 0.268 +assembly: 0.192 +i386: 0.130 +KVM: 0.050 +-------------------- +arm: 0.993 +debug: 0.310 +hypervisor: 0.213 +virtual: 0.105 +TCG: 0.087 +files: 0.059 +register: 0.017 +PID: 0.012 +performance: 0.012 +device: 0.011 +semantic: 0.010 +user-level: 0.009 +kernel: 0.008 +network: 0.007 +assembly: 0.003 +architecture: 0.002 +boot: 0.002 +socket: 0.002 +peripherals: 0.002 +graphic: 0.001 +ppc: 0.001 +permissions: 0.001 +risc-v: 0.001 +VMM: 0.001 +vnc: 0.001 +x86: 0.001 +mistranslation: 0.000 +i386: 0.000 +KVM: 0.000 + + qemu-arm-static crashes "segmentation fault" when running "git clone" + +This is a reopen of #1869073 for `qemu-user-static/focal-updates,focal-security,now 1:4.2-3ubuntu6.17 amd64`. + +`git clone` reproducably segfaults in `qemu-arm-static` chroot. + +#1869073 mentions this should have been fixed for newer versions of QEMU, but for `focal` there's no newer version available, even in `focal-backports`. + +This is the upstream QEMU bug tracker, not an Ubuntu specific tracker; if you'd like Ubuntu to consider a backport of something, please file a bug with them. + + + diff --git a/results/classifier/zero-shot/118/user-level-arm/385 b/results/classifier/zero-shot/118/user-level-arm/385 new file mode 100644 index 000000000..095652060 --- /dev/null +++ b/results/classifier/zero-shot/118/user-level-arm/385 @@ -0,0 +1,61 @@ +arm: 0.972 +user-level: 0.889 +device: 0.784 +graphic: 0.767 +debug: 0.630 +register: 0.550 +performance: 0.516 +PID: 0.281 +architecture: 0.225 +semantic: 0.217 +boot: 0.207 +risc-v: 0.185 +vnc: 0.178 +permissions: 0.156 +files: 0.150 +mistranslation: 0.122 +socket: 0.096 +ppc: 0.094 +i386: 0.048 +kernel: 0.035 +virtual: 0.031 +network: 0.018 +assembly: 0.013 +x86: 0.010 +TCG: 0.006 +VMM: 0.005 +peripherals: 0.005 +hypervisor: 0.003 +KVM: 0.000 +-------------------- +arm: 0.994 +user-level: 0.993 +performance: 0.533 +PID: 0.388 +debug: 0.278 +architecture: 0.130 +device: 0.069 +files: 0.063 +assembly: 0.063 +virtual: 0.021 +VMM: 0.021 +TCG: 0.015 +risc-v: 0.015 +register: 0.012 +semantic: 0.012 +graphic: 0.010 +KVM: 0.007 +socket: 0.005 +peripherals: 0.003 +boot: 0.003 +kernel: 0.003 +vnc: 0.001 +permissions: 0.001 +hypervisor: 0.001 +network: 0.001 +mistranslation: 0.001 +ppc: 0.000 +i386: 0.000 +x86: 0.000 + +ARM user regression since 87b74e8b6edd287ea2160caa0ebea725fa8f1ca1 |