Regarding drivers/ide/ide-cd.c in 2.5.72

Andy Polyakov (appro@fy.chalmers.se)
Tue, 17 Jun 2003 23:54:54 +0200


Hi,

I have brought this issue once already in 2.5.70 context (see uppermost
post in http://marc.theaimsgroup.com/?t=105410790500005&r=1&w=2), but it
apparently slipped through. So I've decided to bring it up again, this
time describing [hopefully] better how does this *generic* problem with
ide-cd.c manifests itself. In the nutshell the problem is that [as it is
now] every failed SG_IO request is replayed second time without data
transfer. E.g. if WRITE(10) SCSI command fails with sense code X, ide-cd
immediately resends the command block descriptor one more time, this time
without programming for any associated I/O payload, which [normally]
results in *different* sense code. And the catch is that user-land gets
this second sense code instead of the real/original one. Suggested patch
overcomes this problem by immediately purging the failed SG_IO request
from the request queue.

P.S. Non-essential "rant." One can wonder how come the originally
discussed patch, the one which made to 2.5.71, was sufficient for DVD+RW
units, but not DVD-RW. Are commands sent to DVD-RW unit so to say bound
to fail? In a sense yes! Majority of DVD-RW units terminate WRITE
requests with "LONG WRITE IN PROGRESS" sense code wherever internal
buffer gets full. The idea behind this LUN behaviour is to minimize
IDE-bus monopolization periods. The sense code is commonly treated as
"estimate how long does it take to purge say 1/2 of internal buffer,
hibernate for that while and retry the failed WRITE command." Needless
to say that if original sense code is effectively discarded and replaced
by another code [apparently by "INVALID ADDRESS FOR WRITE"], it makes it
impossible to treat this essentially *non-error* condition appropriately
For whatever reason DVD+RW units don't terminate WRITE requests in same
manner and IDE-bus remains monopilized till there is buffer space
available to meet the outstanding WRITE request. Well, there're commands
which get replayed even in DVD+RW case, those are data-less commands,
most notably TEST UNIT READY, which are "safe" to replay.

Cheers. A.

8<--------8<--------8<--------8<--------8<--------8<--------8<--------
--- ./drivers/ide/ide-cd.c.orig Tue Jun 3 12:21:56 2003
+++ ./drivers/ide/ide-cd.c Thu Jun 5 22:26:56 2003
@@ -749,12 +749,17 @@
by transferring the semaphore from the packet
command request to the request sense request. */

+ rq->flags |= REQ_FAILED;
if ((stat & ERR_STAT) != 0) {
wait = rq->waiting;
rq->waiting = NULL;
+ if (rq->flags&REQ_BLOCK_PC) {
+ cdrom_queue_request_sense(drive, wait,
+ rq->sense, rq);
+ return 1; /* REQ_BLOCK_PC self-cares */
+ }
}

- rq->flags |= REQ_FAILED;
cdrom_end_request(drive, 0);

if ((stat & ERR_STAT) != 0)
@@ -1657,13 +1662,14 @@
dma = info->dma;
if (dma) {
info->dma = 0;
- if ((dma_error = HWIF(drive)->ide_dma_end(drive))) {
- printk("ide-cd: dma error\n");
- HWIF(drive)->ide_dma_off(drive);
- }
+ dma_error = HWIF(drive)->ide_dma_end(drive);
}

if (cdrom_decode_status(drive, 0, &stat)) {
+ if (stat&ERR_STAT)
+ { end_that_request_chunk(rq, 0, rq->data_len);
+ goto end_request; /* purge the whole thing... */
+ }
end_that_request_chunk(rq, 1, rq->data_len);
return ide_stopped;
}
@@ -1672,8 +1678,11 @@
* using dma, transfer is complete now
*/
if (dma) {
- if (dma_error)
+ if (dma_error) {
+ printk("ide-cd: dma error\n");
+ HWIF(drive)->ide_dma_off(drive);
return DRIVER(drive)->error(drive, "dma error", stat);
+ }

end_that_request_chunk(rq, 1, rq->data_len);
rq->data_len = 0;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/