diff options
Diffstat (limited to '')
| -rw-r--r-- | results/classifier/108/permissions/1738 | 164 | ||||
| -rw-r--r-- | results/classifier/108/permissions/1738283 | 174 | ||||
| -rw-r--r-- | results/classifier/108/permissions/1738691 | 260 |
3 files changed, 598 insertions, 0 deletions
diff --git a/results/classifier/108/permissions/1738 b/results/classifier/108/permissions/1738 new file mode 100644 index 000000000..20267fcff --- /dev/null +++ b/results/classifier/108/permissions/1738 @@ -0,0 +1,164 @@ +permissions: 0.989 +other: 0.978 +files: 0.978 +graphic: 0.978 +device: 0.973 +debug: 0.968 +boot: 0.959 +semantic: 0.956 +performance: 0.955 +vnc: 0.932 +PID: 0.927 +socket: 0.914 +KVM: 0.912 +network: 0.895 + +qemu-system-x86_64 crash during kernel PCI init with large number of busses +Description of problem: +When booting a Linux kernel under qemu-system-x86_64 (tcg) using a large number of PCI busses (25+), qemu crashes with an invalid memory access during kernel PCI init phase. Failure rate is not 100%; some kernel boots do succeed, but the failure rate increases as the number of pci busses increases. Note that no initrd is needed; crash happens before kernel even gets to the point of trying to mount root. +Steps to reproduce: +Launch qemu using command line above along with 4.19.x kernel image (have not tested 5.x). It may take a few tries but within about 20 boot attempts, qemu will crash at least once. +Additional information: +Final kernel logs before crash: +``` +... +[ 1.413615] ACPI: Added _OSI(Module Device) +[ 1.413947] ACPI: Added _OSI(Processor Device) +[ 1.414262] ACPI: Added _OSI(3.0 _SCP Extensions) +[ 1.414421] ACPI: Added _OSI(Processor Aggregator Device) +[ 1.414922] ACPI: Added _OSI(Linux-Dell-Video) +[ 1.415445] ACPI: Added _OSI(Linux-Lenovo-NV-HDMI-Audio) +[ 1.444489] ACPI: 1 ACPI AML tables successfully acquired and loaded +[ 1.468218] ACPI: Interpreter enabled +[ 1.469897] ACPI: (supports S0 S3 S4 S5) +[ 1.470200] ACPI: Using IOAPIC for interrupt routing +[ 1.471811] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and repog +[ 1.474421] ACPI: Enabled 2 GPEs in block 00 to 3F +[ 1.536854] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff]) +[ 1.537996] acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI] +[ 1.540988] acpi PNP0A08:00: _OSC: platform does not support [LTR] +[ 1.542232] acpi PNP0A08:00: _OSC: OS now controls [PME AER PCIeCapability] +[ 1.546310] PCI host bridge to bus 0000:00 +[ 1.546650] pci_bus 0000:00: root bus resource [io 0x0000-0x0cf7 window] +[ 1.547471] pci_bus 0000:00: root bus resource [io 0x0d00-0xffff window] +[ 1.548039] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff window] +[ 1.548421] pci_bus 0000:00: root bus resource [mem 0x80000000-0xafffffff window] +[ 1.549086] pci_bus 0000:00: root bus resource [mem 0xc0000000-0xfebfffff window] +[ 1.549945] pci_bus 0000:00: root bus resource [mem 0x280000000-0xa7fffffff window] +[ 1.550994] pci_bus 0000:00: root bus resource [bus 00-ff] +<...crash...> +``` + +QEMU backtrace: +``` +$ gdb build/qemu-system-x86_64 core.3475232 +<...> +Reading symbols from build/qemu-system-x86_64... +[New LWP 3475243] +[New LWP 3475244] +[New LWP 3475241] +[New LWP 3475238] +[New LWP 3475245] +[New LWP 3475239] +[New LWP 3475246] +[New LWP 3475240] +[New LWP 3475232] +[New LWP 3475242] +[New LWP 3475236] +[New LWP 3475247] +[Thread debugging using libthread_db enabled] +Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". +Core was generated by `build/qemu-system-x86_64 -m 8192 -smp cpus=10,threads=2 -nographic -machine q35'. +Program terminated with signal SIGSEGV, Segmentation fault. +#0 0x0000556065897e0e in memory_region_dispatch_write (mr=mr@entry=0x0, addr=addr@entry=768, data=data@entry=253, + op=op@entry=MO_32, attrs=...) at ../softmmu/memory.c:1497 +1497 if (mr->alias) { +[Current thread is 1 (Thread 0x7fe2e951d640 (LWP 3475243))] +(gdb) bt full +#0 0x0000556065897e0e in memory_region_dispatch_write + (mr=mr@entry=0x0, addr=addr@entry=768, data=data@entry=253, op=op@entry=MO_32, attrs=...) at ../softmmu/memory.c:1497 + size = <optimized out> +#1 0x00005560659112c2 in io_writex + (env=env@entry=0x556066bbd5d0, full=0x7fe08401ec70, mmu_idx=mmu_idx@entry=2, val=val@entry=253, addr=addr@entry=18446744073699050240, retaddr=retaddr@entry=140611404753775, op=MO_32) at ../accel/tcg/cputlb.c:1430 + _iothread_lock_auto = 0x1 + cpu = 0x556066bbb1e0 + mr_offset = 768 + section = 0x7fe078d7d570 + mr = 0x0 + r = <optimized out> +#2 0x0000556065915f14 in store_helper + (op=MO_32, retaddr=140611404753775, oi=<optimized out>, val=<optimized out>, addr=18446744073699050240, env=0x556066bbd5d0) + at ../accel/tcg/cputlb.c:2454 + full = <optimized out> + need_swap = false + a_bits = <optimized out> + mmu_idx = 2 + tlb_addr = <optimized out> + haddr = <optimized out> + size = 4 + index = <optimized out> + entry = 0x7fe08401bc40 +#3 full_le_stl_mmu (env=0x556066bbd5d0, addr=18446744073699050240, val=253, oi=<optimized out>, retaddr=140611404753775) + at ../accel/tcg/cputlb.c:2542 +#4 0x00007fe2a4d4eb6f in code_gen_buffer () +#5 0x00005560659065bb in cpu_tb_exec + (cpu=cpu@entry=0x556066bbb1e0, itb=itb@entry=0x7fe2a4d4e9c0 <code_gen_buffer+13953427>, tb_exit=tb_exit@entry=0x7fe2e951c758) + at ../accel/tcg/cpu-exec.c:460 + env = 0x556066bbd5d0 + ret = <optimized out> + last_tb = <optimized out> + tb_ptr = 0x7fe2a4d4ea80 <code_gen_buffer+13953619> + __PRETTY_FUNCTION__ = "cpu_tb_exec" +#6 0x0000556065906ab6 in cpu_loop_exec_tb + (tb_exit=0x7fe2e951c758, last_tb=<synthetic pointer>, pc=<optimized out>, tb=0x7fe2a4d4e9c0 <code_gen_buffer+13953427>, cpu=0x556066bbb1e0) at ../accel/tcg/cpu-exec.c:893 + insns_left = <optimized out> + __PRETTY_FUNCTION__ = "cpu_loop_exec_tb" + tb = 0x7fe2a4d4e9c0 <code_gen_buffer+13953427> + flags = <optimized out> + cflags = 4280811520 + cs_base = <optimized out> + pc = <optimized out> + last_tb = <optimized out> + tb_exit = 0 +--Type <RET> for more, q to quit, c to continue without paging-- + ret = <optimized out> +#7 cpu_exec_loop (cpu=cpu@entry=0x556066bbb1e0, sc=sc@entry=0x7fe2e951c7f0) at ../accel/tcg/cpu-exec.c:1013 + tb = 0x7fe2a4d4e9c0 <code_gen_buffer+13953427> + flags = <optimized out> + cflags = 4280811520 + cs_base = <optimized out> + pc = <optimized out> + last_tb = <optimized out> + tb_exit = 0 + ret = <optimized out> +#8 0x0000556065907311 in cpu_exec_setjmp (cpu=cpu@entry=0x556066bbb1e0, sc=sc@entry=0x7fe2e951c7f0) at ../accel/tcg/cpu-exec.c:1043 + __func__ = "cpu_exec_setjmp" +#9 0x00005560659079f0 in cpu_exec (cpu=cpu@entry=0x556066bbb1e0) at ../accel/tcg/cpu-exec.c:1069 + ret = <optimized out> + sc = {diff_clk = 0, last_cpu_icount = 0, realtime_clock = 0} +#10 0x000055606592a854 in tcg_cpus_exec (cpu=cpu@entry=0x556066bbb1e0) at ../accel/tcg/tcg-accel-ops.c:81 + ret = <optimized out> + __PRETTY_FUNCTION__ = "tcg_cpus_exec" +#11 0x000055606592a9a7 in mttcg_cpu_thread_fn (arg=arg@entry=0x556066bbb1e0) at ../accel/tcg/tcg-accel-ops-mttcg.c:95 + r = <optimized out> + + force_rcu = {notifier = {notify = 0x55606592aac0 <mttcg_force_rcu>, node = {le_next = 0x0, le_prev = 0x7fe2e951d4a0}}, cpu = 0x556066bbb1e0} + cpu = 0x556066bbb1e0 + __PRETTY_FUNCTION__ = "mttcg_cpu_thread_fn" + __func__ = "mttcg_cpu_thread_fn" +#12 0x0000556065aa2e91 in qemu_thread_start (args=<optimized out>) at ../util/qemu-thread-posix.c:541 + + __cancel_buf = {__cancel_jmp_buf = {{__cancel_jmp_buf = {140612553791040, -3809744250012005023, 93872529245600, 25, 140612607756368, 140729970282144, -7051494707616903839, -3809738403745854111}, __mask_was_saved = 0}}, __pad = {0x7fe2e951c970, 0x0, 0x0, 0x0}} + __cancel_routine = 0x556065aa2ee0 <qemu_thread_atexit_notify> + __not_first_call = <optimized out> + start_routine = 0x55606592a8a0 <mttcg_cpu_thread_fn> + arg = 0x556066bbb1e0 + r = <optimized out> +#13 0x00007fe2ec894b43 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442 + ret = <optimized out> + pd = <optimized out> + + unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140729970281792, 7053160723592154465, 140612553791040, 25, 140612607756368, 140729970282144, -7051494707570766495, -7051505217351676575}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} + not_first_call = <optimized out> +#14 0x00007fe2ec926a00 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81 +``` diff --git a/results/classifier/108/permissions/1738283 b/results/classifier/108/permissions/1738283 new file mode 100644 index 000000000..d3895e3c1 --- /dev/null +++ b/results/classifier/108/permissions/1738283 @@ -0,0 +1,174 @@ +permissions: 0.926 +performance: 0.917 +vnc: 0.912 +graphic: 0.909 +network: 0.907 +device: 0.906 +semantic: 0.891 +other: 0.889 +boot: 0.885 +files: 0.884 +debug: 0.873 +socket: 0.864 +PID: 0.855 +KVM: 0.834 + +'Less than' (<), 'more than' (>), and 'pipe' (|) can't be typed via VNC + +If I start QEMU 2.11 (from https://build.opensuse.org/package/show/Virtualization/qemu) VM with VNC, I am unable to type following three characters: 'less than' (<), 'more than' (>), and 'pipe' (|) on en_US QWERTY keyboard. Other characters work fine. QEMu version 2.10.1 worked fine. + +/usr/bin/qemu-kvm -m 2048 -cpu kvm64 -drive media=cdrom,if=none,id=cd0,format=raw,file=OI-hipster-minimal-20171031.iso -device ide-cd,drive=cd0 -boot once=d,menu=on,splash-time=5000 -device usb-ehci -device usb-tablet -smp 1 -enable-kvm -vnc :91,share=force-shared + +The ISO can be downloaded here: https://www.openindiana.org/download/ + +Also tried Fedora-Server-dvd-x86_64-25-1.3.iso and it's the same situation. + +If I run the same command without '-vnc :91,share=force-shared', everything works just fine. + +Wondering if it's a SUSE-specific problem: https://build.opensuse.org/package/view_file/Virtualization/qemu/0026-Fix-tigervnc-long-press-issue.patch?expand=1 + +Should have mention I use openSUSE Leap 42.3 with above mentioned virtualization repo. + +Removed the 0026-Fix-tigervnc-long-press-issue patch and rebuilt QEMU but no change. + +But I noticed that if I run the ISO via libvirt and connect to it via virt-manager (virt-manager-1.4.1-4.1.noarch), the keys are there as expected: + +/usr/bin/qemu-system-x86_64 -machine accel=kvm -name guest=OI,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-2-OI/master-key.aes -machine pc-i440fx-2.11,accel=kvm,usb=off,vmport=off,dump-guest-core=off -cpu kvm64 -m 2048 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid 5664149e-26ad-4ee8-8170-16701f107b4b -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-2-OI/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime,driftfix=slew -global kvm-pit.lost_tick_policy=delay -no-hpet -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot strict=on -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x3.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x3 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x3.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x3.0x2 -drive file=/var/lib/libvirt/images/OI-hipster-minimal-20171031.iso,format=raw,if=none,id=drive-ide0-0-0,readonly=on -device ide-cd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 -vnc 127.0.0.1:0 -device VGA,id=video0,vgamem_mb=16,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4 -msg timestamp=on + +Connection via TigerVNC (tigervnc-1.6.0-21.1.x86_64) to the same VM is unable to write those characters. + +Well, if virt-manager is configured to run the VM with `-k en-us` I can't enter <>| even in virt-manager. keycodemapdb? + +By default virt-manager will *not* enable the '-k en-us' argument, because that forces use of a specific keyboard layout in QEMU's VNC server. For that to work, the VNC client keymap must exactly match the QEMU VNC server keymap, and must also exactly match the guest OS keymap. + +Instead virt-manager leaves off the "-k en-us" argument, which will cause the VNC servers raw scancode extension to be activated with compatible clients. Virt-manager uses GTK-VNC which activates this extension, and so passes raw XT scancodes from virt-manager to QEMU to the guest OS, which generally makes everything "just work" + +IOW, if virt-manager works correctly, but tigerVNC does not work correctly, this probably means that tigervnc is not activating the raw scancode extension. + +Hello, + +I confirm the same problem on Fedora 27 Server using Source code release 2.11.0 + +The problem remains no matter if I use the "-k en-us" parameter or not. + +Worked fine up to 2.10.1 + +If the guess is Windows, then when trying to type the "<" character then the pipe ("|") appears. + +If the guess is Linux, the same key produces the ">" character. + +Both operating systems use the US English keyboard layout. + +Thanks a lot for your time and help. + +Miguel + + + +If I start QEMU with `-k en-gb` at least '<' and '>' work, '|' doesn't (and obviously 'Shift-2' produces '"' not '@'). + +My host `locale` is 'en_US.UTF-8' top to bottom. + +I tried to update TigerVNC to 1.8 but no change. I run `vncviewer` with '-Log *:stderr:100' and QEMU without '-k' option and at least on the VNC client side it reports expected key code names. + +Aha. This looks like my bug! + +I'm running into this in what I suspect is the same situation as Michal Nowak: openQA. But in Fedora. openQA (well, its test runner, os-autoinst) works by running virtual machines and interacting with them over VNC. It seems that with qemu 2.11, typing certain characters doesn't work right, where it worked fine with 2.10. The case I ran into is the < case: when os-autoinst intends to type a < (which it does by sending the keysym for shift and then the keysym 60, for <), it winds up typing a > . This winds up causing os-autoinst's test suite to fail when attempting to build the package on Fedora Rawhide. The test suite passes on Fedora 27 (qemu 2.10). + +The qemu command in my test is: + +/usr/bin/qemu-system-i386 -serial file:serial0 -soundhw ac97 -vga cirrus -m 1024 -netdev user,id=qanet0 -device virtio-net,netdev=qanet0,mac=52:54:00:12:34:56 -device ide-drive,drive=hd1,serial=1 -drive file=raid/l1,cache=unsafe,if=none,id=hd1,format=qcow2 -drive media=cdrom,if=none,id=cd0,format=raw,file=/builddir/build/BUILD/os-autoinst-25191d50d54eaded10b6b26199bb986728dcd5c2/t/data//Core-7.2.iso -device ide-cd,drive=cd0 -boot once=d,menu=on,splash-time=5000 -smp 1 -no-shutdown -vnc :90,share=force-shared -qmp unix:qmp_socket,server,nowait -monitor unix:hmp_socket,server,nowait -S -monitor telnet:127.0.0.1:15222,server,nowait + +note there doesn't appear to be any explicit keyboard map setting there. + +Note, os-autoinst is its own VNC client. Most of the implementation can be found in https://github.com/os-autoinst/os-autoinst/blob/master/consoles/VNC.pm . The functions relevant to sending key events are `shift_keys`, `init_x11_keymap`, `map_and_send_key`, and `_send_key_event`. + +I also confirm Michal's observation of virt-manager and tigervnc behaving differently with the same VM: I ran a VM set up with VNC display server in virt-manager and can type < from the virt-manager UI fine, but if I connect to the same VM with tigervnc and try to type < , I get > . This is with current Fedora Rawhide qemu, virt-manager and tigervnc: + +qemu-common-2.11.0-1.fc28.x86_64 +virt-manager-1.4.3-2.fc28.noarch +tigervnc-1.8.0-5.fc28.x86_64 + +I found something interesting using showkey in the VM. This is all assuming en-US everywhere, note. On a US keyboard, "<" is a shifted comma (shift-,), ">" is a shifted period (shift-.), and "|" is a shifted backslash (shift-\). + +If I run showkey and try the affected characters in virt-manager, the results are kinda what I'd expect. It reports keycode 42 for the shift key, keycode 51 for comma key, keycode 52 for period key, and keycode 43 for backslash key. If I do shift-, (to get a <), it shows keycode 42 down, keycode 51 down, keycode 51 up, keycode 42 up - just what you'd expect. Ditto for > and |: it shows 42d/52d/52u/42u and 42d/43d/43u/42u in those cases. + +But if I do this while typing in tigervnc, it reports something quite different. Just pressing the keys alone gives the right codes - 51, 52, 43. But when I try the shifted combinations, it reports keycode *86* for all three keys. That is, so long as shift is held down, pressing the comma, period or backslash key reports keycode 86 - not 51, 52 or 43. Somehow this results in the generation of a > character, not sure how. + +I note this block in pc-bios/keymaps/en-us with interest: + +# evdev 86 (0x56), QKeyCode "less", number 0x56 +less 0x56 +greater 0x56 shift +bar 0x56 altgr +brokenbar 0x56 shift altgr + +That block was added in commit a7815faffb2bd594b92aa3542d7b799cc89c5414 , which I am very suspicious was the cause of this problem. I strongly suspect that removing it will fix the problem. Will test now. + +FWIW, I think this keycode represents the key between the left shift key and the first letter key on the fourth row, if there is one. European keyboards have one, and on e.g. a UK keyboard it types a \ unshifted and a | shifted - this is exactly how it looks in the en-gb keymap file: + +# evdev 86 (0x56), QKeyCode "less", number 0x56 +backslash 0x56 +bar 0x56 shift +bar 0x56 altgr +brokenbar 0x56 shift altgr + +The definition that somehow gets into the en-us keymap file appears to be actually how the key is intended to work on *German* keyboards: + +https://en.wikipedia.org/wiki/German_keyboard_layout + +Note how the key is labelled with <, > and | characters there. The French layout has the same key labelled with < and > but not |. So basically it seems like that same definition for this key shows up when you ask xkb for an en_US map. + +Bonus historical note: modern US keyboards don't have a key there at all, they're 101/104-key keyboards, where the left shift key is very wide and the key next to it is the first letter key. But *old* US keyboards, specifically the 83-key 'XT' layout, *DID* have a key there! + +https://en.wikipedia.org/wiki/IBM_PC_keyboard#/media/File:IBM_Model_F_XT.png + +From that picture, the key was labelled with \ and | characters, like a modern UK keyboard (presumably this is where the modern UK keyboard derived its use for the key from). I wonder if there's a keyboard nerd out there somewhere with a working US XT keyboard who we could ask to press that key and see what keycode it generates...:) I suppose if it's this keycode, we could arguably report a bug in xkb that for en_US, that keycode should work like a modern UK keyboard (backslash / bar / bar / brokenbar), not a modern German keyboard...:) + +Confirmed that dropping the offending keycode 86 definition out of keymaps/en-us fixes the problem. Scratch build for Fedora Rawhide was https://koji.fedoraproject.org/koji/taskinfo?taskID=23814932 , I'll probably send this out as an official build so I can get os-autoinst built without hacking up the tests, but as the files are generated by qemu-keymap just hand editing the file isn't really the 'right' solution for upstream; someone will need to tweak qemu-keymap, or else leave the keymap alone but somehow tweak the relevant bits in qemu/ui/keymaps.c and fix the problem that way. + +Note: I wondered if specifying a correct model for qemu-keymap to pass to xkb would help. But it doesn't :( That is, these: + +qemu-keymap -l us +qemu-keymap -l us -m pc101 +qemu-keymap -l us -m pc104 +qemu-keymap -l us -m pc105 + +all produce the same output except for the commented-out 'model' line at the top. It appears xkb doesn't really consider the model when deciding what keycodes to include in the generated keymap. + +I found Adam's patch from Fedora Rawhide (https://src.fedoraproject.org/rpms/qemu/c/f81be8f0261cce74799f946e99f23d57f8db7e17?branch=master) when applied to openSUSE's 2.11.0 QEMU effective in openQA as well as manually with vncviewer. + +We ran into this as well, using qemu 2.11.0. We're not using the "-k en-us" command line flag, and we're using noVNC as a client (which supports the QEMUExtendedKeyEvent encoding) + +FYI this seems to be fixed with qemu.git master, I didn't track down the specific commit but there were several keymap related changes. so qemu 2.12 will be fixed + +QEMU 2.12 has now been release, so marking this one as "Fix Released". + +Indeed the bug does not exist in this exact form any more, but it seems the stray '86' keymap entry *does* still cause problems in current qemu in one specific case: + +https://bugzilla.redhat.com/show_bug.cgi?id=1658676 + +basically, if using 'usb-kbd', we still get trouble when openQA (os-autoinst) tries to type a '<' character, because it does this: + +shift down +comma down +shift up +comma up + +(note it does *not* do shift down, comma down, comma up, shift up), and qemu gets confused and converts that into this sequence of input_event_key_qcode events: + +shift down +comma down +shift up +less up + +and that seems to mess with the key state and cause any subsequent attempts to type a '<' to go wrong. + +Removing the '86' key definition avoids the bug. + +Discussing the problem & likely solution here: + + https://lists.gnu.org/archive/html/qemu-devel/2018-12/msg04631.html + +I'm not subscribed there, so will note here: I tried the proposed changes - the commits from https://lists.gnu.org/archive/html/qemu-devel/2018-12/msg04819.html , backported to 3.0.0 - and that seems to work. A test which would previously have hit this bug ran OK, without the changes to the en-us keymap. + diff --git a/results/classifier/108/permissions/1738691 b/results/classifier/108/permissions/1738691 new file mode 100644 index 000000000..49622b09f --- /dev/null +++ b/results/classifier/108/permissions/1738691 @@ -0,0 +1,260 @@ +permissions: 0.948 +other: 0.942 +performance: 0.927 +debug: 0.922 +device: 0.920 +semantic: 0.910 +boot: 0.909 +KVM: 0.866 +socket: 0.863 +graphic: 0.862 +PID: 0.858 +files: 0.830 +network: 0.826 +vnc: 0.719 + +Guest kernel crashes with kvm_pr on POWER8 + +When attempting to use the kvm_pr module with QEMU 2.10 on a POWER8 host, Debian and Ubuntu guests hang and show crashes. + +Host kernel is 4.14. Issue is observed with host kernels 4.9 and 4.13 as well; no other host kernels were tested. + +Is this the correct place to report a kvm_pr bug? + +Output from Ubuntu 17.10 guest: + +Quiescing Open Firmware ... +Booting Linux via __start() @ 0x0000000002000000 ... +[ 0.000000] Page sizes from device-tree: +[ 0.000000] base_shift=12: shift=12, sllp=0x0000, avpnm=0x00000000, tlbiel=1, penc=0 +[ 0.000000] base_shift=16: shift=16, sllp=0x0110, avpnm=0x00000000, tlbiel=1, penc=1 +[ 0.000000] base_shift=24: shift=24, sllp=0x0100, avpnm=0x00000001, tlbiel=0, penc=0 +[ 0.000000] Using 1TB segments +[ 0.000000] Initializing hash mmu with SLB +[ 0.000000] Linux version 4.13.0-16-generic (buildd@bos01-ppc64el-029) (gcc version 7.2.0 (Ubuntu 7.2.0-8ubuntu2)) #19-Ubuntu SMP Wed Oct 11 18:37:02 UTC 2017 (Ubuntu 4.13.0-16.19-generic 4.13.4) +[ 0.000000] Found initrd at 0xc000000003b00000:0xc0000000048cf68b +[ 0.000000] Using pSeries machine description +[ 0.000000] bootconsole [udbg0] enabled +[ 0.000000] Partition configured for 2 cpus. +[ 0.000000] CPU maps initialized for 1 thread per core + -> smp_release_cpus() +spinning_secondaries = 1 + <- smp_release_cpus() +[ 0.000000] ----------------------------------------------------- +[ 0.000000] ppc64_pft_size = 0x19 +[ 0.000000] phys_mem_size = 0x100000000 +[ 0.000000] dcache_bsize = 0x80 +[ 0.000000] icache_bsize = 0x80 +[ 0.000000] cpu_features = 0x077c7a6c18500249 +[ 0.000000] possible = 0x5fffffff18500649 +[ 0.000000] always = 0x0000000018100040 +[ 0.000000] cpu_user_features = 0xdc0065c2 0xae000000 +[ 0.000000] mmu_features = 0x7c006001 +[ 0.000000] firmware_features = 0x00000000415a445f +[ 0.000000] htab_hash_mask = 0x3ffff +[ 0.000000] ----------------------------------------------------- +[ 0.000000] numa: NODE_DATA [mem 0xfffd7c80-0xfffe3fff] +[ 0.000000] PCI host bridge /pci@800000020000000 ranges: +[ 0.000000] IO 0x0000200000000000..0x000020000000ffff -> 0x0000000000000000 +[ 0.000000] MEM 0x0000200080000000..0x00002000ffffffff -> 0x0000000080000000 +[ 0.000000] MEM 0x0000210000000000..0x000021ffffffffff -> 0x0000210000000000 +[ 0.000000] PPC64 nvram contains 65536 bytes +[ 0.000000] Zone ranges: +[ 0.000000] DMA [mem 0x0000000000000000-0x00000000ffffffff] +[ 0.000000] DMA32 empty +[ 0.000000] Normal empty +[ 0.000000] Device empty +[ 0.000000] Movable zone start for each node +[ 0.000000] Early memory node ranges +[ 0.000000] node 0: [mem 0x0000000000000000-0x00000000ffffffff] +[ 0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x00000000ffffffff] +[ 0.000000] percpu: Embedded 4 pages/cpu @c0000000ffe00000 s162840 r0 d99304 u524288 +[ 0.000000] Built 1 zonelists in Node order, mobility grouping on. Total pages: 65472 +[ 0.000000] Policy zone: DMA +[ 0.000000] Kernel command line: BOOT_IMAGE=/install/vmlinux file=/cdrom/preseed/ubuntu-server.seed no_timer_check printk.time=1 --- +[ 0.000000] PID hash table entries: 4096 (order: -1, 32768 bytes) +[ 0.000000] Memory: 4070016K/4194304K available (12800K kernel code, 2048K rwdata, 3456K rodata, 4608K init, 3021K bss, 124288K reserved, 0K cma-reserved) +[ 0.000000] random: get_random_u64 called from cache_random_seq_create+0x80/0x180 with crng_init=0 +[ 0.000000] SLUB: HWalign=128, Order=0-3, MinObjects=0, CPUs=2, Nodes=1 +[ 0.000000] ftrace: allocating 33631 entries in 13 pages +[ 0.000000] Hierarchical RCU implementation. +[ 0.000000] RCU restricting CPUs from NR_CPUS=2048 to nr_cpu_ids=2. +[ 0.000000] Tasks RCU enabled. +[ 0.000000] RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=2 +[ 0.000000] NR_IRQS: 512, nr_irqs: 512, preallocated irqs: 16 +[ 0.000006] clocksource: timebase: mask: 0xffffffffffffffff max_cycles: 0x761537d007, max_idle_ns: 440795202126 ns +[ 0.000696] clocksource: timebase mult[1f40000] shift[24] registered +[ 0.001189] Console: colour dummy device 80x25 +[ 0.001500] console [hvc0] enabled +[ 0.001500] console [hvc0] enabled +[ 0.001751] bootconsole [udbg0] disabled +[ 0.001751] bootconsole [udbg0] disabled +[ 0.002142] pid_max: default: 32768 minimum: 301 +[ 0.002358] Security Framework initialized +[ 0.002377] Yama: becoming mindful. +[ 0.002466] AppArmor: AppArmor initialized +[ 0.007008] Dentry cache hash table entries: 524288 (order: 6, 4194304 bytes) +[ 0.009037] Inode-cache hash table entries: 262144 (order: 5, 2097152 bytes) +[ 0.009144] Mount-cache hash table entries: 8192 (order: 0, 65536 bytes) +[ 0.009282] Mountpoint-cache hash table entries: 8192 (order: 0, 65536 bytes) +[ 0.011066] EEH: pSeries platform initialized +[ 0.011137] POWER8 performance monitor hardware support registered +[ 0.011231] Hierarchical SRCU implementation. +[ 0.012560] smp: Bringing up secondary CPUs ... +[ 0.014620] smp: Brought up 1 node, 2 CPUs +[ 0.014669] numa: Node 0 CPUs: 0-1 +[ 0.017357] devtmpfs: initialized +[ 0.020796] evm: security.selinux +[ 0.020816] evm: security.SMACK64 +[ 0.020832] evm: security.SMACK64EXEC +[ 0.020849] evm: security.SMACK64TRANSMUTE +[ 0.020865] evm: security.SMACK64MMAP +[ 0.020882] evm: security.ima +[ 0.020898] evm: security.capability +[ 0.021384] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns +[ 0.021428] futex hash table entries: 512 (order: 0, 65536 bytes) +[ 0.022217] NET: Registered protocol family 16 +[ 0.023456] EEH: No capable adapters found +[ 0.068790] KVM: Live patching for a fast VM worked +[ 0.069504] cpuidle: using governor ladder +[ 0.069606] cpuidle: using governor menu +[ 0.070109] pstore: using zlib compression +[ 0.070162] pstore: Registered nvram as persistent store backend +Linux ppc64le +#19-Ubuntu SMP W[ 0.073385] PCI: Probing PCI hardware +[ 0.073595] PCI host bridge to bus 0000:00 +[ 0.073650] pci_bus 0000:00: root bus resource [io 0x10000-0x1ffff] (bus address [0x0000-0xffff]) +[ 0.073722] pci_bus 0000:00: root bus resource [mem 0x200080000000-0x2000ffffffff] (bus address [0x80000000-0xffffffff]) +[ 0.073827] pci_bus 0000:00: root bus resource [mem 0x210000000000-0x21ffffffffff] +[ 0.073913] pci_bus 0000:00: root bus resource [bus 00-ff] +[ 0.081145] IOMMU table initialized, virtual merging enabled +[ 0.081231] iommu: Adding device 0000:00:00.0 to group 0 +[ 0.083493] HugeTLB registered 16.0 MiB page size, pre-allocated 0 pages +[ 0.085216] SCSI subsystem initialized +[ 0.085722] vgaarb: loaded +[ 0.085885] usbcore: registered new interface driver usbfs +[ 0.085961] usbcore: registered new interface driver hub +[ 0.086096] usbcore: registered new device driver usb +[ 0.086175] pps_core: LinuxPPS API ver. 1 registered +[ 0.086217] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <email address hidden> +[ 0.086316] PTP clock support registered +[ 0.086629] EDAC MC: Ver: 3.0.0 +[ 0.087455] NetLabel: Initializing +[ 0.087509] NetLabel: domain hash size = 128 +[ 0.087550] NetLabel: protocols = UNLABELED CIPSOv4 CALIPSO +[ 0.087676] NetLabel: unlabeled traffic allowed by default +[ 0.088226] clocksource: Switched to clocksource timebase +[ 0.109127] VFS: Disk quotas dquot_6.6.0 +[ 0.109244] VFS: Dquot-cache hash table entries: 8192 (order 0, 65536 bytes) +[ 0.109543] AppArmor: AppArmor Filesystem Enabled +[ 0.121635] NET: Registered protocol family 2 +[ 0.122074] TCP established hash table entries: 32768 (order: 2, 262144 bytes) +[ 0.122584] TCP bind hash table entries: 32768 (order: 3, 524288 bytes) +[ 0.123346] TCP: Hash tables configured (established 32768 bind 32768) +[ 0.123472] UDP hash table entries: 2048 (order: 0, 65536 bytes) +[ 0.123692] UDP-Lite hash table entries: 2048 (order: 0, 65536 bytes) +[ 0.123937] NET: Registered protocol family 1 +[ 0.124257] Unpacking initramfs... +[ 0.467838] Freeing initrd memory: 14080K +[ 0.472109] audit: initializing netlink subsys (disabled) +[ 0.472949] audit: type=2000 audit(1513569522.428:1): state=initialized audit_enabled=0 res=1 +[ 0.473972] Initialise system trusted keyrings +[ 0.474068] Key type blacklist registered +[ 0.474308] workingset: timestamp_bits=38 max_order=16 bucket_order=0 +[ 0.476124] zbud: loaded +[ 0.477006] squashfs: version 4.0 (2009/01/31) Phillip Lougher +[ 0.477456] fuse init (API version 7.26) +[ 0.478394] random: fast init done +[ 0.483013] Key type asymmetric registered +[ 0.483040] Asymmetric key parser 'x509' registered +[ 0.483150] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 245) +[ 0.483363] io scheduler noop registered +[ 0.483383] io scheduler deadline registered +[ 0.483450] io scheduler cfq registered (default) +[ 0.484056] virtio-pci 0000:00:00.0: enabling device (0100 -> 0103) +[ 0.485519] virtio-pci 0000:00:00.0: ibm,query-pe-dma-windows(2026) 0 8000000 20000000 returned 0 +[ 0.485916] virtio-pci 0000:00:00.0: ibm,create-pe-dma-window(2027) 0 8000000 20000000 10 20 returned 0 (liobn = 0x80000001 starting addr = 8000000 0) +[ 0.501557] virtio-pci 0000:00:00.0: Using 64-bit direct DMA at offset 800000000000000 +[ 0.503803] Serial: 8250/16550 driver, 32 ports, IRQ sharing enabled +[ 0.507398] Linux agpgart interface v0.103 +[ 0.511296] loop: module loaded +[ 0.511671] libphy: Fixed MDIO Bus: probed +[ 0.511698] tun: Universal TUN/TAP device driver, 1.6 +[ 0.511860] PPP generic driver version 2.4.2 +[ 0.512086] VFIO - User Level meta-driver version: 0.3 +[ 0.512309] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver +[ 0.512367] ehci-pci: EHCI PCI platform driver +[ 0.512420] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver +[ 0.512457] ohci-pci: OHCI PCI platform driver +[ 0.512501] uhci_hcd: USB Universal Host Controller Interface driver +[ 0.512814] mousedev: PS/2 mouse device common for all mice +[ 0.513152] rtc-generic rtc-generic: rtc core: registered rtc-generic as rtc0 +[ 0.513200] i2c /dev entries driver +[ 0.513320] device-mapper: uevent: version 1.0.3 +[ 0.513482] device-mapper: ioctl: 4.36.0-ioctl (2017-06-09) initialised: <email address hidden> +[ 0.513710] ledtrig-cpu: registered to indicate activity on CPUs +[ 0.514095] NET: Registered protocol family 10 +[ 0.526547] modprobe[89]: unhandled signal 11 at 0000000000000008 nip 000073724fd9645c lr 000073724fd855c0 code 30001 +[ 0.528919] modprobe[90]: unhandled signal 11 at 00000000001e4250 nip 000076c0ae90e0f8 lr 000076c0ae90e6a4 code 30001 +[ 0.529819] Segment Routing with IPv6 +[ 0.529874] NET: Registered protocol family 17 +[ 0.529922] Key type dns_resolver registered +[ 0.530832] registered taskstats version 1 +[ 0.530902] Loading compiled-in X.509 certificates +[ 0.531719] modprobe[93]: unhandled signal 11 at 0000000000000008 nip 0000741ba74e645c lr 0000741ba74d55c0 code 30001 +[ 0.532899] modprobe[94]: unhandled signal 11 at 0000000000000008 nip 0000764dd97f645c lr 0000764dd97e55c0 code 30001 +[ 0.534414] Loaded X.509 cert 'Build time autogenerated kernel key: bc297e5938e0456833a4c0c157e5483b77785cf1' +[ 0.534505] zswap: loaded using pool lzo/zbud +[ 0.535375] modprobe[97]: unhandled signal 11 at 0000000000000008 nip 00007e85a34b645c lr 00007e85a34a55c0 code 30001 +[ 0.536618] modprobe[98]: unhandled signal 11 at 0000000000000008 nip 0000713d7724645c lr 0000713d772355c0 code 30001 +[ 0.537392] Key type big_key registered +[ 0.537418] Key type trusted registered +[ 0.545589] Key type encrypted registered +[ 0.545642] AppArmor: AppArmor sha1 policy hashing enabled +[ 0.545689] ima: No TPM chip found, activating TPM-bypass! (rc=-19) +[ 0.545799] evm: HMAC attrs: 0x1 +[ 0.551224] rtc-generic rtc-generic: setting system clock to 2017-12-18 03:58:43 UTC (1513569523) +[ 0.552107] Unable to open file: /etc/keys/x509_ima.der (-2) +[ 0.552109] Unable to open file: /etc/keys/x509_evm.der (-2) +[ 0.591193] Freeing unused kernel memory: 4608K +[ 0.591643] This architecture does not have kernel memory protection. +<hang> + +Is this the correct place to file kvm-pr bug reports? + +No, this bug tracker is for QEMU bugs only. Please report KVM-PR bugs to the <email address hidden> mailing list (see also https://www.linux-kvm.org/page/Bugs for how to report KVM kernel bugs in general) + +Hi, Timothy. + +I tried to reproduce this issue on a POWER8 box and couldn't reproduce it. + +Whatever the issue was, it seems to be fixed on kernel v4.16-rc4 with qemu 2.11.50. + +I downloaded vmlinux/initrd.gz from Ubuntu 18.04 to boot guest. It booted fine up to the installer initial screen. + +Please find my environment information listed below. + +I'm closing this bug but feel free to reopen it or file a new one. + +Cheers +Murilo + + +Machine type/model: 8247-22L + +[muriloo@baratheon ~]$ uname -a +Linux localhost.localdomain 4.16.0-rc4+ #1 SMP Thu Mar 8 22:54:31 UTC 2018 ppc64le ppc64le ppc64le GNU/Linux + +[muriloo@baratheon ~]$ lsmod | grep kvm +kvm_pr 100276 0 +kvm 217753 1 kvm_pr + +[muriloo@baratheon ~]$ ~/qemu/build/ppc64-softmmu/qemu-system-ppc64 --version +QEMU emulator version 2.11.50 (v2.11.0-2108-g83d2e94) +Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers + +[muriloo@baratheon ~]$ ~/qemu/build/ppc64-softmmu/qemu-system-ppc64 -kernel ~/ubuntu/18.04/vmlinux -initrd ~/ubuntu/18.04/initrd.gz -append "console=hvc0 verbose" -nodefaults -nographic -serial mon:stdio -accel kvm + +vmlinux: http://ports.ubuntu.com/ubuntu-ports/dists/bionic/main/installer-ppc64el/current/images/netboot/ubuntu-installer/ppc64el/vmlinux +initrd.gz: http://ports.ubuntu.com/ubuntu-ports/dists/bionic/main/installer-ppc64el/current/images/netboot/ubuntu-installer/ppc64el/initrd.gz + |