aboutsummaryrefslogtreecommitdiffstats
path: root/drivers
diff options
context:
space:
mode:
authorFrank Pavlic <fpavlic@de.ibm.com>2007-07-17 07:36:04 -0400
committerMartin Schwidefsky <schwidefsky@de.ibm.com>2007-07-17 07:36:18 -0400
commit6cbed91ab78e750eef2dacb75bd51bd63792fd07 (patch)
treeb7fae0e398d677e1b1e155c758a5af82387c17c1 /drivers
parent92d154b6c54f76016d36a7eb4aab6eea27737fdb (diff)
[S390] qdio: output queue stall on FCP and network devices
When running QIOASSIST enabled qdio devices in a z/VM environment the output queue for such devices stall in heavy workload situations. When SQBS and EQBS instructions returns CCQ=96 qdio does not reissue the instruction again with the register settings done by millicode but processed the returned qdio buffer. This is wrong. qdio has to reissue the instruction once again on CCQ=96, as we already do it for CCQ=97. Signed-off-by: Frank Pavlic <fpavlic@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Diffstat (limited to 'drivers')
-rw-r--r--drivers/s390/cio/qdio.c4
1 files changed, 2 insertions, 2 deletions
diff --git a/drivers/s390/cio/qdio.c b/drivers/s390/cio/qdio.c
index e70aeb7a3781..ae437322c9ca 100644
--- a/drivers/s390/cio/qdio.c
+++ b/drivers/s390/cio/qdio.c
@@ -166,9 +166,9 @@ qdio_check_ccq(struct qdio_q *q, unsigned int ccq)
166{ 166{
167 char dbf_text[15]; 167 char dbf_text[15];
168 168
169 if (ccq == 0 || ccq == 32 || ccq == 96) 169 if (ccq == 0 || ccq == 32)
170 return 0; 170 return 0;
171 if (ccq == 97) 171 if (ccq == 96 || ccq == 97)
172 return 1; 172 return 1;
173 /*notify devices immediately*/ 173 /*notify devices immediately*/
174 sprintf(dbf_text,"%d", ccq); 174 sprintf(dbf_text,"%d", ccq);