Bug 1394469

Summary: seabios-bin version seabios-bin-1.9.1-5.el7.noarch breaks rebooting from within a RHEL 7.x guest
Product: Red Hat Enterprise Linux 7 Reporter: Salvatore Bognanni <sbognann>
Component: seabiosAssignee: Gerd Hoffmann <kraxel>
Status: CLOSED DUPLICATE QA Contact: aihua liang <aliang>
Severity: high Docs Contact:
Priority: unspecified    
Version: 7.3CC: aliang, areis, chayang, coli, dyuan, gkable, jinqi, jkirby, juzhang, knoel, kraxel, michen, sbognann, virt-maint, xuzhang, yafu, zpeng
Target Milestone: rcKeywords: Regression
Target Release: ---   
Hardware: Unspecified   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-11-29 11:05:09 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:

Description Salvatore Bognanni 2016-11-12 11:41:07 UTC 
Description of problem:running 'reboot' or shutdown -r from within a RHEL 7.x guest running on a host which has the seabios-bin-1.9.1-5.el7.noarch installed, hangs the vm


Version-Release number of selected component (if applicable):
RHEL7.3 on host, seabios-bin-1.9.1-5.el7.noarch on host, RHEL 7.x on guest

How reproducible:


Steps to Reproduce:
1.install virtual machine
2.ssh into virtual machine
3.run reboot

Actual results:
machine hangs 

Expected results:
machine reboots


Additional info:
Comment 3 aihua liang 2016-11-14 10:24:34 UTC 
Can't reproduce this bug.

Test Version:
Host Kernel version: 3.10.0-521.el7.x86_64
Guest Kernel version：3.10.0-521.el7.x86_64
qemu-kvm-rhev version: 2.6.0-27.el7.x86_64
seabios version:1.9.1-5.el7.noarch.

Test cmds:
/usr/libexec/qemu-kvm -name rhel7.3-1 \
-machine pc-i440fx-rhel7.2.0,accel=kvm,usb=off,vmport=off \
-cpu SandyBridge \
-m 4096 \
-realtime mlock=off \
-smp 8,sockets=8,cores=1,threads=1 \
-uuid 1534fa42-4818-4493-9f67-eee5ba758385 \
-no-user-config -nodefaults \
-chardev socket,id=qmp_id_catch_monitor,path=/var/tmp/test1,server,nowait \
-mon chardev=qmp_id_catch_monitor,id=monitor,mode=control \
-rtc base=utc,driftfix=slew \
-global kvm-pit.lost_tick_policy=discard -no-hpet \
-global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 \
-boot menu=on,splash-time=1200 \
-device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x6.0x7 \
-device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x6 \
-device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x6.0x1 \
-device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x6.0x2 \
-device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x5 \
-device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x7 \
-drive file=/home/73test/img/se_test.qcow2,if=none,id=drive-scsi0-0-0-0,format=qcow2,cache=none,aio=native,snapshot=off \
-device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0 \
-drive file=/home/kvm_autotest_root/iso/linux/RHEL7.3-Server-x86_64.iso,if=none,id=drive-ide0-0-0,readonly=on,format=raw \
-device ide-cd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 \
-netdev tap,id=hostnet0 \
-device virtio-net-pci,netdev=hostnet0,id=net0,mac=50:54:00:49:b2:5f,bus=pci.0,addr=0x3 \
-chardev pty,id=charserial0 \
-device isa-serial,chardev=charserial0,id=serial0 \
-chardev spicevmc,id=charchannel1,name=vdagent \
-device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel1,id=channel1,name=com.redhat.spice.0 \
-device usb-tablet,id=input0 \
-vnc 0:2 \
-device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vgamem_mb=16,bus=pci.0,addr=0x2 \
-chardev spicevmc,id=charredir0,name=usbredir \
-device usb-redir,chardev=charredir0,id=redir0 \
-chardev spicevmc,id=charredir1,name=usbredir \
-device usb-redir,chardev=charredir1,id=redir1 \
-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x8 \
-msg timestamp=on \
-monitor stdio \
Comment 4 Salvatore Bognanni 2016-11-14 11:29:07 UTC 
Hi Liang,

