Bug 466127 - dasd: fix loop in request expiration handling
dasd: fix loop in request expiration handling
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel (Show other bugs)
s390x All
high Severity high
: rc
: ---
Assigned To: Hans-Joachim Picht
Martin Jenner
Depends On:
  Show dependency treegraph
Reported: 2008-10-08 11:47 EDT by IBM Bug Proxy
Modified: 2014-07-24 23:37 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-05-18 15:17:46 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
linux-2.6.9-s390-dasd_fix_loop_in_request_expiration.patch (787 bytes, text/plain)
2008-10-08 11:47 EDT, IBM Bug Proxy
no flags Details

  None (edit)
Description IBM Bug Proxy 2008-10-08 11:47:21 EDT
=Comment: #0=================================================
Hans Joachim Picht <hans@linux.vnet.ibm.com> - 


Description: dasd: fix loop in request expiration handling
Symptom:     I/O on a DASD is blocked and message log shows a lot
             of messages that say 'termination failed, retrying in 5s'
             but the message repeats several times a second and not
             just every 5 seconds.
Problem:     The first thing we do in the dasd device tasklet is to
             check for expired requests. When a expired cqr is found,
             we try to terminate that request so that we can give it
             a fresh start. If this termination fails, we want to
             wait for 5 seconds and do the same check/termination
             We setup a timer, which will schedule the tasklet in 5
             seconds. Unfortunately the termination function itself
             schedules the tasklet as well, so the tasklet will be
             executed again right after it finished and will find the
             expired cqr. If the termination failed due to a hardware
             problem it will probably fail again, and we are stuck
             in a loop until the hardware allows termination again.
Solution:    The schedule in the termination function may be needed
             in other contexts, so if we want to give a request some
             more time, we need to add this time to it's 'expires'

Contact Information = stefan.haberland@de.ibm.com
=Comment: #2=================================================
Hans Joachim Picht <hans@linux.vnet.ibm.com> - 
The patch has been tested, fixed the problem and is upstream:
Comment 1 IBM Bug Proxy 2008-10-08 11:47:26 EDT
Created attachment 319760 [details]
Comment 2 Hans-Joachim Picht 2008-10-22 06:16:42 EDT
The patch has been posted to rhkernel on Oct 22 by Hans-Joachim Picht
Comment 3 IBM Bug Proxy 2008-10-22 09:11:04 EDT
Hello Red Hat:
I increase severity from normal to "high"
That is to reflect  the changed severity assessment at IBM that occurred
during fix development and test.

This fix should be included into RHEL4.8.
Comment 4 IBM Bug Proxy 2008-10-23 08:10:58 EDT
Hello Red Hat:
As discussed yesterday here the business justification for this fix
to make RHEL4.8:

If the system runs into this error
it is caught in a loop that floods the message log with errors.
The System will not respond for an indefinite time.
Comment 5 IBM Bug Proxy 2008-10-29 08:40:43 EDT
Hello Red Hat,
There is  RIT  232885 created for this LTC BZ
Please ensure the RIT is linked to RH BZ 466127.
Comment 6 RHEL Product and Program Management 2008-10-30 14:28:06 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
Comment 7 Vivek Goyal 2008-11-05 08:58:10 EST
Committed in 78.17.EL . RPMS are available at http://people.redhat.com/vgoyal/rhel4/
Comment 8 IBM Bug Proxy 2008-12-15 06:40:50 EST
*** Bug 50127 has been marked as a duplicate of this bug. ***
Comment 10 IBM Bug Proxy 2009-03-19 05:53:42 EDT
------- Comment From mgrf@de.ibm.com 2009-03-19 05:42 EDT-------
This is verified OK on RHEL 4.8 beta1 on System z .
Closing on IBM site , Thx
Comment 12 Chris Ward 2009-03-27 10:20:15 EDT
~~ Attention Partners! Snap 1 Released ~~
RHEL 4.8 Snapshot 1 has been released on partners.redhat.com. There should
be a fix present, which addresses this bug. NOTE: there is only a short time
left to test, please test and report back results on this bug
at your earliest convenience.

If you encounter any issues, please set the bug back to the ASSIGNED state and
describe the issues you encountered. If you have found a NEW bug, clone this
bug and describe the issues you encountered. Further questions can be
directed to your Red Hat Partner Manager.

If you have VERIFIED the bug fix. Please select your PartnerID from the
Verified field above. Please leave a comment with your test results details.
Include which arches tested, package version and any applicable logs.

 - Red Hat QE Partner Management
Comment 14 errata-xmlrpc 2009-05-18 15:17:46 EDT
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.


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