Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
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.
OK, so basically you can suspend and resume, but after resume you see the cpu stuck warning?
Also, you see the too many open files *after* resume from suspend, right?
Are you doing open/close in a loop while doing the suspend?
(In reply to comment #3)
> OK, so basically you can suspend and resume, but after resume you see the cpu
> stuck warning?
>
yes . suspend and resume is OK here.
before suspend. I have stopped listen the unix socket on host. (control-C)
after resume. it seems everything is right before writing to the virtio0p0 ( echo a >/dev/vport0p0) : I login guest via ssh. the session hung after send command "echo a >/dev/vport0p0". inside guest, top show "bash" consumed 100%cpu.
after a while, i got the stuck warning.
> Also, you see the too many open files *after* resume from suspend, right?
>
yes.
> Are you doing open/close in a loop while doing the suspend?
no
Each virtio driver needs to be updated to handle PM, so re-opening this.
Comment 11RHEL Program Management
2011-12-13 04:40:02 UTC
This request was evaluated by Red Hat Product Management for inclusion
in a Red Hat Enterprise Linux maintenance release. Product Management has
requested further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products. This request is not yet committed for inclusion in an Update release.
Comment 12Aristeu Rozanski
2012-02-15 19:55:52 UTC
Verified on kernel-2.6.32-262.el6, and this bug does not exist.
Related packages:
qemu-kvm-0.12.1.2-2.275.el6.x86_64
seabios-0.6.1.2-18.el6.x86_64
Steps:
1. Boot guest with virtio serial device:
# /usr/libexec/qemu-kvm -M rhel6.3.0 -cpu Conroe -enable-kvm -m 2G -smp 2,sockets=1,cores=2,threads=1 -name rhel6.3 -uuid 4c84db67-faf8-4498-9829-19a3d6431d9d -rtc base=localtime,driftfix=slew -drive file=/home/rhel6.3-64-new.qcow2,if=none,id=drive-virtio-disk0,format=qcow2,cache=none,werror=stop,rerror=stop,aio=native -device virtio-blk-pci,bus=pci.0,drive=drive-virtio-disk0,id=virtio-disk0,addr=0x5 -netdev tap,id=hostnet0,script=/etc/qemu-ifup -device virtio-net-pci,netdev=hostnet0,id=net0,mac=00:1a:2a:42:10:66,bus=pci.0,addr=0x3 -usb -device usb-tablet,id=input0 -boot c -monitor stdio -drive if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw -device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -vnc :10 -qmp tcp:0:4444,server,nowait -bios /usr/share/seabios/bios-pm.bin -chardev socket,path=/tmp/qzhang-test,server,nowait,id=isa1 -device isa-serial,chardev=isa1,id=isa-serial1 -device virtio-serial-pci,id=virtio-serial0,max_ports=31,vectors=4,bus=pci.0 -chardev socket,id=channel0,path=/tmp/virtio-serial,server,nowait -device virtserialport,chardev=channel0,name=org.linux-kvm.port.0,bus=virtio-serial0.0,id=port0 -device virtio-balloon-pci,bus=pci.0,id=balloon0
2. transfer some data through virtio serial after guest boots up:
Host: #nc -U /tmp/virtio-serial
Guest: # echo abc > /dev/vport0p1 (write)
# cat /dev/vport0p1 (read) (need to input some characters on host 'nc' connection)
3. Suspend guest to memory.
#pm-suspend
4. Resume guest by sending "system_wakeup" qemu command.
5. Repeat step 2.
6. Suspend guest to disk.
#pm-hibernate
7. Resume guest by booting it up with the same command line.
8. Repeat step 2.
9. Repeat step 2~8 for several times.
Result: Virtio-serial still works after guest s3/s4. So this issue is fixed.
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.
http://rhn.redhat.com/errata/RHSA-2012-0862.html
Description of problem: write to or read from /dev/vport0p1 after s3/s4 : BUG: soft lockup - CPU#0 stuck for 61s! [cat:1848] Modules linked in: virtio_console autofs4 sunrpc ipt_REJECT nf_conntrack_ipv4 nf_defrag_ipv4 iptable_filter ip_tables ip6t_REJECT nf_conntrack_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables ipv6 dm_mirror dm_region_hash dm_log virtio_balloon snd_intel8x0 snd_ac97_codec ac97_bus snd_seq snd_seq_device snd_pcm snd_timer snd soundcore snd_page_alloc e1000 i2c_piix4 i2c_core sg ext4 mbcache jbd2 sd_mod crc_t10dif virtio_pci virtio_ring virtio pata_acpi ata_generic ata_piix dm_mod [last unloaded: virtio_console] Pid: 1848, comm: cat Not tainted (2.6.32-59.1.el6.i686 #1) KVM EIP: 0060:[<f7eab230>] EFLAGS: 00000246 CPU: 0 EIP is at virtqueue_get_buf+0x0/0x130 [virtio_ring] EAX: f4a09140 EBX: f4a09140 ECX: 0001c950 EDX: f70a3e34 ESI: f70a3e34 EDI: f70a3e14 EBP: f32a6190 ESP: f70a3e08 DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 CR0: 8005003b CR2: 002e72c0 CR3: 32de1000 CR4: 000006f0 DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000 DR6: ffff0ff0 DR7: 00000400 Call Trace: [<f7e5734b>] ? __send_control_msg+0x9b/0xb0 [virtio_console] [<f7e57196>] ? reclaim_consumed_buffers+0x26/0x30 [virtio_console] [<f7e5740a>] ? port_fops_open+0xaa/0xd0 [virtio_console] [<c0520097>] ? chrdev_open+0xf7/0x1d0 [<c051a0ff>] ? __dentry_open+0xdf/0x2a0 [<c051a315>] ? nameidata_to_filp+0x55/0x70 [<c051ffa0>] ? chrdev_open+0x0/0x1d0 [<c052aa7b>] ? do_filp_open+0x50b/0xb10 [<c052107e>] ? cp_new_stat64+0xee/0x100 [<c0519e88>] ? do_sys_open+0x58/0x130 [<c04a9f4c>] ? audit_syscall_entry+0x21c/0x240 [<c0519fdc>] ? sys_open+0x2c/0x40 [<c04099fb>] ? sysenter_do_call+0x12/0x28 Version-Release number of selected component (if applicable): kernel-2.6.32-59.1.el6.i686 (only test i686 guest so far) How reproducible: 100% Steps to Reproduce: 1. start a kvm guest with virtio-serial configured . -device virtio-serial-pci,id=virtio-serial0,max_ports=16,vectors=4,bus=pci.0 -chardev socket,id=channel0,path=/var/lib/libvirt/qemu/rhel6.channel0,server,nowait -device virtserialport,chardev=channel0,name=org.linux-kvm.port.0,bus=virtio-serial0.0,id=port0 (use ide and e1000 to avoid trigger other problem) 2. (guest) write to /dev/vport0p1. e.g. hexdump -C -n 1024 /dev/sda >/dev/vport0p1 3. (host) read from socket. nc -U /var/lib/libvirt/qemu/rhel6.channel0 4. (guest) implement s3/s4 inside guest. 5. repeat step2 and step3 Actual results: ==> step3 PASS ==> step5 FAILED: data is not diplay on host. guest got the soft lockup Expected results: Additional info: reload virtio-console module after s3 can make step5 PASS.