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

From: Andy Polyakov (
Date: Tue Jun 17 2003 - 16:54:54 EST


I have brought this issue once already in 2.5.70 context (see uppermost
post in, 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.

--- ./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
More majordomo info at
Please read the FAQ at

This archive was generated by hypermail 2b29 : Mon Jun 23 2003 - 22:00:22 EST