Bug 822072

Created attachment 584913 [details]
strace info of ethtool

Hi Yunping,

Please make sure that it works well for RHEL6.3.

Thanks, Ronen.

Yunping, 

Can you help to check if libvirt created VM works?
If it works, then autotest bridge/tap setup exists problem.

when i run it using rhel6 host and 5.8 guest ,it ok

(In reply to comment #4)
> when i run it using rhel6 host and 5.8 guest ,it ok

What's the result of using libvirt & 5.8 guest & 5.8 host?

This request was evaluated by Red Hat Product Management for inclusion
in a Red Hat Enterprise Linux release.  Product Management has
requested further review of this request by Red Hat Engineering, for
potential inclusion in a Red Hat Enterprise Linux release for currently
deployed products.  This request is not yet committed for inclusion in
a release.

the result of using libvirt & 5.8 guest & 5.8 host: PASS

[root@localhost ~]# ps aux | grep qemu
root     16997 49.1  4.6 2331568 371964 ?      Sl   13:58   0:48 /usr/libexec/qemu-kvm -S -M rhel5.4.0 -m 2048 -smp 4,sockets=4,cores=1,threads=1 -name linux -uuid ed92d913-e1ab-ad93-5ce3-e84596bf5fad -monitor unix:/var/lib/libvirt/qemu/linux.monitor,server,nowait -no-kvm-pit-reinjection -no-reboot -boot nc -drive file=/var/lib/libvirt/images/linux-1.img,if=virtio,boot=on,format=raw,cache=none -net nic,macaddr=54:52:00:30:6f:77,vlan=0,model=virtio -net tap,fd=21,vlan=0 -serial pty -parallel none -usb -vnc 127.0.0.1:0 -k en-us -vga cirrus -balloon virtio

[root@localhost ~]# brctl show
bridge name	bridge id		STP enabled	interfaces
switch		8000.d4bed98eb973	no		vnet0
							eth0
virbr0		8000.000000000000	yes		

 Test Result:
[root@localhost ~]# ethtool  -k eth0
Offload parameters for eth0:
Cannot get device udp large send offload settings: Operation not supported
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp segmentation offload: on
udp fragmentation offload: off
generic segmentation offload: off
generic-receive-offload: off
[root@localhost ~]# ethtool  -K eth0 tx off
[root@localhost ~]# ethtool  -k eth0
Offload parameters for eth0:
Cannot get device udp large send offload settings: Operation not supported
rx-checksumming: on
tx-checksumming: off
scatter-gather: off
tcp segmentation offload: off
udp fragmentation offload: off
generic segmentation offload: off
generic-receive-offload: off
[root@localhost ~]# ethtool  -K eth0 tx on
[root@localhost ~]# ethtool  -k eth0
Offload parameters for eth0:
Cannot get device udp large send offload settings: Operation not supported
rx-checksumming: on
tx-checksumming: on
scatter-gather: off
tcp segmentation offload: off
udp fragmentation offload: off
generic segmentation offload: off
generic-receive-offload: off

host using 5.8 ,guest using 6.2,6.3 and 5.8 all of the guest os have this problem.

Autotest setup tap device by fcntl.ioctl()

In 5.8 host, an exception will be raised:
   OverflowError: signed integer is greater than maximum

https://github.com/autotest/autotest/blob/43118bf82af9d6bf5927e77472607af5e0d1302f/client/virt/virt_utils.py

def vnet_hdr_probe(tapfd):
    """
    Check if the IFF_VNET_HDR is support by tun.

    @param tapfd: the file descriptor of /dev/net/tun
    """
    u = struct.pack("I", 0)
    try:
        r = fcntl.ioctl(tapfd, TUNGETFEATURES, u)

^^^^ problem exists here (only in python-2.4.3-46.el5)

    except OverflowError:
        return False
    flags = struct.unpack("I", r)[0]
    if flags & IFF_VNET_HDR:
        return True
    else:
        return False

It seems a bug of python, after upgrading the python in host 5.8 to Python-2.6.6, problem could not be reproduced.

   77  wget http://..../Python-2.6.6.tar.bz2
   78  tar xjf Python-2.6.6.tar.bz2
   79  ./configure --prefix=/usr/local --exec-prefix=/usr/local
   81  cd Python-2.6.6
   82  ./configure --prefix=/usr/local --exec-prefix=/usr/local
   84  make -j 10
   85  make install
   86  ln -sf /usr/local/bin/python /usr/bin/python


So change the Component to 'python'.

This request was evaluated by Red Hat Product Management for inclusion
in a Red Hat Enterprise Linux release.  Product Management has
requested further review of this request by Red Hat Engineering, for
potential inclusion in a Red Hat Enterprise Linux release for currently
deployed products.  This request is not yet committed for inclusion in
a release.

fcnt.ioctl is implemented in Python-2.4.3/Modules/fcntlmodule.c: fcntl_ioctl

The exception OverflowError: "signed integer is greater than maximum" comes from Python-2.4.3/Python/getargs.c:convertsimple when handling the "i" format code within PyArg_ParseTuple, presumably within
    PyArg_ParseTuple(args, "O&iw#|i:ioctl",
within fcnt_ioctl.

This exception occurs when the object being parsed in for the code is to be coerced to a C "int".  It is initially successfully coerced to a C long, but it is a larger integer value than C's INT_MAX and thus can't be stored into a C "int".

This is TUNGETFEATURES, which I see is initialized in https://github.com/autotest/autotest/blob/43118bf82af9d6bf5927e77472607af5e0d1302f/client/virt/virt_utils.py like this:
if ARCH == "ppc64":
    # From linux/include/linux/if_tun.h
    TUNGETFEATURES = 0x400454cf
else:
    # From linux/include/linux/if_tun.h
    TUNGETFEATURES = 0x800454cf

What I believe is happening is that the "else" clause has been run, and that TUNGETFEATURES is 0x800454cf, which is too large to fit in a C int on this platform, leading to the exception.

Looking at "man ioctl", I see that ioctl *does* expect a C "int" as the request code, whereas /usr/include/sys/ioctl.h says that it's a "unsigned long int".

fcntl_ioctl  was changed to use the "I" parsing code, which treats it as an "unsigned int" (before casting back to "int"), in these commits:
  http://hg.python.org/cpython/rev/7099f6e68183
  http://hg.python.org/cpython/rev/1774fe7ec0c7
This was:
  http://bugs.python.org/issue1231069

Subsequently http://bugs.python.org/issue1471 changed Python 2.5 onwards to use a C "unsigned int" for the ioctl request code.

Hence Python 2.6 works for ioctl codes >= 0x80000000, whereas our Python 2.4.3 doesn't on 32-bit archs.

(In reply to comment #12)
> Subsequently http://bugs.python.org/issue1471 changed Python 2.5 onwards to
> use a C "unsigned int" for the ioctl request code.
Note to self: this latter commit was http://hg.python.org/cpython/rev/1c24a09acb97

Amos, Yunpin:

I see Amos has sent a patch that adds a debug statement to capture and log when that problem happens. It is OK, I guess we could alternatively catch the overflow, verify the currently running python version and if it's 2.4, then just return True, logging that a workaround had to be applied due to a bug in that python implementation.

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.

http://rhn.redhat.com/errata/RHBA-2013-0045.html