Adaptec 39160 / Yamaha CRW8424S CD burning

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

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

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

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

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

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

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

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

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

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

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

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

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

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:

shows a SCSI WRITE (10) command in progress. This is typical for cdrecord using sg during a burn.

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.

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