The issue happened on hosts running kernel 3.10.0-327.4.5.el7.x86_64 , they were updated to 7.3 but kernel version is locked down. It's Lenovo 541 Laptos
Comment 5 Karen Noel 2016-11-14 12:23:28 UTC 
Salvatore, 

Please list the relevant host package versions and the guest kernel version as Liang did in comment 3. I'm confused. It seems like you're saying that the host is running RHEL 7.3, except the kernel is from 7.2 "locked down"? That's not supported. Maybe I misunderstood. Thanks.
Comment 6 Salvatore Bognanni 2016-11-14 13:11:11 UTC 
(In reply to Karen Noel from comment #5)
> Salvatore, 
> 
> Please list the relevant host package versions and the guest kernel version
> as Liang did in comment 3. I'm confused. It seems like you're saying that
> the host is running RHEL 7.3, except the kernel is from 7.2 "locked down"?
> That's not supported. Maybe I misunderstood. Thanks.

Sorry, Karen, these are just regular RHEL boxes which were updated to 7.3 recently , from our satellite,  they can't be easily upgraded to the newest kernel (because we have a locked down bootloader) so they are still running 3.10.0-327.4.5.el7.x86_64 , however we also tried to use a newer kernel , namely version kernel-3.10.0-520.el7.x86_64.rpm and the issue was still there. I tried downgrading kvm and libvirt and the issue was not fixed. The only thing that fixed the issue was the downgrade of seabios.
Comment 7 Karen Noel 2016-11-14 16:07:10 UTC 
(In reply to Salvatore Bognanni from comment #6)
> (In reply to Karen Noel from comment #5)
> > Salvatore, 
> > 
> > Please list the relevant host package versions and the guest kernel version
> > as Liang did in comment 3. I'm confused. It seems like you're saying that
> > the host is running RHEL 7.3, except the kernel is from 7.2 "locked down"?
> > That's not supported. Maybe I misunderstood. Thanks.
> 
> Sorry, Karen, these are just regular RHEL boxes which were updated to 7.3
> recently , from our satellite,  they can't be easily upgraded to the newest
> kernel (because we have a locked down bootloader) 

You shouldn't upgrade to 7.3 if your kernel version is locked down. Is this by design or can it be "fixed"?

> so they are still running
> 3.10.0-327.4.5.el7.x86_64 , however we also tried to use a newer kernel ,
> namely version kernel-3.10.0-520.el7.x86_64.rpm and the issue was still
> there. I tried downgrading kvm and libvirt and the issue was not fixed. The
> only thing that fixed the issue was the downgrade of seabios.

Okay, thanks. We'll look into it.

Please provide the qemu command line. For some reason Liang could not reproduce. It must be something specific about the VM configuration.

Liang, I'm guessing they are using qemu-kvm-1.5.3, since it's a laptop. 
Can you try that? Thanks.
Comment 8 aihua liang 2016-11-15 12:34:09 UTC 
The bug still can't be reproduced with following test:

Test Version:
Host Kernel version: 3.10.0-327.2.1.el7.x86_64/3.10.0-327.4.5.el7.x86_64
Guest Kernel version：3.10.0-521.el7.x86_64/3.10.0-327.4.5.el7.x86_64
qemu-kvm version:1.5.3-126.el7.x86_64
seabios version:1.9.1-5.el7

Test cmds:
/usr/libexec/qemu-kvm -name rhel7.3-1 \
-machine pc,accel=kvm,usb=off \
-cpu SandyBridge \
-m 4096 \
-realtime mlock=off \
-smp 8,sockets=8,cores=1,threads=1 \
-uuid 1534fa42-4818-4493-9f67-eee5ba758385 \
-no-user-config -nodefaults \
-chardev socket,id=qmp_id_catch_monitor,path=/var/tmp/test1,server,nowait \
-mon chardev=qmp_id_catch_monitor,id=monitor,mode=control \
-rtc base=utc,driftfix=slew \
-global kvm-pit.lost_tick_policy=discard -no-hpet \
-global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 \
-boot menu=on,splash-time=1200 \
-device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x6.0x7 \
-device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x6 \
-device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x6.0x1 \
-device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x6.0x2 \
-device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x5 \
-device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x7 \
-drive file=/home/se_test.qcow2,if=none,id=drive-scsi0-0-0-0,format=qcow2,cache=none,aio=native,snapshot=off \
-device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0 \
-netdev tap,id=hostnet0 \
-device virtio-net-pci,netdev=hostnet0,id=net0,mac=50:54:00:49:b2:5f,bus=pci.0,addr=0x3 \
-chardev pty,id=charserial0 \
-device isa-serial,chardev=charserial0,id=serial0 \
-chardev spicevmc,id=charchannel1,name=vdagent \
-device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel1,id=channel1,name=com.redhat.spice.0 \
-device usb-tablet,id=input0 \
-vnc 0:2 \
-device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vgamem_mb=16,bus=pci.0,addr=0x2 \
-chardev spicevmc,id=charredir0,name=usbredir \
-device usb-redir,chardev=charredir0,id=redir0 \
-chardev spicevmc,id=charredir1,name=usbredir \
-device usb-redir,chardev=charredir1,id=redir1 \
-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x8 \
-msg timestamp=on \
-monitor stdio \

CPU info：
processor	: 31
vendor_id	: GenuineIntel
cpu family	: 6
model		: 63
model name	: Intel(R) Xeon(R) CPU E5-2630 v3 @ 2.40GHz
stepping	: 2
microcode	: 0x36
cpu MHz		: 2472.937
cache size	: 20480 KB
physical id	: 1
siblings	: 16
core id		: 7
cpu cores	: 8
apicid		: 31
initial apicid	: 31
fpu		: yes
fpu_exception	: yes
cpuid level	: 15
wp		: yes


Hi,Salvatore
 Is there difference with our host configuration or our qemu cmdline?
Comment 9 Salvatore Bognanni 2016-11-15 13:08:04 UTC 
(In reply to aihua liang from comment #8)
> The bug still can't be reproduced with following test:
> 
> Test Version:
> Host Kernel version: 3.10.0-327.2.1.el7.x86_64/3.10.0-327.4.5.el7.x86_64
> Guest Kernel version：3.10.0-521.el7.x86_64/3.10.0-327.4.5.el7.x86_64
> qemu-kvm version:1.5.3-126.el7.x86_64
> seabios version:1.9.1-5.el7
> 
> Test cmds:
> /usr/libexec/qemu-kvm -name rhel7.3-1 \
> -machine pc,accel=kvm,usb=off \
> -cpu SandyBridge \
> -m 4096 \
> -realtime mlock=off \
> -smp 8,sockets=8,cores=1,threads=1 \
> -uuid 1534fa42-4818-4493-9f67-eee5ba758385 \
> -no-user-config -nodefaults \
> -chardev socket,id=qmp_id_catch_monitor,path=/var/tmp/test1,server,nowait \
> -mon chardev=qmp_id_catch_monitor,id=monitor,mode=control \
> -rtc base=utc,driftfix=slew \
> -global kvm-pit.lost_tick_policy=discard -no-hpet \
> -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 \
> -boot menu=on,splash-time=1200 \
> -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x6.0x7 \
> -device
> ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,
> addr=0x6 \
> -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x6.0x1 \
> -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x6.0x2 \
> -device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x5 \
> -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x7 \
> -drive
> file=/home/se_test.qcow2,if=none,id=drive-scsi0-0-0-0,format=qcow2,
> cache=none,aio=native,snapshot=off \
> -device
> scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,
> id=scsi0-0-0-0 \
> -netdev tap,id=hostnet0 \
> -device
> virtio-net-pci,netdev=hostnet0,id=net0,mac=50:54:00:49:b2:5f,bus=pci.0,
> addr=0x3 \
> -chardev pty,id=charserial0 \
> -device isa-serial,chardev=charserial0,id=serial0 \
> -chardev spicevmc,id=charchannel1,name=vdagent \
> -device
> virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel1,id=channel1,
> name=com.redhat.spice.0 \
> -device usb-tablet,id=input0 \
> -vnc 0:2 \
> -device
> qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vgamem_mb=16,bus=pci.
> 0,addr=0x2 \
> -chardev spicevmc,id=charredir0,name=usbredir \
> -device usb-redir,chardev=charredir0,id=redir0 \
> -chardev spicevmc,id=charredir1,name=usbredir \
> -device usb-redir,chardev=charredir1,id=redir1 \
> -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x8 \
> -msg timestamp=on \
> -monitor stdio \
> 
> CPU info：
> processor	: 31
> vendor_id	: GenuineIntel
> cpu family	: 6
> model		: 63
> model name	: Intel(R) Xeon(R) CPU E5-2630 v3 @ 2.40GHz
> stepping	: 2
> microcode	: 0x36
> cpu MHz		: 2472.937
> cache size	: 20480 KB
> physical id	: 1
> siblings	: 16
> core id		: 7
> cpu cores	: 8
> apicid		: 31
> initial apicid	: 31
> fpu		: yes
> fpu_exception	: yes
> cpuid level	: 15
> wp		: yes
> 
> 
> Hi,Salvatore
>  Is there difference with our host configuration or our qemu cmdline?

Hi Liang,

Here is our specs:

kernel on host : 3.10.0-327.4.5.el7.x86_64
kernel on guest : 3.10.0-327.el7.x86_64
qemu-kvm-1.5.3-126.el7.x86_64
seabios-bin-1.9.1-5.el7

we first create a definition xmlfile
then we run

virsh define xmlfile
virsh autostart vmname 
virsh start vmname

Here is an example of such definition xml

<domain type='kvm' id='49'>
  <name>cracker</name>
  <uuid>b2896bb6-48d8-481d-8ea9-5f227adaf9c2</uuid>
  <memory unit='KiB'>1048576</memory>
  <currentMemory unit='KiB'>1048576</currentMemory>
  <vcpu placement='static'>1</vcpu>
  <resource>
    <partition>/machine</partition>
  </resource>
  <os>
    <type arch='x86_64' machine='rhel6.5.0'>hvm</type>
    <boot dev='hd'/>
  </os>
  <features>
    <acpi/>
    <apic/>
    <pae/>
  </features>
  <cpu mode='host-model'>
    <model fallback='allow'/>
    <feature policy='force' name='vmx'/>
  </cpu>
  <clock offset='utc'/>
  <on_poweroff>destroy</on_poweroff>
  <on_reboot>restart</on_reboot>
  <on_crash>restart</on_crash>
  <devices>
    <emulator>/usr/libexec/qemu-kvm</emulator>
    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2' cache='none' io='threads'/>
      <source file='/var/lib/libvirt/images/cracker'/>
      <backingStore type='file' index='1'>
        <format type='qcow2'/>
        <source file='/var/lib/libvirt/images/rhel-7.2-x86_64-97e781a035adae28fbdebc0c81e39b63'/>
        <backingStore/>
      </backingStore>
      <target dev='vda' bus='virtio'/>
      <alias name='virtio-disk0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    </disk>
    <controller type='usb' index='0'>
      <alias name='usb'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/>
    </controller>
    <controller type='pci' index='0' model='pci-root'>
      <alias name='pci.0'/>
    </controller>
    <interface type='network'>
      <mac address='52:54:00:01:01:01'/>
      <source network='kprivate' bridge='virbr1'/>
      <target dev='vnet3'/>
      <model type='virtio'/>
      <alias name='net0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
    </interface>
    <serial type='pty'>
      <source path='/dev/pts/5'/>
      <target port='0'/>
      <alias name='serial0'/>
    </serial>
    <console type='pty' tty='/dev/pts/5'>
      <source path='/dev/pts/5'/>
      <target type='serial' port='0'/>
      <alias name='serial0'/>
    </console>
    <input type='tablet' bus='usb'>
      <alias name='input0'/>
      <address type='usb' bus='0' port='1'/>
    </input>
    <input type='mouse' bus='ps2'>
      <alias name='input1'/>
    </input>
    <input type='keyboard' bus='ps2'>
      <alias name='input2'/>
    </input>
    <graphics type='vnc' port='5902' autoport='yes' listen='0.0.0.0' keymap='en-us'>
      <listen type='address' address='0.0.0.0'/>
    </graphics>
    <video>
      <model type='vga' vram='4096' heads='1' primary='yes'/>
      <alias name='video0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
    </video>
    <memballoon model='virtio'>
      <alias name='balloon0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
    </memballoon>
  </devices>
  <seclabel type='dynamic' model='selinux' relabel='yes'>
    <label>system_u:system_r:svirt_t:s0:c452,c899</label>
    <imagelabel>system_u:object_r:svirt_image_t:s0:c452,c899</imagelabel>
  </seclabel>
  <seclabel type='dynamic' model='dac' relabel='yes'>
    <label>+107:+107</label>
    <imagelabel>+107:+107</imagelabel>
  </seclabel>
</domain>
Comment 10 Ademar Reis 2016-11-15 14:17:34 UTC 
*** Bug 1394403 has been marked as a duplicate of this bug. ***
Comment 11 Gerd Hoffmann 2016-11-16 07:57:42 UTC 
please test: http://people.redhat.com/ghoffman/bz1392569/
Comment 12 yafu 2016-11-16 08:53:14 UTC 
I can reproduce the issue randomly(about 25%) with:
host kernel: 3.10.0-506.el7.x86_64
guest kernel: 3.10.0-510.el7.x86_64
qemu-kvm-1.5.3-126.el7.x86_64/qemu-kvm-rhev-2.6.0-27.el7.x86_64
seabios-bin-1.9.1-5.el7.noarch
guest machine type: rhel6.6.0/rhel6.5.0

And the issue can not be reproduced with machine type pc-i440fx-rhel7.3.0.

The stack trace of the hung qemu-kvm process is as follows:
# gstack 3048
Thread 7 (Thread 0x7f49fe460700 (LWP 3057)):
#0  syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
#1  0x00007f4a21931d86 in futex_wait (val=<optimized out>, ev=<optimized out>) at util/qemu-thread-posix.c:292
#2  qemu_event_wait (ev=ev@entry=0x7f4a22338f24 <rcu_call_ready_event>) at util/qemu-thread-posix.c:399
#3  0x00007f4a2194038e in call_rcu_thread (opaque=<optimized out>) at util/rcu.c:250
#4  0x00007f4a08c1ddc5 in start_thread (arg=0x7f49fe460700) at pthread_create.c:308
#5  0x00007f4a0894c73d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113
Thread 6 (Thread 0x7f49fc059700 (LWP 3061)):
#0  0x00007f4a08943507 in ioctl () at ../sysdeps/unix/syscall-template.S:81
#1  0x00007f4a216acb55 in kvm_vcpu_ioctl (cpu=cpu@entry=0x7f4a24c44000, type=type@entry=44672) at /usr/src/debug/qemu-2.6.0/kvm-all.c:2080
#2  0x00007f4a216acc0d in kvm_cpu_exec (cpu=cpu@entry=0x7f4a24c44000) at /usr/src/debug/qemu-2.6.0/kvm-all.c:1930
#3  0x00007f4a2169b756 in qemu_kvm_cpu_thread_fn (arg=<optimized out>) at /usr/src/debug/qemu-2.6.0/cpus.c:1076
#4  0x00007f4a08c1ddc5 in start_thread (arg=0x7f49fc059700) at pthread_create.c:308
#5  0x00007f4a0894c73d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113
Thread 5 (Thread 0x7f49fb858700 (LWP 3062)):
#0  0x00007f4a08943507 in ioctl () at ../sysdeps/unix/syscall-template.S:81
#1  0x00007f4a216acb55 in kvm_vcpu_ioctl (cpu=cpu@entry=0x7f4a24cca000, type=type@entry=44672) at /usr/src/debug/qemu-2.6.0/kvm-all.c:2080
#2  0x00007f4a216acc0d in kvm_cpu_exec (cpu=cpu@entry=0x7f4a24cca000) at /usr/src/debug/qemu-2.6.0/kvm-all.c:1930
#3  0x00007f4a2169b756 in qemu_kvm_cpu_thread_fn (arg=<optimized out>) at /usr/src/debug/qemu-2.6.0/cpus.c:1076
#4  0x00007f4a08c1ddc5 in start_thread (arg=0x7f49fb858700) at pthread_create.c:308
#5  0x00007f4a0894c73d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113
Thread 4 (Thread 0x7f49fb057700 (LWP 3063)):
#0  0x00007f4a08943507 in ioctl () at ../sysdeps/unix/syscall-template.S:81
#1  0x00007f4a216acb55 in kvm_vcpu_ioctl (cpu=cpu@entry=0x7f4a24cea000, type=type@entry=44672) at /usr/src/debug/qemu-2.6.0/kvm-all.c:2080
#2  0x00007f4a216acc0d in kvm_cpu_exec (cpu=cpu@entry=0x7f4a24cea000) at /usr/src/debug/qemu-2.6.0/kvm-all.c:1930
#3  0x00007f4a2169b756 in qemu_kvm_cpu_thread_fn (arg=<optimized out>) at /usr/src/debug/qemu-2.6.0/cpus.c:1076
#4  0x00007f4a08c1ddc5 in start_thread (arg=0x7f49fb057700) at pthread_create.c:308
#5  0x00007f4a0894c73d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113
Thread 3 (Thread 0x7f49fa856700 (LWP 3064)):
#0  0x00007f4a08943507 in ioctl () at ../sysdeps/unix/syscall-template.S:81
#1  0x00007f4a216acb55 in kvm_vcpu_ioctl (cpu=cpu@entry=0x7f4a24d02000, type=type@entry=44672) at /usr/src/debug/qemu-2.6.0/kvm-all.c:2080
#2  0x00007f4a216acc0d in kvm_cpu_exec (cpu=cpu@entry=0x7f4a24d02000) at /usr/src/debug/qemu-2.6.0/kvm-all.c:1930
#3  0x00007f4a2169b756 in qemu_kvm_cpu_thread_fn (arg=<optimized out>) at /usr/src/debug/qemu-2.6.0/cpus.c:1076
#4  0x00007f4a08c1ddc5 in start_thread (arg=0x7f49fa856700) at pthread_create.c:308
#5  0x00007f4a0894c73d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113
Thread 2 (Thread 0x7f49a6dff700 (LWP 3066)):
#0  0x00007f4a08941dfd in poll () at ../sysdeps/unix/syscall-template.S:81
#1  0x00007f4a0a678327 in poll (__timeout=<optimized out>, __nfds=20, __fds=0x7f4a26b18038) at /usr/include/bits/poll2.h:46
#2  red_worker_main (arg=<optimized out>) at red_worker.c:12247
#3  0x00007f4a08c1ddc5 in start_thread (arg=0x7f49a6dff700) at pthread_create.c:308
#4  0x00007f4a0894c73d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113
Thread 1 (Thread 0x7f4a213f3d00 (LWP 3048)):
#0  0x00007f4a08941ebf in __GI_ppoll (fds=0x7f4a25747c00, nfds=11, timeout=<optimized out>, timeout@entry=0x7ffd33f80c90, sigmask=sigmask@entry=0x0) at ../sysdeps/unix/sysv/linux/ppoll.c:56
#1  0x00007f4a2189f4c9 in ppoll (__ss=0x0, __timeout=0x7ffd33f80c90, __nfds=<optimized out>, __fds=<optimized out>) at /usr/include/bits/poll2.h:77
#2  qemu_poll_ns (fds=<optimized out>, nfds=<optimized out>, timeout=timeout@entry=29962271) at qemu-timer.c:325
#3  0x00007f4a2189ee5c in os_host_main_loop_wait (timeout=29962271) at main-loop.c:252
#4  main_loop_wait (nonblocking=<optimized out>) at main-loop.c:506
#5  0x00007f4a2166c80f in main_loop () at vl.c:1937
#6  main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at vl.c:4693
Comment 13 aihua liang 2016-11-16 11:42:11 UTC 
The key point for reproduce the bug is just "machine type:rhel6.5.0".

As yafu comment, this bug can be reproduced on 7.3 kernel:3.10.0-521.el7.x86_64+qemu-kvm-rhev:2.6.0-27.el7.x86_64 either.

I tried Gerd's Seabios version, it works ok with "rhel6.5.0".

So, hi, Salvatore
 Can you try Gerd's Seabios version mentioned in comment 11?
Comment 14 Ademar Reis 2016-11-16 12:47:07 UTC 
May be related: Bug 1395097 and Bug 1387140
Comment 15 Gerd Hoffmann 2016-11-16 13:17:59 UTC 
(In reply to Ademar Reis from comment #14)
> May be related: Bug 1395097 and Bug 1387140

Both look like duplicates indeed.
Comment 16 Salvatore Bognanni 2016-11-16 14:16:12 UTC 
(In reply to aihua liang from comment #13)
> The key point for reproduce the bug is just "machine type:rhel6.5.0".
> 
> As yafu comment, this bug can be reproduced on 7.3
> kernel:3.10.0-521.el7.x86_64+qemu-kvm-rhev:2.6.0-27.el7.x86_64 either.
> 
> I tried Gerd's Seabios version, it works ok with "rhel6.5.0".
> 
> So, hi, Salvatore
>  Can you try Gerd's Seabios version mentioned in comment 11?

Hi Liang,

I have done some tests with Gerd Hoffman's packages at : http://people.redhat.com/ghoffman/bz1392569/ and the issue is not happening anymore.

Salvatore
Comment 17 aihua liang 2016-11-17 02:21:28 UTC 
H(In reply to Salvatore Bognanni from comment #16)
> (In reply to aihua liang from comment #13)
> > The key point for reproduce the bug is just "machine type:rhel6.5.0".
> > 
> > As yafu comment, this bug can be reproduced on 7.3
> > kernel:3.10.0-521.el7.x86_64+qemu-kvm-rhev:2.6.0-27.el7.x86_64 either.
> > 
> > I tried Gerd's Seabios version, it works ok with "rhel6.5.0".
> > 
> > So, hi, Salvatore
> >  Can you try Gerd's Seabios version mentioned in comment 11?
> 
> Hi Liang,
> 
> I have done some tests with Gerd Hoffman's packages at :
> http://people.redhat.com/ghoffman/bz1392569/ and the issue is not happening
> anymore.
> 
> Salvatore

Got it，thanks Salvatore.
Comment 18 Greg Kable 2016-11-17 04:02:06 UTC 
Gerd's packages also solve the problem in my testing.
Comment 19 Ademar Reis 2016-11-29 11:05:09 UTC 

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