AcoSail/kernel_optimize_test
8
0
Fork 0
forked from luck/tmp_suning_uos_patched
Code Pull Requests Activity

[PATCH] s390: tape retry flooding by deferred CC in interrupt

Browse Source 
If a deferred CC happens there will be lots of messages, because the retry is
done immediatly in the interrupt handler which can be too fast.  To avoid this
requeue the request and schedule the queue to be processed.

Signed-off-by: Stefan Bader <shbader@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This commit is contained in:
Stefan Bader 2006-03-24 03:15:26 -08:00 committed by Linus Torvalds
parent 20c644680a
commit 842d3fba94
1 changed files with 5 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
drivers/s390/char/tape_core.c
View File

@ -1064,15 +1064,16 @@ __tape_do_irq (struct ccw_device *cdev, unsigned long intparm, struct irb *irb)
/*
* If the condition code is not zero and the start function bit is
* still set, this is an deferred error and the last start I/O did
* not succeed. Restart the request now.
* not succeed. At this point the condition that caused the deferred
* error might still apply. So we just schedule the request to be
* started later.
*/
if (irb->scsw.cc != 0 && (irb->scsw.fctl & SCSW_FCTL_START_FUNC)) {
PRINT_WARN("(%s): deferred cc=%i. restaring\n",
cdev->dev.bus_id,
irb->scsw.cc);
rc = __tape_start_io(device, request);
if (rc)
__tape_end_request(device, request, rc);
request->status = TAPE_REQUEST_QUEUED;
schedule_work(&device->tape_dnr);
return;
}