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.
Bug 1356924 - rtl8139 driver hangs in widows guests
Summary: rtl8139 driver hangs in widows guests
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: qemu-kvm
Version: 6.8
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: rc
: ---
Assignee: Stefan Hajnoczi
QA Contact: weliao
Yehuda Zimmerman
URL:
Whiteboard:
Depends On:
Blocks: 1359965 1364808
TreeView+ depends on / blocked
 
Reported: 2016-07-15 09:36 UTC by Dmitry Melekhov
Modified: 2017-03-21 09:39 UTC (History)
8 users (show)

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.
Clone Of:
Environment:
Last Closed: 2017-03-21 09:39:36 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2017:0621 0 normal SHIPPED_LIVE Moderate: qemu-kvm security and bug fix update 2017-03-21 12:28:31 UTC

Description Dmitry Melekhov 2016-07-15 09:36:52 UTC 
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]#
Comment 3 Jeff Nelson 2016-09-22 13:49:25 UTC 
Fix included in qemu-kvm-0.12.1.2-2.494.el6
Comment 5 weliao 2016-11-23 05:46:51 UTC 
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.
Comment 6 Dmitry Melekhov 2016-11-23 06:02:16 UTC 
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 :-)
Comment 7 weliao 2016-11-23 06:14:47 UTC 
(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
Comment 8 Dmitry Melekhov 2016-11-23 06:19:34 UTC 
Sure, just install windows server in VM in production (low traffic in our case) with rtl8139 on RHEL 6.
Wait :-)
Comment 9 Stefan Hajnoczi 2016-11-24 09:22:50 UTC 
(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
Comment 10 weliao 2016-11-25 05:53:42 UTC 
(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
Comment 11 Stefan Hajnoczi 2016-11-28 16:57:03 UTC 
If you cannot reproduce it I would move on.  It's a race condition so it may not be easy to reproduce reliably.
Comment 12 weliao 2016-11-30 02:26:51 UTC 
(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?
Comment 13 Stefan Hajnoczi 2016-11-30 09:39:25 UTC 
(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.
Comment 14 weliao 2016-12-01 08:51:08 UTC 
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.
Comment 16 Stefan Hajnoczi 2016-12-08 14:56:26 UTC 
Jirka,
I have filled in the doc text.
Comment 18 Stefan Hajnoczi 2017-01-04 14:00:36 UTC 
Doc Text looks good.
Comment 20 errata-xmlrpc 2017-03-21 09:39:36 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.

https://rhn.redhat.com/errata/RHSA-2017-0621.html
Note You need to log in before you can comment on or make changes to this bug.