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 1049264 - virtio ethernet drivers do not work in Windows 7 SP1 32-bit without disabling TCP/UDP checksum offload
Summary: virtio ethernet drivers do not work in Windows 7 SP1 32-bit without disabling...
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: virtio-win
Version: 7.0
Hardware: x86_64
OS: Windows
unspecified
medium
Target Milestone: rc
: ---
Assignee: Ronen Hod
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-01-07 10:04 UTC by Marcin Krol
Modified: 2014-12-15 00:54 UTC (History)
14 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-01-09 13:22:57 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Marcin Krol 2014-01-07 10:04:53 UTC
Description of problem:


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

I used drivers available in virtio-win-0.1-74.iso.

How reproducible:

Always.

Steps to Reproduce:

1. For win 7 pro sp1 32-bit guest install *bridged* virtio eth driver card in virt-manager (config is like Source device: Host device vnet 3 (bridge 'br0'), Device model: virtio). 

2. Reboot guest.

3. If you have DHCP server available for guests, just leave all defaults. Otherwise, configure static tcp/ip v4 in windows the usual way.

Actual results:

The card cannot communicate with host or other machines in network.

Expected results:

The card works as expected.

Additional info:

Disable TCP Checksum Offload and UDP Checksum Offload in eth card config in Windows guest. This makes the card work instantly (not even reboot necessary). More info at:

http://serverfault.com/questions/565039/kvm-win-7-pro-rh-virtio-net-driver

Comment 2 Mike Cao 2014-01-08 03:17:13 UTC
I can not reproduce this issue on RHEL7

versions:
virtio-win-prewhql-0.1.74
3.10.0-50.el7.x86_64
seabios-1.7.2.2-4.el7.x86_64
package sgabios is not installed
package qemu-kvm is not installed
qemu-kvm-rhev-1.5.3-19.el7.x86_64

steps:
1.Start win7-32 bit guest on RHEL7 host
/usr/libexec/qemu-kvm -M rhel6.5.0 -cpu SandyBridge -enable-kvm -m 2G -smp 2,cores=2 -name bcao_win-7-32-netkvm -uuid 884e673a-1b4a-4385-a522-b3cc35ef4e18 -rtc base=localtime,clock=host,driftfix=slew -drive file=win7-32.qcow2,if=none,media=disk,serial=aaabbbccc,werror=stop,rerror=stop,cache=none,format=qcow2,id=drive-disk0 -device ide-drive,bus=ide.0,unit=1,physical_block_size=4096,logical_block_size=512,drive=drive-disk0,id=disk0 -drive file=en_windows_7_ultimate_with_sp1_x86_dvd_u_677460.iso,if=none,media=cdrom,id=aa -device ide-drive,id=aa1,drive=aa,bootindex=1 -drive file=/usr/share/virtio-win/virtio-win.iso,media=cdrom,if=none,id=bb -device ide-drive,id=bb1,drive=bb -netdev tap,vhost=on,id=netdev0 -device virtio-net-pci,netdev=netdev0,id=nic1,mac=1a:46:1b:ca:bc:7b -vnc :2 -monitor stdio -usb -device usb-tablet,id=tablet0 -global PIIX4_PM.disable_s3=0 -global PIIX_PM.disable_s4=0 -monitor unix:/tmp/tt,server,nowait -boot menu=on 
2.install netkvm driver from virito-win-prewhql-0.1-74
3.disable following options 
TCP Checksum Offload (IPv4)
TCP Checksum Offload (IPv6)
UDP Checksum Offload (IPv4)
UDP Checksum Offload (IPv6)

Actual Restults:
guest still can commnunicate with host and other machines

Comment 3 Ronen Hod 2014-01-08 09:40:42 UTC
Dear Marcin,

Thank you for taking the time to enter a bug report with us. We appreciate the feedback and look to use reports such as this to guide our efforts at improving our products. That being said, this bug tracking system is not a mechanism for requesting support, and we are not able to  guarantee the timeliness or suitability of a resolution.
 
