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 1716248 - [virtio-win][netkvm] can not ping out when boot with "queues=4,vectors=5/6/7/8" on win7 and win2008r2
Summary: [virtio-win][netkvm] can not ping out when boot with "queues=4,vectors=5/6/7/...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: virtio-win
Version: 8.1
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: rc
: 8.1
Assignee: ybendito
QA Contact: lijin
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-06-03 02:22 UTC by Yu Wang
Modified: 2020-11-14 07:37 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-07-30 14:22:07 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
Batch for collecting nerkvm trace (1.21 KB, text/plain)
2019-06-04 18:12 UTC, ybendito 		no flags Details
trace_log (121.11 KB, application/zip)
2019-06-05 04:32 UTC, Yu Wang 		no flags Details
trace_cmd_log (50.55 KB, application/zip)
2019-06-05 04:51 UTC, Yu Wang 		no flags Details
Driver for test (6.36 MB, application/zip)
2019-06-05 16:28 UTC, ybendito 		no flags Details
build168-netkvm (408.00 KB, application/octet-stream)
2019-06-06 02:48 UTC, Yu Wang 		no flags Details
View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2019:1997 0 None None None 2019-07-30 14:22:10 UTC

Description Yu Wang 2019-06-03 02:22:11 UTC 
Description of problem:
 can not ping out when boot with "queues=4,vectors=5/6/7/8" on win7 and win2008r2

Version-Release number of selected component (if applicable):

    virtio-win-prewhql-171
    qemu-kvm-rhev-2.12.0-29.el7.x86_64
    kernel-3.10.0-1048.el7.x86_64
    seabios-bin-1.11.0-2.el7.noarch

How reproducible:
100%

Steps to Reproduce:
1. boot guest with queues=4,vectors=5/6/7/8

-device virtio-net-pci,mac=9a:57:58:59:5a:5b,id=id7aRAGK,mq=on,vectors=5,netdev=idvtcVZ0,bus=pci.0,addr=0x5 -netdev tap,id=idvtcVZ0,vhost=on,queues=4 -m 4096 -smp 4,maxcpus=4,cores=2,threads=1,sockets=2


2. ping out
3.

Actual results:
Get ip slowly but can get valid ip, but cannot ping out successfully

Expected results:
ping out successfully

Additional info:
1 can ping out with vectors=0/1/2/3/4/9/10
2 can ping out with "virtio-win-prewhql-160" (rhel7.6 release version)
3 can ping out on RHEL8 host
4 can ping out on win8-32/win2012/win2016/win2019

So it happens on RHEL7 host and it is a regression
Comment 3 Yvugenfi@redhat.com 2019-06-04 11:07:20 UTC 
Hello,

* Is the issue happens on Win7 32 bit or Win7 64 bit?

* Can you please also add the part of QEMU command line related to "-cpu" (all the flags that were passed to -cpu)?

