Adaptec 39160 / Yamaha CRW8424S CD burning

Adaptec 39160 / Yamaha CRW8424S CD burning

[William Lee Irwin III]

SCSI CD burning appears to fail, causing audio CD's burned with
bash-2.05# cdrecord -v -pad speed=1 dev=0,3,0 -audio `cat tracks`
(where the tracks are wav files) to have massive numbers of skips.

$ cat /proc/scsi/scsi 
Attached devices: 
Host: scsi0 Channel: 00 Id: 00 Lun: 00
  Vendor: WDIGTL   Model: WDE18310 ULTRA2  Rev: 1.30
  Type:   Direct-Access                    ANSI SCSI revision: 02
Host: scsi0 Channel: 00 Id: 03 Lun: 00
  Vendor: YAMAHA   Model: CRW8424S         Rev: 1.0j
  Type:   CD-ROM                           ANSI SCSI revision: 02
Host: scsi1 Channel: 00 Id: 06 Lun: 00
  Vendor: IBM      Model: DDYS-T36950N     Rev: S93E
  Type:   Direct-Access                    ANSI SCSI revision: 03

The adapter is an Adaptec 39160, kernel is 2.5.49-mm2.

It works in 2.4, of course.


Bill

Re: Adaptec 39160 / Yamaha CRW8424S CD burning

[Douglas Gilbert]

William Lee Irwin III wrote:
> SCSI CD burning appears to fail, causing audio CD's burned with
> bash-2.05# cdrecord -v -pad speed=1 dev=0,3,0 -audio `cat tracks`
> (where the tracks are wav files) to have massive numbers of skips.
> 
> $ cat /proc/scsi/scsi 
> Attached devices: 
> Host: scsi0 Channel: 00 Id: 00 Lun: 00
>   Vendor: WDIGTL   Model: WDE18310 ULTRA2  Rev: 1.30
>   Type:   Direct-Access                    ANSI SCSI revision: 02
> Host: scsi0 Channel: 00 Id: 03 Lun: 00
>   Vendor: YAMAHA   Model: CRW8424S         Rev: 1.0j
>   Type:   CD-ROM                           ANSI SCSI revision: 02
> Host: scsi1 Channel: 00 Id: 06 Lun: 00
>   Vendor: IBM      Model: DDYS-T36950N     Rev: S93E
>   Type:   Direct-Access                    ANSI SCSI revision: 03
> 
> The adapter is an Adaptec 39160, kernel is 2.5.49-mm2.
> 
> It works in 2.4, of course.

Bill,
Depending on which version of cdrecord you are using,
cdrecord will get to the SCSI Yamaha burner via:
   - scsi generic (sg) device (probably /dev/sg1)
   - or directly to /dev/scd0 (via the SG_IO ioctl in
     the block layer)
   - or via /dev/scd0 using the CDROM_PACKET_COMMAND
     ioctl

Could you determine which one is happening? If the
sg route is being used then the individual SCSI
commands can be seen by observing 'cat /proc/scsi/sg/debug'
while the burn is in progress. What version of cdrecord
are you using and what does its output look like?

Doug Gilbert

Re: Adaptec 39160 / Yamaha CRW8424S CD burning

[William Lee Irwin III]

On Mon, Jan 13, 2003 at 07:06:37PM +1100, Douglas Gilbert wrote:
> Depending on which version of cdrecord you are using,
> cdrecord will get to the SCSI Yamaha burner via:
>   - scsi generic (sg) device (probably /dev/sg1)
>   - or directly to /dev/scd0 (via the SG_IO ioctl in
>     the block layer)
>   - or via /dev/scd0 using the CDROM_PACKET_COMMAND
>     ioctl
> Could you determine which one is happening? If the
> sg route is being used then the individual SCSI
> commands can be seen by observing 'cat /proc/scsi/sg/debug'
> while the burn is in progress. What version of cdrecord
> are you using and what does its output look like?

It's sg (SG_IO ioctl's), the version of cdrecord I use always uses it.
I'm also running without your fixes. I've got enough blanks, I'll do
a test run anyway if you still need me to run it.


Thanks,
Bill

Re: Adaptec 39160 / Yamaha CRW8424S CD burning

[William Lee Irwin III]

On Mon, Jan 13, 2003 at 07:06:37PM +1100, Douglas Gilbert wrote:
> Depending on which version of cdrecord you are using,
> cdrecord will get to the SCSI Yamaha burner via:
>   - scsi generic (sg) device (probably /dev/sg1)
>   - or directly to /dev/scd0 (via the SG_IO ioctl in
>     the block layer)
>   - or via /dev/scd0 using the CDROM_PACKET_COMMAND
>     ioctl
> Could you determine which one is happening? If the
> sg route is being used then the individual SCSI
> commands can be seen by observing 'cat /proc/scsi/sg/debug'
> while the burn is in progress. What version of cdrecord
> are you using and what does its output look like?

