Hi Jens, Dne 20.6.2018 v 16:09 Jens Axboe napsal(a): > On 6/20/18 5:52 AM, Maurizio Lombardi wrote: >> Hi Jens, >> >> Dne 23.5.2018 v 16:42 Jens Axboe napsal(a): >>> On 5/23/18 3:19 AM, Maurizio Lombardi wrote: >>>> >>>> >>>> Dne 22.5.2018 v 16:47 Jens Axboe napsal(a): >>>>> It's been many years, but back in the day the program writing the cd >>>>> would eject the disc once done. This of course forces a reload of >>>>> the toc and clearing of the flag. What program is this? Seems like >>>>> it should probably eject when it's done. >>>> >>>> They are using wodim to burn the CDs on their servers. >>>> The problem is that they do not want the CD to be ejected because their >>>> drives >>>> lack a motorized tray, thus requiring manual intervention which they would >>>> like to avoid. >>> >>> I took a quick look at it, man that sr driver needs a bit of love :-) >>> >>> Anyway, I wonder if something like the below would work. Check for >>> a close track command in the sr completion handler, and flag the media >>> as changed if we see one. Totally untested... >>> >>> >>> diff --git a/drivers/scsi/sr.c b/drivers/scsi/sr.c >>> index 3f3cb72e0c0c..48f0d7a096db 100644 >>> --- a/drivers/scsi/sr.c >>> +++ b/drivers/scsi/sr.c >>> @@ -328,6 +328,9 @@ static int sr_done(struct scsi_cmnd *SCpnt) >>> scmd_printk(KERN_INFO, SCpnt, "done: %x\n", result); >>> #endif >>> >>> + if (SCpnt->cmnd[0] == GPCMD_CLOSE_TRACK) >>> + cd->device->changed = 1; >>> + >>> /* >>> * Handle MEDIUM ERRORs or VOLUME OVERFLOWs that indicate partial >>> * success. Since this is a relatively rare error condition, no >>> >> >> I just want to let you know that I tested the patch but unfortunately it >> doesn't work. >> I will try to find out what GPCMD_* commands are passed to sr_done() when >> burning a disc >> to see if there is another one which we could use. > > It's been a decade since I last messed with this or burned a cd-r, so that > would be appreciated. blktrace should be enough to tell you what commands > are being sent. >
You remember this patch? The problem was that after a cd burn operation completes, you can't mount the cd unless you eject it first. I finally carried out the test you suggested by using blktrace. This is what I see when a cd burn operation completes: 11,0 3 32 0.357166787 11653 D W 63488 (2a 00 00 03 3d 02 00 00 1f 00 ..) [wodim] 11,0 3 32 0.357166787 11653 D W 63488 (2a 00 00 03 3d 02 00 00 1f 00 ..) [wodim] 11,0 3 32 0.357166787 11653 D W 63488 (2a 00 00 03 3d 02 00 00 1f 00 ..) [wodim] 11,0 3 32 0.357166787 11653 D W 63488 (2a 00 00 03 3d 02 00 00 1f 00 ..) [wodim] 11,0 3 80 0.922358386 11653 D W 63488 (2a 00 00 03 3e 57 00 00 1f 00 ..) [wodim] 11,0 3 80 0.922358386 11653 D W 63488 (2a 00 00 03 3e 57 00 00 1f 00 ..) [wodim] 11,0 3 80 0.922358386 11653 D W 63488 (2a 00 00 03 3e 57 00 00 1f 00 ..) [wodim] 11,0 3 80 0.922358386 11653 D W 63488 (2a 00 00 03 3e 57 00 00 1f 00 ..) [wodim] 11,0 3 112 1.332351325 11653 D W 63488 (2a 00 00 03 3f 4f 00 00 1f 00 ..) [wodim] 11,0 3 112 1.332351325 11653 D W 63488 (2a 00 00 03 3f 4f 00 00 1f 00 ..) [wodim] 11,0 3 112 1.332351325 11653 D W 63488 (2a 00 00 03 3f 4f 00 00 1f 00 ..) [wodim] 11,0 3 112 1.332351325 11653 D W 63488 (2a 00 00 03 3f 4f 00 00 1f 00 ..) [wodim] 11,0 3 152 1.791786352 11653 D W 63488 (2a 00 00 03 40 66 00 00 1f 00 ..) [wodim] 11,0 3 152 1.791786352 11653 D W 63488 (2a 00 00 03 40 66 00 00 1f 00 ..) [wodim] 11,0 3 152 1.791786352 11653 D W 63488 (2a 00 00 03 40 66 00 00 1f 00 ..) [wodim] 11,0 3 152 1.791786352 11653 D W 63488 (2a 00 00 03 40 66 00 00 1f 00 ..) [wodim] 11,0 3 196 2.357046291 11653 D W 63488 (2a 00 00 03 41 bb 00 00 1f 00 ..) [wodim] 11,0 3 196 2.357046291 11653 D W 63488 (2a 00 00 03 41 bb 00 00 1f 00 ..) [wodim] 11,0 3 196 2.357046291 11653 D W 63488 (2a 00 00 03 41 bb 00 00 1f 00 ..) [wodim] 11,0 3 196 2.357046291 11653 D W 63488 (2a 00 00 03 41 bb 00 00 1f 00 ..) [wodim] 11,0 3 304 3.600032959 11653 D N 0 (35 00 ..) [wodim] 11,0 3 304 3.600032959 11653 D N 0 (35 00 ..) [wodim] 11,0 3 304 3.600032959 11653 D N 0 (35 00 ..) [wodim] 11,0 3 304 3.600032959 11653 D N 0 (35 00 ..) [wodim] 11,0 3 332 18.496219927 11653 D N 0 (35 00 ..) [wodim] 11,0 3 332 18.496219927 11653 D N 0 (35 00 ..) [wodim] 11,0 3 332 18.496219927 11653 D N 0 (35 00 ..) [wodim] 11,0 3 332 18.496219927 11653 D N 0 (35 00 ..) [wodim] 11,0 3 352 18.499114653 7433 D N 0 (00 ..) [kworker/3:2] 11,0 3 352 18.499114653 7433 D N 0 (00 ..) [kworker/3:2] 11,0 3 352 18.499114653 7433 D N 0 (00 ..) [kworker/3:2] 11,0 3 352 18.499114653 7433 D N 0 (00 ..) [kworker/3:2] 11,0 3 356 20.898947607 7433 D R 8 (4a 01 00 00 10 00 00 00 08 00 ..) [kworker/3:2] 11,0 3 356 20.898947607 7433 D R 8 (4a 01 00 00 10 00 00 00 08 00 ..) [kworker/3:2] 11,0 3 356 20.898947607 7433 D R 8 (4a 01 00 00 10 00 00 00 08 00 ..) [kworker/3:2] 11,0 3 356 20.898947607 7433 D R 8 (4a 01 00 00 10 00 00 00 08 00 ..) [kworker/3:2] You see a sequence of 0x2a commands (GPCMD_WRITE_10). Then the write operation finishes and sr receives the 0x35 command (GPCMD_FLUSH_CACHE) 0x4a is GPCMD_GET_EVENT_STATUS_NOTIFICATION. GPCMD_CLOSE_TRACK is not used, this explains why your patch didn't work. Do you think it's acceptable to mark the device as changed when GPCMD_FLUSH_CACHE is received? Thanks, Maurizio
