>From: [EMAIL PROTECTED]
>I have switched from cdrtools-1.10a11 to cdrtools-1.10a13
>but I believe that the decisive hint came from Thomas
>who suggested to try TAO mode instead of DAO mode.
If you do this you will have no chance to fix your problem...
>Yes, it is. With more than 30 years experience with computers of
>several kinds, teaching C++ and having no problems with assembler,
>having written device drivers myself,
>I wouldn't call myself a newbee. Nevertheless I haven't been able
>to get cdrecord running. (Yes, I could have studied the sources)
Mmmm this statement does not match your statements below.
>> ATAPI is SCSI over IDE transport. You only need to
>> have one SCSI CD-ROm driver and a SCSI hostadaptor driver
>> for the IDE interface. The argument that I mostly hear:
>> "why do nwe need a full blown SCSI subsystem for a IDE only
>> machine" goes away if you use loadable kernel modules.
>I don't know the details, but I wonder why one couldn't use
>the standard IDE driver and do all the other stuff by
>suitable ioctl calls. If necessary one could try to
>have the IDE driver support additional ioctl functions.
Did you ever read README.ATAPI ?
There is no single IDE cd burner. You need SCSI commands to write CD's.
>>>Waiting for reader process to fill input buffer ...
>>>cdrecord: Input/output error. mode select g1: scsi sendcmd: retryable error
>>>CDB: 55 10 00 00 00 00 00 00 3C 00
>>>status: 0x0 (GOOD STATUS)
>>
>> Well for this error there are several possible reasons.
>>
>> - Let me use this first so you can"t tell me again that I am against
>> Linux (in fact I run Linux on my notebook).
>>
>> There may be HW or cabling problems.
>This was unlikely since the drives works just fine with Windows
So I would guess that you have no experiences with computers.
The bad thing with cable problems is that once you have them, there
is no guarantee for a failure. Small timing problems (caused
by the drivers od an OS) may change a lot.
>> - a bug in the SCSI subsystem of the kernel
>>
>> - binary incompatibility of cdrecord with the kernel.
>Most unlikely since I compiled from the source without any
>significant warnings
So It is most likely a bug in the kernel that caused an in principle
impossible error message.
>>>cmd finished after 0.007s timeout 200s
>>>cdrecord: Warning: using default CD write parameter data.
>>>Mode Select Data 00 11 00 00 05 32 02 00 00 00 00 00 00 00 00 00 00 00 00 96 00 00
>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>00 00 00 00 00 00
>>
>> It looks that the mode page 05 that is send back by the drive is not correct.
>> So it may even be rotten firmware.
>>
>> As the write type is "packet" it may also be a defective media.
>Certainly it wasn't
I just again checked your messages ....
1) There is no block descriptor, so the firmware is most likely rotten
2) I was wrong: wryte type is 2 == SAO
... but it may be that the drive does not like dbtype to be set
to DB_RAW as cdrecord does just to set up the new session
(will be corrected later in open track...).
In any case: status: 0x0 (GOOD STATUS)
flags most likely a bug in the kernel that needs to be fixed first.
J�rg
EMail:[EMAIL PROTECTED] (home) J�rg Schilling D-13353 Berlin
[EMAIL PROTECTED] (uni) If you don't have iso-8859-1
[EMAIL PROTECTED] (work) chars I am J"org Schilling
URL: http://www.fokus.gmd.de/usr/schilling ftp://ftp.fokus.gmd.de/pub/unix
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
