Red Hat Bugzilla – Bug 1356924
rtl8139 driver hangs in widows guests
Last modified: 2017-03-21 05:39:36 EDT
Hello! This is well know and already fixed bug http://git.qemu.org/?p=qemu.git;a=commit;h=00b7ade807b5ce6779ddd86ce29c5521ec5c529a But, as I see, patch is not included in RHEL6 qemu. And I can't recompile it (patched) on RHEL6 server: [root@roxar SPECS]# rpmbuild -bb qemu-kvm.spec ошибка: Неудовлетворенные зависимости сборки: texi2html нужен для qemu-kvm-2:0.12.1.2-2.491.el6.1.x86_64 dev86 нужен для qemu-kvm-2:0.12.1.2-2.491.el6.1.x86_64 iasl нужен для qemu-kvm-2:0.12.1.2-2.491.el6.1.x86_64 pciutils-devel нужен для qemu-kvm-2:0.12.1.2-2.491.el6.1.x86_64 usbredir-devel >= 0.5 нужен для qemu-kvm-2:0.12.1.2-2.491.el6.1.x86_64 lzo-devel нужен для qemu-kvm-2:0.12.1.2-2.491.el6.1.x86_64 spice-server-devel >= 0.12.3 нужен для qemu-kvm-2:0.12.1.2-2.491.el6.1.x86_64 [root@roxar SPECS]# yum install spice-server-devel Загружены модули: product-id, refresh-packagekit, search-disabled-repos, security Подготовка к установке Пакет spice-server-devel недоступен. Ошибка: Выполнять нечего [root@roxar SPECS]#
Fix included in qemu-kvm-0.12.1.2-2.494.el6
Hi Stefan, Seems QE can't reproduced this bug according to http://git.qemu.org/?p=qemu.git;a=commit;h=00b7ade807b5ce6779ddd86ce29c5521ec5c529a. Test versions: Host: 2.6.32-642.el6.x86_64 qemu-kvm-0.12.1.2-2.491.el6_8.3.x86_64 Test steps: 1.Luanch a win7 guest with rtl8139 Nic. 2.In Win7 guest From the FTP server download a 5G file. 3.check the rtl8139 driver status. works well. Command: /usr/libexec/qemu-kvm \ -S \ -name 'Windows' \ -machine pc \ -m 4096 \ -smp 4,maxcpus=4,sockets=1,cores=4,threads=1 \ -cpu SandyBridge,enforce \ -rtc base=localtime,clock=host,driftfix=slew \ -nodefaults \ -vga qxl \ -device AC97,bus=pci.0 \ -chardev socket,id=qmp_id_qmpmonitor1,path=/tmp/monitor-qmpmonitor1-20151214-111528-C6FB1EaX,server,nowait \ -mon chardev=qmp_id_qmpmonitor1,mode=control \ -chardev socket,id=qmp_id_catch_monitor,path=/tmp/monitor-catch_monitor-20151214-111528-C6FB1EaX,server,nowait \ -mon chardev=qmp_id_catch_monitor,mode=control \ -device pvpanic,ioport=0x505,id=idSWJ5gV \ -chardev socket,id=serial_id_serial0,path=/tmp/serial-serial0-20151214-111528-C6FB1EaX,server,nowait \ -device isa-serial,chardev=serial_id_serial0 \ -chardev socket,id=seabioslog_log,path=/tmp/seabios-log,server,nowait \ -device isa-debugcon,chardev=seabioslog_log,iobase=0x402 \ -device ich9-usb-ehci1,id=usb1,addr=1d.7,multifunction=on,bus=pci.0 \ -device ich9-usb-uhci1,id=usb1.0,multifunction=on,masterbus=usb1.0,addr=1d.0,firstport=0,bus=pci.0 \ -device ich9-usb-uhci2,id=usb1.1,multifunction=on,masterbus=usb1.0,addr=1d.2,firstport=2,bus=pci.0 \ -device ich9-usb-uhci3,id=usb1.2,multifunction=on,masterbus=usb1.0,addr=1d.4,firstport=4,bus=pci.0 \ -device usb-tablet,id=usb-tablet1 \ -boot menu=on \ -enable-kvm \ -monitor stdio \ -spice port=5900,disable-ticketing \ -qmp tcp:0:9999,server,nowait \ -netdev tap,id=netdev0,script=/etc/qemu-ifup,downscript=/etc/ifdown_script \ -device rtl8139,mac=52:54:13:83:4F:BD,id=net0,netdev=netdev0,bus=pci.0 \ -device virtio-scsi-pci,id=scsi0 \ -drive file=/home/win7-64-sp1-virtio-scsi.qcow2,format=qcow2,id=drive_sysdisk,if=none,cache=none,aio=native,werror=stop,rerror=stop \ -device scsi-hd,drive=drive_sysdisk,bus=scsi0.0,id=device_sysdisk,bootindex=0 \ -device virtio-scsi-pci,id=scsi1 If I have mistake please correct me, if also can't reproduce this bug, Can I run a rtl8139 NIC function test with Win7 guest to verify this bug? Thanks Wei.
This bug can't be easily reproduced by just 5Gb data copy. We had stuck network after several days of VM uptime. btw, we switched to e1000 and now everything is fine :-)
(In reply to Need Real Name from comment #6) > This bug can't be easily reproduced by just 5Gb data copy. > We had stuck network after several days of VM uptime. > btw, we switched to e1000 and now everything is fine :-) Can you share me how to reproduced the bug? Thanks
Sure, just install windows server in VM in production (low traffic in our case) with rtl8139 on RHEL 6. Wait :-)
(In reply to weliao from comment #5) > Hi Stefan, > Seems QE can't reproduced this bug according to > http://git.qemu.org/?p=qemu.git;a=commit; > h=00b7ade807b5ce6779ddd86ce29c5521ec5c529a. > > Test versions: > Host: > 2.6.32-642.el6.x86_64 > qemu-kvm-0.12.1.2-2.491.el6_8.3.x86_64 > > Test steps: > 1.Luanch a win7 guest with rtl8139 Nic. > 2.In Win7 guest From the FTP server download a 5G file. > 3.check the rtl8139 driver status. > works well. > > Command: > /usr/libexec/qemu-kvm \ > -S \ > -name 'Windows' \ > -machine pc \ > -m 4096 \ > -smp 4,maxcpus=4,sockets=1,cores=4,threads=1 \ > -cpu SandyBridge,enforce \ > -rtc base=localtime,clock=host,driftfix=slew \ > -nodefaults \ > -vga qxl \ > -device AC97,bus=pci.0 \ > -chardev > socket,id=qmp_id_qmpmonitor1,path=/tmp/monitor-qmpmonitor1-20151214-111528- > C6FB1EaX,server,nowait \ > -mon chardev=qmp_id_qmpmonitor1,mode=control \ > -chardev > socket,id=qmp_id_catch_monitor,path=/tmp/monitor-catch_monitor-20151214- > 111528-C6FB1EaX,server,nowait \ > -mon chardev=qmp_id_catch_monitor,mode=control \ > -device pvpanic,ioport=0x505,id=idSWJ5gV \ > -chardev > socket,id=serial_id_serial0,path=/tmp/serial-serial0-20151214-111528- > C6FB1EaX,server,nowait \ > -device isa-serial,chardev=serial_id_serial0 \ > -chardev socket,id=seabioslog_log,path=/tmp/seabios-log,server,nowait \ > -device isa-debugcon,chardev=seabioslog_log,iobase=0x402 \ > -device ich9-usb-ehci1,id=usb1,addr=1d.7,multifunction=on,bus=pci.0 \ > -device > ich9-usb-uhci1,id=usb1.0,multifunction=on,masterbus=usb1.0,addr=1d.0, > firstport=0,bus=pci.0 \ > -device > ich9-usb-uhci2,id=usb1.1,multifunction=on,masterbus=usb1.0,addr=1d.2, > firstport=2,bus=pci.0 \ > -device > ich9-usb-uhci3,id=usb1.2,multifunction=on,masterbus=usb1.0,addr=1d.4, > firstport=4,bus=pci.0 \ > -device usb-tablet,id=usb-tablet1 \ > -boot menu=on \ > -enable-kvm \ > -monitor stdio \ > -spice port=5900,disable-ticketing \ > -qmp tcp:0:9999,server,nowait \ > -netdev tap,id=netdev0,script=/etc/qemu-ifup,downscript=/etc/ifdown_script \ > -device rtl8139,mac=52:54:13:83:4F:BD,id=net0,netdev=netdev0,bus=pci.0 \ > -device virtio-scsi-pci,id=scsi0 \ > -drive > file=/home/win7-64-sp1-virtio-scsi.qcow2,format=qcow2,id=drive_sysdisk, > if=none,cache=none,aio=native,werror=stop,rerror=stop \ > -device > scsi-hd,drive=drive_sysdisk,bus=scsi0.0,id=device_sysdisk,bootindex=0 \ > -device virtio-scsi-pci,id=scsi1 > > If I have mistake please correct me, if also can't reproduce this bug, Can I > run a rtl8139 NIC function test with Win7 guest to verify this bug? Your configuration looks fine. The bug is triggered when the NIC receive buffers are exhausted. This is most likely to happen when the FTP server runs on the host. If you used an FTP server on another machine then the chance of exhausting rtl8139 receive buffers is lower. Was your FTP server running on the host? Stefan
(In reply to Stefan Hajnoczi from comment #9) > (In reply to weliao from comment #5) > > Hi Stefan, > > Seems QE can't reproduced this bug according to > > http://git.qemu.org/?p=qemu.git;a=commit; > > h=00b7ade807b5ce6779ddd86ce29c5521ec5c529a. > > > > Test versions: > > Host: > > 2.6.32-642.el6.x86_64 > > qemu-kvm-0.12.1.2-2.491.el6_8.3.x86_64 > > > > Test steps: > > 1.Luanch a win7 guest with rtl8139 Nic. > > 2.In Win7 guest From the FTP server download a 5G file. > > 3.check the rtl8139 driver status. > > works well. > > > > Command: > > /usr/libexec/qemu-kvm \ > > -S \ > > -name 'Windows' \ > > -machine pc \ > > -m 4096 \ > > -smp 4,maxcpus=4,sockets=1,cores=4,threads=1 \ > > -cpu SandyBridge,enforce \ > > -rtc base=localtime,clock=host,driftfix=slew \ > > -nodefaults \ > > -vga qxl \ > > -device AC97,bus=pci.0 \ > > -chardev > > socket,id=qmp_id_qmpmonitor1,path=/tmp/monitor-qmpmonitor1-20151214-111528- > > C6FB1EaX,server,nowait \ > > -mon chardev=qmp_id_qmpmonitor1,mode=control \ > > -chardev > > socket,id=qmp_id_catch_monitor,path=/tmp/monitor-catch_monitor-20151214- > > 111528-C6FB1EaX,server,nowait \ > > -mon chardev=qmp_id_catch_monitor,mode=control \ > > -device pvpanic,ioport=0x505,id=idSWJ5gV \ > > -chardev > > socket,id=serial_id_serial0,path=/tmp/serial-serial0-20151214-111528- > > C6FB1EaX,server,nowait \ > > -device isa-serial,chardev=serial_id_serial0 \ > > -chardev socket,id=seabioslog_log,path=/tmp/seabios-log,server,nowait \ > > -device isa-debugcon,chardev=seabioslog_log,iobase=0x402 \ > > -device ich9-usb-ehci1,id=usb1,addr=1d.7,multifunction=on,bus=pci.0 \ > > -device > > ich9-usb-uhci1,id=usb1.0,multifunction=on,masterbus=usb1.0,addr=1d.0, > > firstport=0,bus=pci.0 \ > > -device > > ich9-usb-uhci2,id=usb1.1,multifunction=on,masterbus=usb1.0,addr=1d.2, > > firstport=2,bus=pci.0 \ > > -device > > ich9-usb-uhci3,id=usb1.2,multifunction=on,masterbus=usb1.0,addr=1d.4, > > firstport=4,bus=pci.0 \ > > -device usb-tablet,id=usb-tablet1 \ > > -boot menu=on \ > > -enable-kvm \ > > -monitor stdio \ > > -spice port=5900,disable-ticketing \ > > -qmp tcp:0:9999,server,nowait \ > > -netdev tap,id=netdev0,script=/etc/qemu-ifup,downscript=/etc/ifdown_script \ > > -device rtl8139,mac=52:54:13:83:4F:BD,id=net0,netdev=netdev0,bus=pci.0 \ > > -device virtio-scsi-pci,id=scsi0 \ > > -drive > > file=/home/win7-64-sp1-virtio-scsi.qcow2,format=qcow2,id=drive_sysdisk, > > if=none,cache=none,aio=native,werror=stop,rerror=stop \ > > -device > > scsi-hd,drive=drive_sysdisk,bus=scsi0.0,id=device_sysdisk,bootindex=0 \ > > -device virtio-scsi-pci,id=scsi1 > > > > If I have mistake please correct me, if also can't reproduce this bug, Can I > > run a rtl8139 NIC function test with Win7 guest to verify this bug? > > Your configuration looks fine. > > The bug is triggered when the NIC receive buffers are exhausted. This is > most likely to happen when the FTP server runs on the host. If you used an > FTP server on another machine then the chance of exhausting rtl8139 receive > buffers is lower. > > Was your FTP server running on the host? > > Stefan Yes, My FTP server was rinning on the host, but I download a 10G file from host repeat 10 times also can't reproduced this bug !! Wei
If you cannot reproduce it I would move on. It's a race condition so it may not be easy to reproduce reliably.
(In reply to Stefan Hajnoczi from comment #11) > If you cannot reproduce it I would move on. It's a race condition so it may > not be easy to reproduce reliably. Hi Stefan: Since hard to reproduce this bug, May I do a regression test to verify this bug?
(In reply to weliao from comment #12) > (In reply to Stefan Hajnoczi from comment #11) > > If you cannot reproduce it I would move on. It's a race condition so it may > > not be easy to reproduce reliably. > > Hi Stefan: > > Since hard to reproduce this bug, May I do a regression test to verify this > bug? Yes, that is fine.
Test Rtl8137 NIC with following versions: 2.6.32-672.el6.x86_64 qemu-kvm-0.12.1.2-2.496.el6.x86_64 Guest: Win7 X86 Log link: http://10.66.4.244/kvm_autotest_job_log/?jobid=1615766 Analysis the log didn't find the regression bug,according to #C13 update the bug to VERIFIED status.
Jirka, I have filled in the doc text.
Doc Text looks good.
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://rhn.redhat.com/errata/RHSA-2017-0621.html