Hi, Sorry to send the patch here because my ISP does not allow me to send email to bug report.
This patch is similar to bug #323602, but fix another problem. It may solved the problem raised at the end of message of http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=323602 which is: ,----- | The important one however is the CLOSE SESSION failed one, which looks | identical to this bug reportee's problem. Perhaps the patch hasn't been | applied or something? `----- The patch comes from RISKO Gergely's message: http://article.gmane.org/gmane.comp.audio.cd-record/4805 which I believe that the solution is the same as bug #323602, but at different a place. Here is the full description of the symptom: ,----- | I got the same problem as Felix and Gadi had in January, but it | irritated me enough to solve it. (quick hack only) | | The problem was (just to remember) with different Pioneer drives, my | drive is a DVR-109 with firmware version 1.40 (the newest one, but the | problem was occurred with previous versions too). When I write a | Philips 8x DVD+R disk with quite a lot data (my experiences shows, | that a test amount (say <1G) is not enough to reproduce the bug), the | write finishes OK, but when growisofs wants to close the disk, I got: | | /dev/hdc: flushing cache | /dev/hdc: closing track | /dev/hdc: closing disc | :-[ CLOSE SESSION failed with SK=2h/ASC=04h/ACQ=07h]: Resource temporarily unavailable | /dev/hdc: reloading tray | | and after this termination, the disk left in an unmountable state | (linux says, that media not found): | [...] | | When I searched the specification for the meaning of | SK=2h/ASC=04h/ACQ=07h, I found, that it means something like 'drive | not ready', but not an error, just a query from the drive to wait a | minute and try again. `----- Why I'm redoing this, since there is a solution already? - The fix is not officially included yet, as of 2005.12.19. http://packages.debian.org/changelogs/pool/main/d/dvd+rw-tools/dvd%2brw-tools_5.21.4.10.8-4/changelog - I was not able to apply the RISKO's patch, but have to do it manually. - Mine use more "native" solution, ie, poll, instead of usleep. - The wait time is carefully calculated, only about 1/5 of RISKO's patch. - The compile code from my source is shorter. Here it is: diff -wu growisofs_mmc.cpp.org growisofs_mmc.cpp --- growisofs_mmc.cpp.org 2005-12-19 16:13:38.000000000 -0500 +++ growisofs_mmc.cpp 2005-12-19 16:30:51.000000000 -0500 @@ -1484,8 +1484,17 @@ cmd[1] = 0x01; // "IMMED" cmd[2] = mode; // "Close session" cmd[9] = 0; - if ((err=cmd.transport())) + + // it seems, that pioneer is a bit crappy + while (err=cmd.transport()) { + if (err == 0x20407) { + sperror ("CLOSE SESSION (but try to continue)",err); + poll (NULL,0,1400); + } else { sperror ("CLOSE SESSION",err); + break; + } + } if (wait_for_unit (cmd)) break; Why poll:1400? I first tried with poll 333, and the message showed up 7 times. So 1400 is just enough for the message to show up only once. FYI, major part of RISKO's patch (so as bug #323602) + if (SK(err)==0x2 && ASC(err)==0x04 && ASCQ(err)==0x07) { + sperror ("CLOSE SESSION (but try to continue)",err); + usleep(10000); PS. I hope the fix for bug #323602 can be changed to above 'err == 0x20407' and the 'poll' method as well. thanks Antonio Tong Sun -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
