[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: growisofs TOSHIBA SD-R5002 problem



Summary for public reference.

japie:~$ growisofs -Z /dev/dvd -R -J -use-the-force-luke=dao
/mnt/lfs/home/japie/tmp/Test/
Executing 'mkisofs -R -J /mnt/lfs/home/japie/tmp/Test/ | builtin_dd
of=/dev/dvd obs=32k seek=0'
/dev/dvd: engaging DVD-R DAO upon user request...
/dev/dvd: reserving 1432352 blocks
/dev/dvd: "Current Write Speed" is 1.0x1385KBps.
:-[ WRITE@LBA=0h failed with SK=3h/ASC=0Ch/ACQ=00h]: Input/output error
:-( write failed: Input/output error

In the course of trouble-shooting it became apparent that only DAO recordings are affected, but not any other recording mode. By default DAO mode is/has to be engagend with minimally blanked DVD-RW media only. The thing about DAO mode is that first write command takes extra long time, because unit has to record lead-in prior the first data sector. Now the catch is that unit in question takes extra-ordinary time of 75 seconds [if compared with other units] to fulfill the first write request nor does it implement "LONG WRITE IN PROGRESS" code. And the trouble is even though growisofs passes longer time-out values down to kernel, 2.4 series kernels ignore these values and unconditionally use default one of 30 seconds. This kernel deficiency is the actual cause for the failure. If unit was able to filfull the first write in less than 30 seconds [or implemented "LONG WRITE IN PROGRESS" code], then failure wouldn't have emerged. Question is what to do. Several options:

1. I can simply choose to avoid DAO with unit in question. In DVD-R case it's more than enough to abstain from -use-the-force-luke=dao. As for DVD-RW, I'd actually recommend to format media for Restricted Overwrite with dvd+rw-format -force and forget all about blanking and DAO.

2. Fix your 2.4 kernel. One can work around the problem with simple increasing default time-out value, it's #define IOCTL_TIMEOUT 30*HZ line in drivers/scsi/sr_ioctl.c. Alternative is to apply DVD+RW or packet-writing kernel patches, which both fix the problem.

3. Upgrade kernel to 2.6 [naturally avoiding 2.6.8].

A.



Reply to: