RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1173038 - kernel panic if execute "echo 0 > /dev/watchdog" inside guest with potion "-watchdog-action shutdown"
Summary: kernel panic if execute "echo 0 > /dev/watchdog" inside guest with potion "-w...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: qemu-kvm-rhev
Version: 7.1
Hardware: x86_64
OS: Linux
high
high
Target Milestone: rc
: ---
Assignee: Radim Krčmář
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-12-11 10:46 UTC by Lin Chen
Modified: 2015-01-15 20:11 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-01-15 20:11:40 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Lin Chen 2014-12-11 10:46:55 UTC
Description of problem:
Boot guest with "-watchdog i6300esb -watchdog-action shutdown" CLI option, then execute "echo 0 > /dev/watchdog" inside guest. guest don't shutdown and kernel panic.
QE also tested it with:
1. 3.10.0-123.el7.x86_64 inside guest and qemu-kvm-rhev-2.1.2-16.el7.x86_64 inside host.
2. 3.10.0-123.el7.x86_64 inside guest and qemu-kvm-rhev-1.5.3-60.el7_0.11.x86_64 inside host.
in both scenario above,guest don't kernel panic but keep black screen and don't shutdown successfully.


Version-Release number of selected component (if applicable):
inside host:
  uname -r
  3.10.0-213.el7.x86_64
  rpm -qa|grep 
  qemu-kvm-rhev-2.1.2-16.el7.x86_64
inside guest:
  uname -r
  3.10.0-213.el7.x86_64

How reproducible:
100%

Steps to Reproduce:
1.Boot guest with "-watchdog i6300esb -watchdog-action shutdown" CLI option.
2.Execute "echo 0 > /dev/watchdog" inside guest.

Actual results:
Guest don't shutdown and kernel panic.

Expected results:
Guest shall shutdown gracefully

Additional info:

Comment 3 Radim Krčmář 2014-12-11 19:24:58 UTC
(Don't other scenarios end at black screen because you have -no-shutdown?)

Does it fail the same if you enter 'system_powerdown' in the qemu monitor?
(Normal shutdown from guest works?)

Can you share the qemu command line?  I can't reproduce with the one I tried ...
(It is a problem with virtio storage, so it would be great if you could minimize it around that.)

Thanks.

Comment 4 Lin Chen 2014-12-12 04:26:16 UTC
> (Don't other scenarios end at black screen because you have -no-shutdown?)
QE didn't test these scenarios with option -no-shutdown.

> Does it fail the same if you enter 'system_powerdown' in the qemu monitor?
> (Normal shutdown from guest works?)
According to bug980692 QE can't confirm whether 'system_powerdown' in the qemu monitor successfully. However, it is normal if guest run in runlevel3.
And shutdown inside guest normally.


> Can you share the qemu command line?  I can't reproduce with the one I tried
my full command line:
/usr/libexec/qemu-kvm -cpu SandyBridge,+kvm_pv_eoi -m 2048 -smp 2,sockets=1,cores=2,threads=1 -M pc -enable-kvm -name RHEL7 -drive file=/home/guest/RHEL7.1-64.qcow2,if=none,format=qcow2,werror=stop,rerror=stop,cache=none,id=drive-blk -device virtio-blk-pci,drive=drive-blk,id=virtio-disk0 -nodefaults -nodefconfig -monitor stdio  -netdev tap,id=hostnet0 -device virtio-net-pci,netdev=hostnet0,mac=be:ba:0a:82:5a:78,id=net0  -vga qxl -spice port=5901,disable-ticketing -qmp tcp:0:4440,server,nowait -watchdog i6300esb -watchdog-action shutdown -serial unix:/tmp/ttys0,server,nowait

> (It is a problem with virtio storage, so it would be great if you could
> minimize it around that.)
QE will minimize and provide it later. 


additionally, QE tested it again but can't reproduce it as well and get some info as following:
[  109.969052] i6300esb: Unexpected close, not stopping watchdog!
Dec 11 22:05:13 unused kernel: i6300esb: Unexpected close, not stopping watchdog!
Dec 11 22:05:43 unused systemd-logind: Power key pressed.
Dec 11 22:05:43 unused gnome-session: (gnome-settings-daemon:2833): power-plugin-WARNING **: failed to turn the panel off: Display is not DPMS capable
Dec 11 22:05:43 unused NetworkManager[760]: <info>  sleep requested (sleeping: no  enabled: yes)
Dec 11 22:05:43 unused NetworkManager[760]: <info>  sleeping...
Dec 11 22:05:43 unused NetworkManager[760]: <info>  (eth0): device state change: disconnected -> unmanaged (reason 'sleeping') [30 10 37]
Dec 11 22:05:43 unused NetworkManager[760]: <info>  (eth0): link disconnected
Dec 11 22:05:43 unused NetworkManager[760]: <info>  NetworkManager state is now ASLEEP
Dec 11 22:05:44 unused systemd: Starting Sleep.
Dec 11 22:05:44 unused systemd: Reached target Sleep.
Dec 11 22:05:44 unused systemd: Starting Suspend...
Dec 11 22:05:44 unused systemd-sleep: Suspending system...
Dec 11 22:05:44 unused kernel: PM: Syncing filesystems ... done.

Comment 5 Radim Krčmář 2015-01-15 20:11:40 UTC
Not reproducible by QE anymore, going to presume it is fixed.

If you manage to hit it again, please reopen and give me access to the setup.


Note You need to log in before you can comment on or make changes to this bug.