Bug 678073

Summary: qeth: allow channel path changes in recovery
Product: Red Hat Enterprise Linux 5 Reporter: Joseph Kachuck <jkachuck>
Component: kernelAssignee: Hendrik Brueckner <brueckner>
Status: CLOSED ERRATA QA Contact: Chao Yang <chyang>
Severity: high Docs Contact:
Priority: high    
Version: 5.6CC: brueckner, cward, peterm, qcai
Target Milestone: rcKeywords: OtherQA
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-07-21 09:31:35 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: 684940    
Attachments:
Description Flags
linux-2.6.18-s390-qeth-chpath-change.patch none

Description Joseph Kachuck 2011-02-16 16:48:22 UTC 
Created attachment 479162 [details]
linux-2.6.18-s390-qeth-chpath-change.patch

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

Description: qeth: allow channel path changes in recovery
Symptom: qeth device does not recover successfully
Problem: Channel path information is determined only when qeth
device is grouped. In order to recognize channel path
changes during recovery, 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 results in failing
recovery.
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?
RHEL 5.6


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

With best regards,
Hendrik
Comment 1 Hendrik Brueckner 2011-03-07 10:23:06 UTC 
The patch has been posted to rhkernel by Hendrik Brueckner <brueckner>
Comment 2 RHEL Program Management 2011-03-07 15:20:26 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:09 UTC 
------- Comment From brueckner.ibm.com 2011-02-16 11:59 EDT-------
(In reply to comment #6)
> I have sent this up for engineering to review.

Please let me know the RHBZ.

Thanks.
Comment 5 Jarod Wilson 2011-03-28 18:38:22 UTC 
Patch(es) available in kernel-2.6.18-252.el5
You can download this test kernel (or newer) from http://people.redhat.com/jwilson/el5
Detailed testing feedback is always welcomed.
Comment 8 errata-xmlrpc 2011-07-21 09:31:35 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-1065.html