Bug 678067

Summary: qeth: allow channel path changes in recovery
Product: Red Hat Enterprise Linux 6 Reporter: Joseph Kachuck <jkachuck>
Component: kernelAssignee: Hendrik Brueckner <brueckner>
Status: CLOSED ERRATA QA Contact: Red Hat Kernel QE team <kernel-qe>
Severity: high Docs Contact:
Priority: high    
Version: 6.0CC: arozansk, brueckner, cward, peterm, syeghiay
Target Milestone: rcKeywords: OtherQA
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: kernel-2.6.32-130.el6 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-05-19 12:14:27 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:
Bug Depends On:    
Bug Blocks: 684385    
Attachments:
Description Flags
linux-2.6.32-s390-qeth-chpath-change.patch none

Description Joseph Kachuck 2011-02-16 16:35:47 UTC 
Created attachment 479157 [details]
linux-2.6.32-s390-qeth-chpath-change.patch

linux-2.6.32-s390-qeth-chpath-change.patch

Description: qeth: allow channel path changes in suspend state
Symptom: qeth device does not recover successfully during resume
Problem: Channel path information is determined only when qeth
device is grouped. In order to recognize channel path
changes at resume time, channel path information has to
be re-determined during online setting.
One possible change is the number of OSA-supported TCP/IP
stacks determining the number of available outbound
queues. Switching them from 480 to 1920 while being
suspended results in failing recovery when resuming.
Solution: Determine channel path capabilities during online
setting of the device and reestablish outbound qdio
queues during recovery in case the number of
OSA-supported TCP/IP stacks has changed.

Server architecture(s): System z
Server type: s390x
General component: kernel
Other components involved: No

Does the server have the latest GA firmware?
Yes.

Has the problem been shown to occur on more than one system?
Yes.

Is a tested patch available?
Yes.

If yes to the above, has it been approved upstream?
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-
2.6.git;a=commitdiff;h=d0ff1f52361d714863c49abb721a8714ea4e76d6

What is the latest official Red Hat build on which this bug has been seen?
RHEL6


The patch has been tested, fixes the problem, and is part of the upstream
kernel.

With best regards,
Hendrik
Comment 2 Hendrik Brueckner 2011-03-07 10:15:10 UTC 
The patch has been posted to rhkernel by Hendrik Brueckner <brueckner>
Comment 3 RHEL Program Management 2011-03-07 15:21:20 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.
Comment 4 IBM Bug Proxy 2011-03-26 17:34:34 UTC 
------- Comment From brueckner.ibm.com 2011-02-16 12:00 EDT-------
(In reply to comment #6)
> I have sent this up for engineering to review.

Please let me know the RHBZ.

Thanks.
Comment 5 Aristeu Rozanski 2011-04-07 14:14:09 UTC 
Patch(es) available on kernel-2.6.32-130.el6
Comment 8 Chris Ward 2011-05-06 11:41:00 UTC 
@IBM, test results?
Comment 9 errata-xmlrpc 2011-05-19 12:14:27 UTC 
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-2011-0542.html