Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

For bugs related to Red Hat Enterprise Linux 5 product line. The current stable release is 5.10. For Red Hat Enterprise Linux 6 and above, please visit Red Hat JIRA https://issues.redhat.com/secure/CreateIssue!default.jspa?pid=12332745 to report new issues.

Bug 615174

Summary:	Received data corrupts when non standards L3 protocols are used on ixgbe
Product:	Red Hat Enterprise Linux 5	Reporter:	wmg <wezhang>
Component:	kernel	Assignee:	Andy Gospodarek <agospoda>
Status:	CLOSED DUPLICATE	QA Contact:	Network QE <network-qe>
Severity:	high	Docs Contact:
Priority:	urgent
Version:	5.4.z	CC:	dhoward, jpirko, jwest, jwilson, lwang, peterm, plyons, tao
Target Milestone:	rc
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2010-07-26 14:49:33 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description wmg 2010-07-16 04:27:49 UTC

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 16:15:36 UTC

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>
Date:   Thu May 7 10:39:35 2009 +0000

    ixgbe: Enable L2 header split in 82599

Comment 2 wmg 2010-07-19 02:22:16 UTC

(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>
> 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 Program Management 2010-07-21 18:00:27 UTC

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.