I'm trying Jens' patched cdrecord from people/axboe/tools/ on kernel.org
and got:

$ cat /proc/scsi/sg/debug
dev_max(currently)=6 max_active_device=3 (origin 1)
 def_reserved_size=32768
 >>> device=sg1 scsi0 chan=0 id=3 lun=0   em=0 sg_tablesize=128 excl=0
   FD(1): timeout=20500ms bufflen=129024 (res)sgat=4 low_dma=0
   cmd_q=1 f_packid=0 k_orphan=0 closed=0
     rb>> act: id=0 blen=63504 t_o/elap=40000/15ms sgat=2 op=0x2a
$ cat /proc/scsi/sg/debug
dev_max(currently)=6 max_active_device=3 (origin 1)
 def_reserved_size=32768
 >>> device=sg1 scsi0 chan=0 id=3 lun=0   em=0 sg_tablesize=128 excl=0
   FD(1): timeout=20500ms bufflen=129024 (res)sgat=4 low_dma=0
   cmd_q=1 f_packid=0 k_orphan=0 closed=0
     rb>> act: id=0 blen=63504 t_o/elap=40000/11ms sgat=2 op=0x2a
$ cat /proc/scsi/sg/debug
dev_max(currently)=6 max_active_device=3 (origin 1)
 def_reserved_size=32768
 >>> device=sg1 scsi0 chan=0 id=3 lun=0   em=0 sg_tablesize=128 excl=0
   FD(1): timeout=20500ms bufflen=129024 (res)sgat=4 low_dma=0
   cmd_q=1 f_packid=0 k_orphan=0 closed=0
     rb>> act: id=0 blen=63504 t_o/elap=40000/65ms sgat=2 op=0x2a

Re: Adaptec 39160 / Yamaha CRW8424S CD burning

[William Lee Irwin III]

On Mon, Jan 13, 2003 at 07:06:37PM +1100, Douglas Gilbert wrote:
>> Could you determine which one is happening? If the
>> sg route is being used then the individual SCSI
>> commands can be seen by observing 'cat /proc/scsi/sg/debug'
>> while the burn is in progress. What version of cdrecord
>> are you using and what does its output look like?

On Mon, Jan 13, 2003 at 01:16:35AM -0800, William Lee Irwin III wrote:
> I'm trying Jens' patched cdrecord from people/axboe/tools/ on kernel.org
> and got:
> $ cat /proc/scsi/sg/debug
> dev_max(currently)=6 max_active_device=3 (origin 1)
>  def_reserved_size=32768
>  >>> device=sg1 scsi0 chan=0 id=3 lun=0   em=0 sg_tablesize=128 excl=0
>    FD(1): timeout=20500ms bufflen=129024 (res)sgat=4 low_dma=0
>    cmd_q=1 f_packid=0 k_orphan=0 closed=0
>      rb>> act: id=0 blen=63504 t_o/elap=40000/15ms sgat=2 op=0x2a

Okay, this spewed a coaster too. (2.5.49-mm2). Looks like I'll have to
reboot to have a chance of anything working. I'm going to take a shot
at 2.5.56-mm1 + your SG_IO fixes.

Bill

Re: Adaptec 39160 / Yamaha CRW8424S CD burning

[William Lee Irwin III]

On Mon, Jan 13, 2003 at 01:38:33AM -0800, William Lee Irwin III wrote:
> Okay, this spewed a coaster too. (2.5.49-mm2). Looks like I'll have to
> reboot to have a chance of anything working. I'm going to take a shot
> at 2.5.56-mm1 + your SG_IO fixes.

Okay, 2.5.56-mm1 + your SG_IO fixes got the following in the debug stuff
with Jens' patched cdrecord:

$ cat /proc/scsi/sg/debug    
dev_max(currently)=6 max_active_device=3 (origin 1)
 def_reserved_size=32768
 >>> device=sg1 scsi0 chan=0 id=3 lun=0   em=0 sg_tablesize=128 excl=0
   FD(1): timeout=20500ms bufflen=129024 (res)sgat=4 low_dma=0
   cmd_q=1 f_packid=0 k_orphan=0 closed=0
     rb>> act: id=0 blen=63504 t_o/elap=40000/29ms sgat=2 op=0x2a
