Bug 1743477
Summary: | Since bd94bc06479a "spapr: change default interrupt mode to 'dual'", QEMU resets the machine to select the appropriate interrupt controller. And -no-reboot prevents that. | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux Advanced Virtualization | Reporter: | Min Deng <mdeng> |
Component: | qemu-kvm | Assignee: | David Gibson <dgibson> |
Status: | CLOSED ERRATA | QA Contact: | Min Deng <mdeng> |
Severity: | medium | Docs Contact: | |
Priority: | high | ||
Version: | 8.1 | CC: | bugproxy, dgibson, fnovak, hannsj_uhl, juzhang, knoel, lvivier, mdeng, ngu, ptoscano, qzhang, virt-maint |
Target Milestone: | rc | Keywords: | Regression |
Target Release: | 8.1 | ||
Hardware: | ppc64le | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | qemu-kvm-4.1.0-8.module+el8.1.0+4199+446e40fc | Doc Type: | If docs needed, set a value |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2019-11-06 07:19:01 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | 910269, 1741619 | ||
Bug Blocks: | 1624641 |
Description
Min Deng
2019-08-20 05:23:31 UTC
It's not reproducible on build qemu-kvm-core-4.0.0-6.module+el8.1.0+3736+a2aefea3.ppc64le so it should be regression problem,and feel free to update if you have any concerns. Simpler reproducer: curl -O http://download-ipv4.eng.brq.redhat.com/rhel-8/rel-eng/RHEL-8/latest-RHEL-8.1.0/compose/BaseOS/ppc64le/os/ppc/ppc64/vmlinuz /usr/libexec/qemu-kvm -M accel=tcg --nodefaults -serial mon:stdio -kernel ~/vmlinuz -nographic -no-reboot qemu-system-ppc64: warning: TCG doesn't support requested feature, cap-cfpc=workaround qemu-system-ppc64: warning: TCG doesn't support requested feature, cap-sbbc=workaround qemu-system-ppc64: warning: TCG doesn't support requested feature, cap-ibs=workaround SLOF ********************************************************************** QEMU Starting Build Date = Jul 3 2019 12:26:14 FW Version = git-ba1ab360eebe6338 Press "s" to enter Open Firmware. Populating /vdevice methods Populating /vdevice/vty@71000000 Populating /vdevice/nvram@71000001 Populating /pci@800000020000000 No NVRAM common partition, re-initializing... Scanning USB Using default console: /vdevice/vty@71000000 Detected RAM kernel at 400000 (1a7b860 bytes) Welcome to Open Firmware Copyright (c) 2004, 2017 IBM Corporation All rights reserved. This program and the accompanying materials are made available under the terms of the BSD License available at http://www.opensource.org/licenses/bsd-license.php Booting from memory... OF stdout device is: /vdevice/vty@71000000 Preparing to boot Linux version 4.18.0-128.el8.ppc64le (mockbuild.eng.bos.redhat.com) (gcc version 8.3.1 20190507 (Red Hat 8.3.1-4) (GCC)) #1 SMP Fri Aug 2 14:52:33 UTC 2019 Detected machine type: 0000000000000101 command line: Max number of cores passed to firmware: 2048 (NR_CPUS = 2048) Calling ibm,client-architecture-support...[root@localhost ~]# David, do you know if upstream will be fixed soon to avoid to have a reset when ic-mode is dual? Thanks The fact it breaks libguestfs has greatly raised the priority with which I'm considering this. Unfortunately, figuring out how to fix it will be a bit tricky. I'm flaggint this for RHEL-AV-8.1, though. Ok, it turns out this is easier to fix than I anticipated. I'd still like to remove CAS reboots entirely, because they cause other problems, but there's an easier fix for this specific problem in the meantime. Seems s390 had a somewhat similar problem, and introduced a SHUTDOWN_CAUSE_SUBSYSTEM_RESET option that ignores -no-reboot which we can use for the CAS reboots as well. I've put this fix into my ppc-for-4.2 tree which I expect to send a PR for shortly. (In reply to David Gibson from comment #5) > Ok, it turns out this is easier to fix than I anticipated. I'd still like > to remove CAS reboots entirely, because they cause other problems, but > there's an easier fix for this specific problem in the meantime. > > Seems s390 had a somewhat similar problem, and introduced a > SHUTDOWN_CAUSE_SUBSYSTEM_RESET option that ignores -no-reboot which we can > use for the CAS reboots as well. > > I've put this fix into my ppc-for-4.2 tree which I expect to send a PR for > shortly. Cool, thanks! (In reply to David Gibson from comment #5) > Ok, it turns out this is easier to fix than I anticipated. I'd still like > to remove CAS reboots entirely, because they cause other problems, but > there's an easier fix for this specific problem in the meantime. > > Seems s390 had a somewhat similar problem, and introduced a > SHUTDOWN_CAUSE_SUBSYSTEM_RESET option that ignores -no-reboot which we can > use for the CAS reboots as well. Per David,QE also tried the problem on s390x host with the similar steps ,it seems that the problem can't be reproduced on the below build,thanks. Build information qemu-kvm-4.1.0-5.module+el8.1.0+4076+b5e41ebc.s390x supermin: rpm: detected RPM version 4.14 supermin: package handler: fedora/rpm supermin: acquiring lock on /home/libguestfs-1.40.2/tmp/.guestfs-0/lock supermin: if-newer: output does not need rebuilding libguestfs: finished building supermin appliance libguestfs: begin testing qemu features libguestfs: checking for previously cached test results of /usr/libexec/qemu-kvm, in /home/libguestfs-1.40.2/tmp/.guestfs-0 libguestfs: loading previously cached test results libguestfs: qemu version: 4.1 libguestfs: qemu mandatory locking: yes libguestfs: qemu KVM: enabled libguestfs: finished testing qemu features libguestfs: command: run: dmesg | grep -Eoh 'lpj=[[:digit:]]+' libguestfs: read_lpj_from_dmesg: external command exited with error status 1 libguestfs: read_lpj_from_files: no boot messages files are readable /usr/libexec/qemu-kvm \ -global virtio-blk-ccw.scsi=off \ -no-user-config \ -enable-fips \ -nodefaults \ -display none \ -machine accel=tcg \ -m 768 \ -no-reboot \ -rtc driftfix=slew \ -kernel /home/libguestfs-1.40.2/tmp/.guestfs-0/appliance.d/kernel \ -initrd /home/libguestfs-1.40.2/tmp/.guestfs-0/appliance.d/initrd \ -object rng-random,filename=/dev/urandom,id=rng0 \ -device virtio-rng-ccw,rng=rng0 \ -device virtio-scsi-ccw,id=scsi \ -drive file=/home/libguestfs-1.40.2/tmp/libguestfslpr3Dc/scratch1.img,cache=unsafe,format=raw,id=hd0,if=none \ -device scsi-hd,drive=hd0 \ -drive file=/home/libguestfs-1.40.2/tmp/.guestfs-0/appliance.d/root,snapshot=on,id=appliance,cache=unsafe,if=none,format=raw \ -device scsi-hd,drive=appliance \ -device virtio-serial-ccw \ -chardev stdio,id=charconsole0 \ -device sclpconsole,chardev=charconsole0 \ -chardev socket,path=/tmp/libguestfso4zkCh/guestfsd.sock,id=channel0 \ -device virtserialport,chardev=channel0,name=org.libguestfs.channel.0 \ -append "panic=1 console=ttysclp0 edd=off udevtimeout=6000 udev.event-timeout=6000 no_timer_check printk.time=1 cgroup_disable=memory usbcore.nousb cryptomgr.notests tsc=reliable 8250.nr_uarts=1 root=/dev/sdb selinux=0 guestfs_verbose=1 TERM=xterm-256color" qemu-kvm: warning: global mc146818rtc.lost_tick_policy has invalid class name ... umount-all: /proc/mounts: fsname=/dev/sda1 dir=/sysroot type=ext2 opts=rw,relatime,block_validity,barrier,user_xattr,acl freq=0 passno=0 commandrvf: stdout=n stderr=y flags=0x0 commandrvf: umount /sysroot commandrvf: stdout=n stderr=y flags=0x0 commandrvf: udevadm --debug settle -E /dev/sdb calling: settle commandrvf: stdout=n stderr=y flags=0x0 commandrvf: udevadm --debug settle -E /dev/sda calling: settle fsync /dev/sda guestfsd: => internal_autosync (0x11a) took 0.39 secs libguestfs: sending SIGTERM to process 20412 libguestfs: qemu maxrss 351128K libguestfs: closing guestfs handle 0x277b6d30 (state 0) libguestfs: command: run: rm libguestfs: command: run: \ -rf /home/libguestfs-1.40.2/tmp/libguestfslpr3Dc libguestfs: command: run: rm libguestfs: command: run: \ -rf /tmp/libguestfso4zkCh ===== TEST FINISHED OK ===== Upstream fix sent in pull request, just waiting for merge. Fix for this is now merged upstream, doing a brew build at: https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=23395494 Verified the bug on the following build qemu-kvm-4.1.0-8.module+el8.1.0+4199+446e40fc.ppc64le kernel-4.18.0-141.el8.ppc64le Steps please refer to comment0 actual results, test can finish. expected results, test can finish without errors The original issue has been fixed,thanks. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2019:3723 |