Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
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:
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


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2017:0621 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.