If this issue is critical or in any way time sensitive, please raise a ticket through your regular Red Hat support channels to make certain  it receives the proper attention and prioritization to assure a timely resolution. 
 
For information on how to contact the Red Hat production support team, please visit:
https://www.redhat.com/support/process/production/#howto

Comment 4 Marcin Krol 2014-01-08 11:37:12 UTC
@Mike Cao: have you tried using the virtio eth card BEFORE disabling TCP/UDP Checksum Offload?

AFTER disabling checksum offloads the card works, yes, but not with checksum offload functions enabled. That's what I'm reporting.

@Ronen Hod: I do not ask for support here, after all I was able to make the virtio eth card work. Just wanted to let you know there might be a problem.

Comment 5 Yvugenfi@redhat.com 2014-01-08 12:12:22 UTC
Hi Marcin,

Thank you for your report.

Can you send the result of "ethtool -k" on the tap device and bridge on the host?

Thanks,
Yan.

Comment 6 Marcin Krol 2014-01-08 14:16:15 UTC
    % ethtool -k eth0
    Features for eth0:
    rx-checksumming: on
    tx-checksumming: on
            tx-checksum-ipv4: on
            tx-checksum-unneeded: off [fixed]
            tx-checksum-ip-generic: off [fixed]
            tx-checksum-ipv6: on
            tx-checksum-fcoe-crc: off [fixed]
            tx-checksum-sctp: on
    scatter-gather: on
            tx-scatter-gather: on
            tx-scatter-gather-fraglist: off [fixed]
    tcp-segmentation-offload: on
            tx-tcp-segmentation: on
            tx-tcp-ecn-segmentation: off [fixed]
            tx-tcp6-segmentation: on
    udp-fragmentation-offload: off [fixed]
    generic-segmentation-offload: on
    generic-receive-offload: on
    large-receive-offload: off
    rx-vlan-offload: on
    tx-vlan-offload: on
    ntuple-filters: off [fixed]
    receive-hashing: on
    highdma: on [fixed]
    rx-vlan-filter: on [fixed]
    vlan-challenged: off [fixed]
    tx-lockless: off [fixed]
    netns-local: off [fixed]
    tx-gso-robust: off [fixed]
    tx-fcoe-segmentation: off [fixed]
    fcoe-mtu: off [fixed]
    tx-nocache-copy: on
    loopback: off [fixed]




    % ethtool -k br0
    Features for br0:
    rx-checksumming: off [fixed]
    tx-checksumming: on
            tx-checksum-ipv4: off [fixed]
            tx-checksum-unneeded: off [requested on]
            tx-checksum-ip-generic: on [fixed]
            tx-checksum-ipv6: off [fixed]
            tx-checksum-fcoe-crc: off [fixed]
            tx-checksum-sctp: off [fixed]
    scatter-gather: on
            tx-scatter-gather: on
            tx-scatter-gather-fraglist: on
    tcp-segmentation-offload: on
            tx-tcp-segmentation: on
            tx-tcp-ecn-segmentation: on
            tx-tcp6-segmentation: on
    udp-fragmentation-offload: on
    generic-segmentation-offload: on
    generic-receive-offload: on
    large-receive-offload: off [fixed]
    rx-vlan-offload: off [fixed]
    tx-vlan-offload: on
    ntuple-filters: off [fixed]
    receive-hashing: off [fixed]
    highdma: on
    rx-vlan-filter: off [fixed]
    vlan-challenged: off [fixed]
    tx-lockless: on [fixed]
    netns-local: on [fixed]
    tx-gso-robust: off [requested on]
    tx-fcoe-segmentation: off [requested on]
    fcoe-mtu: off [fixed]
    tx-nocache-copy: off
    loopback: off [fixed]


Note: the eth0 card is Intel's I210 Gigabit controller:

    % lspci | grep -i eth
    05:00.0 Ethernet controller: Intel Corporation I210 Gigabit Network Connection (rev 03)
    06:00.0 Ethernet controller: Intel Corporation I210 Gigabit Network Connection (rev 03)

