Bug 567718

I was under the impression Emulex was done submitting items for RHEL 5.5 since we are so late in the development cycle. The only way I can get any of these patches in at this point if this causes a crash, hang, or other debilitating issue.

Laurie, can you comment?

Andrius,

Laurie is out today and I will comment on her behalf. Two of these are crtical :

07793d33b4fba00f5bd1dac78fa038bb0e23fa5c 
           be2net: set proper value to version field in req hdr
c0ad98453f23b98f73a1f1be2a75303a6c0dee4c 
           be2net: bug fix in be_read_eeprom

The first one can cause a crash / freeze and the second one is a critical fix required for an OEM.  They change just one line each and there is little risk.  We will submit a new patch for just these two changes.

Thanks.

Subbu

Created attachment 396057 [details]
Two critical fixes submitted to upstream recently


This patch fixes there two critical bugs :

07793d33b4fba00f5bd1dac78fa038bb0e23fa5c 
           be2net: set proper value to version field in req hdr
c0ad98453f23b98f73a1f1be2a75303a6c0dee4c 
           be2net: bug fix in be_read_eeprom

(In reply to comment #3)
> Andrius,
> 
> Laurie is out today and I will comment on her behalf. Two of these are crtical
> :
> 
> 07793d33b4fba00f5bd1dac78fa038bb0e23fa5c 
>            be2net: set proper value to version field in req hdr
> c0ad98453f23b98f73a1f1be2a75303a6c0dee4c 
>            be2net: bug fix in be_read_eeprom
> 
> The first one can cause a crash / freeze and the second one is a critical fix
> required for an OEM.  They change just one line each and there is little risk. 
> We will submit a new patch for just these two changes.
> 
> Thanks.
> 
> Subbu    

Subhu, can you explain how not having the first patch can cause a crash?

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.

Andy,

For compatibility, the firmware looks at the version number in the request to determine what response structure is the driver using.  Since be2net is  using the structure for the older generation of the ASIC, we should set it to 0 explicitly.  If it has 1, f/w will DMA extended response information that requires a larger response buffer.  This will cause corruption of memory not allocated by the driver and bad things could follow.

Thanks.

Subbu

Subbu, thanks for the explanation.  That is extremely helpful.

The commit c0ad98453f23b98f73a1f1be2a75303a6c0dee4c is already present in RHEL5.5. I included it in my previous submission. So I'm going to submit only the first commit regarding version in the request header.

in kernel-2.6.18-191.el5
You can download this test kernel from http://people.redhat.com/jwilson/el5

Please update the appropriate value in the Verified field
(cf_verified) to indicate this fix has been successfully
verified. Include a comment with verification details.

@Subbu, 

Please update this bugzilla with test results as soon as possible. Thank you. Latest kernel for testing is available here: 

http://people.redhat.com/jwilson/el5

Test results on be2net driver:

1. Driver version - 2.102.115r
2. Firmware flash is susccesful - "echo be3flash.ufi" is used with 
timeout period as 60
3. Driver unload and reload is passed.
4. Bonding - Passes (All modes)
5. VLAN with Jumbo - Pass (Tested on be2)

Additionally specific tests for the two problems addressed by this specific bug also passed.

Subbu

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2010-0178.html