Bug 1356924
| Summary: | rtl8139 driver hangs in widows guests | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Dmitry Melekhov <dm> |
| Component: | qemu-kvm | Assignee: | Stefan Hajnoczi <stefanha> |
| Status: | CLOSED ERRATA | QA Contact: | weliao <weliao> |
| Severity: | high | Docs Contact: | Yehuda Zimmerman <yzimmerm> |
| Priority: | unspecified | ||
| Version: | 6.8 | CC: | ailan, chayang, juzhang, mkenneth, rbalakri, stefanha, virt-maint, weliao |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | qemu-kvm-0.12.1.2-2.494.el6 | Doc Type: | Bug Fix |
| Doc Text: |
Network connectivity maintained when using rtl8139 device emulation
Previously, when using rtl8139 device emulation, the virtual device sometimes disabled packet reception. As a consequence, network connectivity was lost. With this update, the issue was resolved, and network connectivity is maintained.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2017-03-21 09:39:36 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: | |||
| Bug Depends On: | |||
| Bug Blocks: | 1359965, 1364808 | ||
|
Description
Dmitry Melekhov
2016-07-15 09:36:52 UTC
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 |