The drivers do not seem to be present in stock kernel, so I used ones provided by Intel, archive:

    https://downloadcenter.intel.com/Detail_Desc.aspx?DwnldID=13663

    file: igb-5.0.6.tar.gz


Modprobe card settings I used are as follows:

    alias eth0 igb
    alias eth1 igb
    options igb IntMode=2,1

Comment 7 Marcin Krol 2014-01-08 14:18:11 UTC
P.S. I used defaults everywhere apart from modprobe (did not tweak eth0 settings on host at all, and nothing on guest except disabling those checksum offloads as test)

Comment 8 Mike Cao 2014-01-08 14:21:43 UTC
(In reply to Marcin Krol from comment #4)
> @Mike Cao: have you tried using the virtio eth card BEFORE disabling TCP/UDP
> Checksum Offload?

Yes . Pls tell me which operation system/kernel do you use for testing 

Mike
> 
> AFTER disabling checksum offloads the card works, yes, but not with checksum
> offload functions enabled. That's what I'm reporting.
> 
> @Ronen Hod: I do not ask for support here, after all I was able to make the
> virtio eth card work. Just wanted to let you know there might be a problem.

Comment 11 Yvugenfi@redhat.com 2014-01-08 15:10:44 UTC
(In reply to Marcin Krol from comment #6)
>     % ethtool -k eth0

Marcin, what about tap device that is created as a backend for virtio-net?

Check the list of devices with ifconfig, you should see it.

Thanks,
Yan.

Comment 12 Marcin Krol 2014-01-08 16:19:10 UTC
Hello,

The host OS is actually Debian 7.2 x64:

    % uname -a
    Linux irys 3.2.0-4-amd64 #1 SMP Debian 3.2.51-1 x86_64 GNU/Linux

However, since Intel IGB driver gave me some trouble (e.g. network link state autodetection works erratically) in connection to RH's virtio eth drivers, I posted the bug rep here.

@Yan: I presume that TAP device for that bridge is what virt-manager displays on guest hw page? (I have "Host device vnet13 (Bridge 'br0')"):

    21: vnet13: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UNKNOWN qlen 500
        link/ether fe:54:00:68:4d:b9 brd ff:ff:ff:ff:ff:ff
        inet6 fe80::fc54:ff:fe68:4db9/64 scope link


ethtool info for it:

    % ethtool -k vnet13
    Features for vnet13:
    rx-checksumming: off [fixed]
    tx-checksumming: off
            tx-checksum-ipv4: off [fixed]
            tx-checksum-unneeded: off [fixed]
            tx-checksum-ip-generic: off [requested on]
            tx-checksum-ipv6: off [fixed]
            tx-checksum-fcoe-crc: off [fixed]
            tx-checksum-sctp: off [fixed]
    scatter-gather: off
            tx-scatter-gather: off [requested on]
            tx-scatter-gather-fraglist: on
    tcp-segmentation-offload: off
            tx-tcp-segmentation: off [requested on]
            tx-tcp-ecn-segmentation: off [requested on]
            tx-tcp6-segmentation: off [requested on]
    udp-fragmentation-offload: off [requested on]
    generic-segmentation-offload: off [requested on]
    generic-receive-offload: on
    large-receive-offload: off [fixed]
    rx-vlan-offload: off [fixed]
    tx-vlan-offload: off [fixed]
    ntuple-filters: off [fixed]
    receive-hashing: off [fixed]
    highdma: off [fixed]
    rx-vlan-filter: off [fixed]
    vlan-challenged: off [fixed]
    tx-lockless: off [fixed]
    netns-local: off [fixed]
    tx-gso-robust: off [fixed]
    tx-fcoe-segmentation: off [fixed]
    fcoe-mtu: off [fixed]
    tx-nocache-copy: on
    loopback: off [fixed]

Comment 14 Ronen Hod 2014-01-09 13:22:57 UTC
I am closing this bug as it does not reproduce on RHEL hosts.
Feel free to continue the communication here.

Regards, Ronen.


Note You need to log in before you can comment on or make changes to this bug.