Bug 623913 - [virtio] virtio-serial doesn't work after s3/s4 in kvm guest.
Summary: [virtio] virtio-serial doesn't work after s3/s4 in kvm guest.
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: kernel   
(Show other bugs)
Version: 6.1
Hardware: All
OS: Linux
Target Milestone: rc
: ---
Assignee: Amit Shah
QA Contact: Virtualization Bugs
Keywords: Reopened
: 621026 (view as bug list)
Depends On:
Blocks: Rhel6KvmTier1 580953 720669 748534
TreeView+ depends on / blocked
Reported: 2010-08-13 06:43 UTC by lihuang
Modified: 2013-01-09 23:00 UTC (History)
10 users (show)

Fixed In Version: kernel-2.6.32-231.el6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-06-20 07:35:07 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2012:0862 normal SHIPPED_LIVE Moderate: Red Hat Enterprise Linux 6 kernel security, bug fix and enhancement update 2012-06-20 12:55:00 UTC

Description lihuang 2010-08-13 06:43:46 UTC
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):
(only test i686 guest so far)

How reproducible:

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.

Comment 1 Amit Shah 2010-08-17 14:28:10 UTC
Can you try the kernel in


(It's still building, it'll take about an hour to get the x86-64 kernel built, and will be available at that link for about a week.)

Comment 3 Amit Shah 2010-08-19 10:09:09 UTC
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?

Comment 4 lihuang 2010-08-19 15:36:22 UTC
(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?

> Are you doing open/close in a loop while doing the suspend?

Comment 6 Dor Laor 2010-11-21 22:31:11 UTC
*** Bug 621026 has been marked as a duplicate of this bug. ***

Comment 7 Dor Laor 2011-04-11 14:10:54 UTC
*** Bug 694801 has been marked as a duplicate of this bug. ***

Comment 9 Amit Shah 2011-05-30 10:50:15 UTC

*** This bug has been marked as a duplicate of bug 609286 ***

Comment 10 Amit Shah 2011-12-09 10:29:07 UTC
Each virtio driver needs to be updated to handle PM, so re-opening this.

Comment 11 RHEL Product and 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 12 Aristeu Rozanski 2012-02-15 19:55:52 UTC
Patch(es) available on kernel-2.6.32-231.el6

Comment 15 Qunfang Zhang 2012-04-16 08:06:32 UTC
Verified on kernel-2.6.32-262.el6, and this bug does not exist.
Related packages:

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.

4. Resume guest by sending "system_wakeup" qemu command.

5. Repeat step 2. 

6. Suspend guest to disk.

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.

Comment 17 errata-xmlrpc 2012-06-20 07:35:07 UTC
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.


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