The mail in /var/spool/mail/wli has been read.
$ cat /proc/scsi/sg/debug
dev_max(currently)=6 max_active_device=3 (origin 1)
 def_reserved_size=32768
 >>> device=sg1 scsi0 chan=0 id=3 lun=0   em=0 sg_tablesize=128 excl=0
   FD(1): timeout=20500ms bufflen=129024 (res)sgat=4 low_dma=0
   cmd_q=1 f_packid=0 k_orphan=0 closed=0
     rb>> act: id=0 blen=63504 t_o/elap=40000/66ms sgat=2 op=0x2a
$ cat /proc/scsi/sg/debug
dev_max(currently)=6 max_active_device=3 (origin 1)
 def_reserved_size=32768
 >>> device=sg1 scsi0 chan=0 id=3 lun=0   em=0 sg_tablesize=128 excl=0
   FD(1): timeout=20500ms bufflen=129024 (res)sgat=4 low_dma=0
   cmd_q=1 f_packid=0 k_orphan=0 closed=0
     rb>> act: id=0 blen=63504 t_o/elap=40000/10ms sgat=2 op=0x2a

and it burned another coaster.


Bill

Re: Adaptec 39160 / Yamaha CRW8424S CD burning

[William Lee Irwin III]

[-- Attachment #1: brief message --]
[-- Type: text/plain, Size: 777 bytes --]

On Mon, Jan 13, 2003 at 02:35:02AM -0800, William Lee Irwin III wrote:
> Okay, 2.5.56-mm1 + your SG_IO fixes got the following in the debug stuff
> with Jens' patched cdrecord:

I'm giving up at this point. I got another skipping CD (again, this
produces playable CD's in 2.4.x, and the only difference is the kernel):

Included as a MIME attachment is a compressed log of the following cmd:

/share/projects/kernel/hacking/misc/axboe/cdrtools-1.11/cdrecord/OBJ/i686-linux-cc/cdrecord -v -pad -swab debug=2 fs=16m timeout=120 speed=0 dev=0,3,0 -audio `cat tracks` >/share/projects/kernel/hacking/cdrecord.log 2>&1

run on 2.5.56-mm1 with your (Doug Gilbert's) SG_IO fixes.

If there's some fix for this this, I'd be much obliged if it were
included in mainline.


Thanks,
Bill

[-- Attachment #2: wli.cdrecord.log.gz --]
[-- Type: application/octet-stream, Size: 10274 bytes --]

Re: Adaptec 39160 / Yamaha CRW8424S CD burning

[Douglas Gilbert]

William Lee Irwin III wrote:
> On Mon, Jan 13, 2003 at 02:35:02AM -0800, William Lee Irwin III wrote:
> 
>>Okay, 2.5.56-mm1 + your SG_IO fixes got the following in the debug stuff
>>with Jens' patched cdrecord:
> 
> 
> I'm giving up at this point. I got another skipping CD (again, this
> produces playable CD's in 2.4.x, and the only difference is the kernel):

Bill,
Thanks for all the testing.

One comment:
'cat /proc/scsi/sg/debug' will only show SCSI commands
being sent to the burner when the sg interface is being used.
So it seems that your earlier posts showed sg being
used in all cases.
For example:
 > $ cat /proc/scsi/sg/debug
 > dev_max(currently)=6 max_active_device=3 (origin 1)
 >  def_reserved_size=32768
 >  >>> device=sg1 scsi0 chan=0 id=3 lun=0   em=0 sg_tablesize=128 excl=0
 >    FD(1): timeout=20500ms bufflen=129024 (res)sgat=4 low_dma=0
 >    cmd_q=1 f_packid=0 k_orphan=0 closed=0
 >      rb>> act: id=0 blen=63504 t_o/elap=40000/15ms sgat=2 op=0x2a
shows a SCSI WRITE (10) command in progress. This is typical
for cdrecord using sg during a burn.

> Included as a MIME attachment is a compressed log of the following cmd:
> 
> /share/projects/kernel/hacking/misc/axboe/cdrtools-1.11/cdrecord/OBJ/i686-linux-cc/cdrecord -v -pad -swab debug=2 fs=16m timeout=120 speed=0 dev=0,3,0 -audio `cat tracks` >/share/projects/kernel/hacking/cdrecord.log 2>&1

Well that log looks fine, no errors or underruns. cdrecord
checks the status of each executed command quite closely
and would not complete if there was something wrong.

> run on 2.5.56-mm1 with your (Doug Gilbert's) SG_IO fixes.
> 
> If there's some fix for this this, I'd be much obliged if it were
> included in mainline.

In this case my SG_IO fixes should not have made any difference
as they are not in the code path when sg is being used.
Unfortunately those fixes didn't get into lk 2.5.57 .

So I can't explain what you are seeing. It's probably
time to pull out my Yamaha 4416 (SCSI burner) and waste
my own CDRs to see if I get the same problem :-)

Doug Gilbert