Thanks,
Yan.
Comment 4 ybendito 2019-06-04 18:12:26 UTC 
Created attachment 1577231 [details]
Batch for collecting nerkvm trace
Comment 5 ybendito 2019-06-04 18:19:03 UTC 
Assuming the problem is 100% reproducible, let's focus on 'vectors=5' and on 2008r2
Please use the attched trace.cmd to collect trace for 171 and 160 as following:
0. Install build 171
1. disable netkvm adapter, set in device manager - advanced - 'Log.Level' to 1
2. Run trace.cmd as an administrator (via right click is ok)
3. Enable the adapter, reproduce the problem (ip address acquired slow, ping does not work)
4. Hit 'enter' in the trace console, collect the netkvm.ETL file
Uninstall the driver, install build 160, repeat the sequence 1-4 (ping works)
Please attach both ETL files.
Comment 6 Yu Wang 2019-06-05 01:53:32 UTC 
(In reply to Yan Vugenfirer from comment #3)
> Hello,
> 
> * Is the issue happens on Win7 32 bit or Win7 64 bit?
> 
> * Can you please also add the part of QEMU command line related to "-cpu"
> (all the flags that were passed to -cpu)?
> 
> Thanks,
> Yan.

It happens on both win7-32 and win7-64

-cpu 'Skylake-Server',hv_relaxed,hv_spinlocks=0x1fff,hv_vapic,hv_time,hv_stimer,hv_synic,hv_vpindex,hv_reset,+kvm_pv_unhalt 

Thanks
Yu Wang
Comment 7 Yu Wang 2019-06-05 01:58:23 UTC 
Incase further debug, full command line is:

MALLOC_PERTURB_=1  /usr/libexec/qemu-kvm \
    -S  \
    -name 'avocado-vt-vm1' \
    -machine pc  \
    -nodefaults \
    -device VGA,bus=pci.0,addr=0x2  \
    -chardev socket,id=qmp_id_qmpmonitor1,path=/var/tmp/avocado_9zyOav1,server,nowait \
    -mon chardev=qmp_id_qmpmonitor1,mode=control  \
    -chardev socket,id=qmp_id_catch_monitor,path=/var/tmp/avocado_9zyOav1,server,nowait \
    -mon chardev=qmp_id_catch_monitor,mode=control \
    -device pvpanic,ioport=0x505,id=idjbRflp  \
    -chardev socket,id=serial_id_serial0,path=/var/tmp/avocado_9zyOav1,server,nowait \
    -device isa-serial,chardev=serial_id_serial0  \
    -chardev socket,id=seabioslog_id_20190530-080253-xoJfEwhA,path=/var/tmp/avocado_9zyOav1,server,nowait \
    -device isa-debugcon,chardev=seabioslog_id_20190530-080253-xoJfEwhA,iobase=0x402 \
    -device nec-usb-xhci,id=usb1,bus=pci.0,addr=0x3 \
    -device virtio-scsi-pci,id=virtio_scsi_pci0,bus=pci.0,addr=0x4 \
    -drive id=drive_image1,if=none,snapshot=on,aio=threads,cache=none,format=qcow2,file=/home/kvm_autotest_root/images/win2008-r2-64-virtio-scsi.qcow2 \
    -device scsi-hd,id=image1,drive=drive_image1 \
    -device virtio-net-pci,mac=9a:57:58:59:5a:5b,id=id7aRAGK,mq=on,vectors=5,netdev=idvtcVZ0,bus=pci.0,addr=0x5  \
    -netdev tap,id=idvtcVZ0,vhost=on,queues=4 \
    -m 4096  \
    -smp 4,maxcpus=4,cores=2,threads=1,sockets=2  \
    -cpu 'Skylake-Server',hv_relaxed,hv_spinlocks=0x1fff,hv_vapic,hv_time,hv_stimer,hv_synic,hv_vpindex,hv_reset,+kvm_pv_unhalt \
    -drive id=drive_cd1,if=none,snapshot=on,aio=threads,cache=none,media=cdrom,file=/home/kvm_autotest_root/iso/windows/winutils.iso \
    -device scsi-cd,id=cd1,drive=drive_cd1 \
    -drive id=drive_virtio,if=none,snapshot=on,aio=threads,cache=none,media=cdrom,file=/home/kvm_autotest_root/iso/windows/virtio-win-prewhql-0.1-171.iso \
    -device scsi-cd,id=virtio,drive=drive_virtio \
    -device usb-tablet,id=usb-tablet1,bus=usb1.0,port=1  \
    -vnc :1  \
    -rtc base=localtime,clock=host,driftfix=slew  \
    -boot menu=off,strict=off,order=cdn,once=c \
    -enable-kvm \
    -monitor stdio
Comment 8 Yu Wang 2019-06-05 04:32:00 UTC 
(In reply to ybendito from comment #5)
> Assuming the problem is 100% reproducible, let's focus on 'vectors=5' and on
> 2008r2
> Please use the attched trace.cmd to collect trace for 171 and 160 as
> following:
> 0. Install build 171
> 1. disable netkvm adapter, set in device manager - advanced - 'Log.Level' to
> 1
> 2. Run trace.cmd as an administrator (via right click is ok)
> 3. Enable the adapter, reproduce the problem (ip address acquired slow, ping
> does not work)
> 4. Hit 'enter' in the trace console, collect the netkvm.ETL file
> Uninstall the driver, install build 160, repeat the sequence 1-4 (ping works)
> Please attach both ETL files.

I tried as above and attached the log (trace_log.zip)

I found a strange thing, when I open the traceview and configure it to collect the log, 
no matter I change the "'Log.Level" or not, I can still get the valid ip and ping out 
successfully (win2008r2 with build 160 and vectors=5)

Thanks
Yu Wang
Comment 9 Yu Wang 2019-06-05 04:32:36 UTC 
Created attachment 1577413 [details]
trace_log
Comment 10 Yu Wang 2019-06-05 04:51:40 UTC 
Created attachment 1577414 [details]
trace_cmd_log

Here is the log (including build 160 and build 171
It can get ip after disable/enable network device when running "trace.cmd".
So I cannot reproduce this issue when running with "trace.cmd", but it can reproduce 100% when not running it.

boot with vectors=5, ws2008r2, build 171

Thanks
Yu Wang
Comment 11 ybendito 2019-06-05 09:19:56 UTC 
Can you please check whether the problem happens on builds 162, 163, 168?
If it does happen on one of them - please attach the record as described in comment #5
Thanks
Comment 12 ybendito 2019-06-05 16:28:47 UTC 
Created attachment 1577639 [details]
Driver for test
Comment 13 ybendito 2019-06-05 16:54:11 UTC 
Please check whether attached driver (Comment #12) fixes the problem.
Do not forget to enable test signature.
The ZIP contains both 32-bit and 64-bit drivers.
Comment 14 Yu Wang 2019-06-06 02:46:39 UTC 
(In reply to ybendito from comment #11)
> Can you please check whether the problem happens on builds 162, 163, 168?
> If it does happen on one of them - please attach the record as described in
> comment #5
> Thanks
It can reproduce this issue with build168 ,  cannot reproduce it with build 167.

trace log pls refer to the attachment  (build168-netkvm)

Thanks
Yu Wang
Comment 15 Yu Wang 2019-06-06 02:48:04 UTC 
Created attachment 1577776 [details]
build168-netkvm
Comment 16 Yu Wang 2019-06-06 02:58:51 UTC 
(In reply to ybendito from comment #13)
> Please check whether attached driver (Comment #12) fixes the problem.
> Do not forget to enable test signature.
> The ZIP contains both 32-bit and 64-bit drivers.

Test on win7-32 and ws2008R2 with the tmp driver, cannot reproduce this issue now.

Thanks
Yu Wang
Comment 17 Yvugenfi@redhat.com 2019-06-06 13:34:11 UTC 
Ths fix: https://github.com/virtio-win/kvm-guest-drivers-windows/pull/401
Comment 22 ybendito 2019-06-09 13:19:12 UTC 
Should be fixed in build 172

https://brewweb.engineering.redhat.com/brew/buildinfo?buildID=908642
Comment 23 ybendito 2019-06-09 13:22:36 UTC 
Indeed, why this bug is for 7.7, if this bug does not exist in 160 and 162?
Comment 24 lijin 2019-06-10 01:07:19 UTC 
(In reply to ybendito from comment #23)
> Indeed, why this bug is for 7.7, if this bug does not exist in 160 and 162?

This issue occurs only on rhel7 host(rhel8 can not reproduce according to comment#0), that's why we file it on rhel7 first.
Will move it to rhel8 after the verification.
Comment 25 Yu Wang 2019-06-10 04:27:34 UTC 
Test with virtio-win-prewhql-172, I can get valid ip and ping out successfully with vectors=5/6/7/8 on RHEL7 host.

    virtio-win-prewhql-172
    qemu-kvm-rhev-2.12.0-29.el7.x86_64
    kernel-3.10.0-1048.el7.x86_64
    seabios-bin-1.11.0-2.el7.noarch
    ws2008r2,win7-32/64

So this bug has been fixed now, change status to "verified"

Thanks a lot
Yu Wang
Comment 27 Danilo de Paula 2019-06-25 14:24:34 UTC 
This BZ needs exception+ to be allowed into the 8.0.1 batch update.
Comment 31 errata-xmlrpc 2019-07-30 14:22:07 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://access.redhat.com/errata/RHEA-2019:1997
Note You need to log in before you can comment on or make changes to this bug.