Bug 615174 - Received data corrupts when non standards L3 protocols are used on ixgbe
Received data corrupts when non standards L3 protocols are used on ixgbe
Status: CLOSED DUPLICATE of bug 618275
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel (Show other bugs)
5.4.z
All Linux
urgent Severity high
: rc
: ---
Assigned To: Andy Gospodarek
Network QE
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-07-16 00:27 EDT by wmg
Modified: 2014-06-29 19:02 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-07-26 10:49:33 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description wmg 2010-07-16 00:27:49 EDT
Description of problem:

Received data corrupts when non standards L3 protocols are used on ixgbe
this been fixed on RHEL5.5 as resolved in bz516699
Now fujitsu want to propose this for 5.4.z

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



How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:
Received data corrupts when non standards L3 protocols are used on ixgbe.

In an ixgbe driver, the receive function is implemented in assumption that the header splitting option works always.

But regarding to the hardware specifications, we have to notice to the hardware for what kind of protocols the header splitting option works through the PSRTYPE register.

This is done in ixgbe_configure_rx (ixgbe_main.c) function.

The real flags written to the register are as follows.

  RHEL 5.4
  drivers/net/ixgbe/ixgbe_main.c

  1651                 if (hw->mac.type == ixgbe_mac_82599EB) {
  1652                         /* PSRTYPE must be initialized in 82599 */
  1653                         u32 psrtype = IXGBE_PSRTYPE_TCPHDR |
  1654                                       IXGBE_PSRTYPE_UDPHDR |
  1655                                       IXGBE_PSRTYPE_IPV4HDR |
  1656                                       IXGBE_PSRTYPE_IPV6HDR;
  1657                         IXGBE_WRITE_REG(hw, IXGBE_PSRTYPE(0), psrtype);
  1658                 }

 RHEL5.5

                        u32 psrtype = IXGBE_PSRTYPE_TCPHDR |
                                      IXGBE_PSRTYPE_UDPHDR |
                                      IXGBE_PSRTYPE_IPV4HDR |
                                      IXGBE_PSRTYPE_IPV6HDR |
                                      IXGBE_PSRTYPE_L2HDR;   

This missing result in the malfunction when the non-standard L3 protocol,
which we mean is not IPV4 or IPV6 , is processed.

Expected results:

RHEL5.4 kernel ixgbe should have IXGBE_PSRTYPE_L2HDR.
Additional info:
Comment 1 Andy Gospodarek 2010-07-16 12:15:36 EDT
Is a customer hitting this issue or was this simply discovered because this failed a test-case?

Can you describe the impact (does the box panic or is the frame just dropped) when this happens?

Can you attach a pcap of the invalid frame that causes this problem?

The upstream commit that makes the change you request is:

commit dfa12f05f60eb23b1670f3a7756ed814f886a7fb
Author: Yi Zou <yi.zou@intel.com>
Date:   Thu May 7 10:39:35 2009 +0000

    ixgbe: Enable L2 header split in 82599
Comment 2 wmg 2010-07-18 22:22:16 EDT
(In reply to comment #1)
> Is a customer hitting this issue or was this simply discovered because this
> failed a test-case?
This should failed in a test of Fujitsu internal tests

> 
> Can you describe the impact (does the box panic or is the frame just dropped)
> when this happens?
> 
> Can you attach a pcap of the invalid frame that causes this problem?
> 
I'm asking a pcap package from them

> The upstream commit that makes the change you request is:
> 
> commit dfa12f05f60eb23b1670f3a7756ed814f886a7fb
> Author: Yi Zou <yi.zou@intel.com>
> Date:   Thu May 7 10:39:35 2009 +0000
> 
>     ixgbe: Enable L2 header split in 82599    

How reproducible:
Always if conditions are met

Step to Reproduce:
- Receive data with non standard L3 protocol.
      (Ones other than ipv4/ipv6)
We've not yet understand what will happen totally.
It seems some data are processed well and the others are not.
It may depend on the length of a frame.
The longer, the worse.
Based on our attempt the frames whose length is shorter than about 256 ,
the size of sk_buff are processed well and the others , longer than that , are not.

Actual Results:
 Data corrupts
Expected Results:
Data are received correctly
Summary of actions taken to resolve issue:
none
Location of diagnostic data:
None
Hardware configuration:
- Model: PRIMEQUEST 1800E
- CPU Info: Intel Xeon E7540 * 2
- Memory Info: 16GB
- Other:
Business Impact:
 We think there are few users who adopt non standard L3 protocols.

 But we can't eliminate the unfortunate case completely.

If some big user who adopts RH5.4 already tries to introduce 10 GB NIC and use some kind of legacy protocol other than TCP/IP , we have to talk them into using RH5.5.

It may be possible, but sometimes not.
In bad case, we don't have any good alternative other than fix because this problem seems exactly missing of the very basic function for such kind of users.
It will harm their trust to us.

Many users use RH5.4 yet, we think the fix for this is crucial for preventing from would-be coming troubles.
Comment 6 RHEL Product and Program Management 2010-07-21 14:00:27 EDT
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.

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