Re: sym53c875 error

2001-04-24 Thread Gérard Roudier



On Tue, 24 Apr 2001, Hamilton, Eamonn wrote:

> Hi Folks.
> 
> Under all of the kernels I have access to try ( 2.2.19, 2.4.X & 2.4.X-ac* ),
> when I try and write an image in XA2 format to my SCSI writer ( Yamaha
> CDR-400t ), I get a DMA overrun. When I try with a kernel patched with the
> beta symbios driver ( 2.1.9 ), it works just fine.

Interesting.

Note that sym-2.1.9 status is probably far better than beta. I just
haven't information enough to know how reliable this driver version
actually is. FYI, I use sym-2.1.x under Linux and FreeBSD since several
months. The NetBSD port is still work in progress, but the driver works
just fine for me under this O/S too.

> This is on a Debian woody system, using cdrecord 1.10 ( also 1.9 and 1.8
> with the same symptoms ) attached to a Tekram DC390F.
> 
> Transcript as follows :
> 
> cdrecord dev=0,3,0 -dummy -xa2 firmware.iso
> 
> Cdrecord 1.10a18 (i686-pc-linux-gnu) Copyright (C) 1995-2001 Jörg Schilling
> scsidev: '0,3,0'
> scsibus: 0 target: 3 lun: 0
> Linux sg driver version: 3.1.17
> Using libscg version 'schily-0.5'
> Device type: Removable CD-ROM
> Version: 2
> Response Format: 2
> Capabilities   :
> Vendor_info: 'YAMAHA  '
> Identifikation : 'CDR400t '
> Revision   : '1.0q'
> Device seems to be: Yamaha CDR-400.
> Using generic SCSI-3/mmc CD-R driver (mmc_cdr).
> Driver flags   : SWABAUDIO
> Starting to write CD/DVD at speed 1 in dummy mode for single session.
> Last chance to quit, starting dummy write in 1 seconds.
> cdrecord: Input/output error. write_g1: scsi sendcmd: retryable error
> CDB:  2A 00 00 00 01 C2 00 00 1F 00
> status: 0x0 (GOOD STATUS)
> DMA overrun, resid: -248

Would be interesting to know how cdrecord calculates the residual. It
should probably use the return value from read()/write(). Does it ?

> cmd finished after 0.579s timeout 40s
> write track data: error after 0 bytes
> Sense Bytes: 70 00 00 00 00 00 00 0A 00 00 00 00 00 00 00 00 00 00
> 
> 
> And while that lot happens, I get
> 
> sym53c875-0-<3,*>: target did not report SYNC.

This message is not normal given the device that for sure supports 
synchronous data transfers. I will look into this problem, first.

> sym53c875-0-<3,*>: extraneous data discarded.
> sym53c875-0-<3,*>: COMMAND FAILED (89 0) @c12a3800.

This one could have been triggerred by previous errors ???.

> Standard burns work ok, it's just the xa2 stuff I have a problem with so
> far. I also tried using the old NCR driver with the same results.

If you mean that the ncr53c8xx driver gets the same error, then the cause
can be a either common bug in sym53c8xx and ncr53c8xx, or caused by a
difference between sym53c8xx/ncr53c8xx and sym-2.1.9.

The main difference that comes to mind is that sym-2 uses the new error
handling interface but sym53c8xx/ncr53c8xx use the old one. If it is the
cause, then the sg driver might get involved in the failure.

> Anybody got any ideas?

No more than the above for now.
Will let you know if I get better ones.

Regards,
  Gérard.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



sym53c875 error

2001-04-24 Thread Hamilton, Eamonn

Hi Folks.

Under all of the kernels I have access to try ( 2.2.19, 2.4.X & 2.4.X-ac* ),
when I try and write an image in XA2 format to my SCSI writer ( Yamaha
CDR-400t ), I get a DMA overrun. When I try with a kernel patched with the
beta symbios driver ( 2.1.9 ), it works just fine.

This is on a Debian woody system, using cdrecord 1.10 ( also 1.9 and 1.8
with the same symptoms ) attached to a Tekram DC390F.

Transcript as follows :

cdrecord dev=0,3,0 -dummy -xa2 firmware.iso

Cdrecord 1.10a18 (i686-pc-linux-gnu) Copyright (C) 1995-2001 Jörg Schilling
scsidev: '0,3,0'
scsibus: 0 target: 3 lun: 0
Linux sg driver version: 3.1.17
Using libscg version 'schily-0.5'
Device type: Removable CD-ROM
Version: 2
Response Format: 2
Capabilities   :
Vendor_info: 'YAMAHA  '
Identifikation : 'CDR400t '
Revision   : '1.0q'
Device seems to be: Yamaha CDR-400.
Using generic SCSI-3/mmc CD-R driver (mmc_cdr).
Driver flags   : SWABAUDIO
Starting to write CD/DVD at speed 1 in dummy mode for single session.
Last chance to quit, starting dummy write in 1 seconds.
cdrecord: Input/output error. write_g1: scsi sendcmd: retryable error
CDB:  2A 00 00 00 01 C2 00 00 1F 00
status: 0x0 (GOOD STATUS)
DMA overrun, resid: -248
cmd finished after 0.579s timeout 40s
write track data: error after 0 bytes
Sense Bytes: 70 00 00 00 00 00 00 0A 00 00 00 00 00 00 00 00 00 00


And while that lot happens, I get

sym53c875-0-<3,*>: target did not report SYNC.
sym53c875-0-<3,*>: extraneous data discarded.
sym53c875-0-<3,*>: COMMAND FAILED (89 0) @c12a3800.

Standard burns work ok, it's just the xa2 stuff I have a problem with so
far. I also tried using the old NCR driver with the same results.

Anybody got any ideas?

Cheers,
Eamonn
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: sym53c875 error

2001-04-24 Thread Gérard Roudier



On Tue, 24 Apr 2001, Hamilton, Eamonn wrote:

 Hi Folks.
 
 Under all of the kernels I have access to try ( 2.2.19, 2.4.X  2.4.X-ac* ),
 when I try and write an image in XA2 format to my SCSI writer ( Yamaha
 CDR-400t ), I get a DMA overrun. When I try with a kernel patched with the
 beta symbios driver ( 2.1.9 ), it works just fine.

Interesting.

Note that sym-2.1.9 status is probably far better than beta. I just
haven't information enough to know how reliable this driver version
actually is. FYI, I use sym-2.1.x under Linux and FreeBSD since several
months. The NetBSD port is still work in progress, but the driver works
just fine for me under this O/S too.

 This is on a Debian woody system, using cdrecord 1.10 ( also 1.9 and 1.8
 with the same symptoms ) attached to a Tekram DC390F.
 
 Transcript as follows :
 
 cdrecord dev=0,3,0 -dummy -xa2 firmware.iso
 
 Cdrecord 1.10a18 (i686-pc-linux-gnu) Copyright (C) 1995-2001 Jörg Schilling
 scsidev: '0,3,0'
 scsibus: 0 target: 3 lun: 0
 Linux sg driver version: 3.1.17
 Using libscg version 'schily-0.5'
 Device type: Removable CD-ROM
 Version: 2
 Response Format: 2
 Capabilities   :
 Vendor_info: 'YAMAHA  '
 Identifikation : 'CDR400t '
 Revision   : '1.0q'
 Device seems to be: Yamaha CDR-400.
 Using generic SCSI-3/mmc CD-R driver (mmc_cdr).
 Driver flags   : SWABAUDIO
 Starting to write CD/DVD at speed 1 in dummy mode for single session.
 Last chance to quit, starting dummy write in 1 seconds.
 cdrecord: Input/output error. write_g1: scsi sendcmd: retryable error
 CDB:  2A 00 00 00 01 C2 00 00 1F 00
 status: 0x0 (GOOD STATUS)
 DMA overrun, resid: -248

Would be interesting to know how cdrecord calculates the residual. It
should probably use the return value from read()/write(). Does it ?

 cmd finished after 0.579s timeout 40s
 write track data: error after 0 bytes
 Sense Bytes: 70 00 00 00 00 00 00 0A 00 00 00 00 00 00 00 00 00 00
 
 
 And while that lot happens, I get
 
 sym53c875-0-3,*: target did not report SYNC.

This message is not normal given the device that for sure supports 
synchronous data transfers. I will look into this problem, first.

 sym53c875-0-3,*: extraneous data discarded.
 sym53c875-0-3,*: COMMAND FAILED (89 0) @c12a3800.

This one could have been triggerred by previous errors ???.

 Standard burns work ok, it's just the xa2 stuff I have a problem with so
 far. I also tried using the old NCR driver with the same results.

If you mean that the ncr53c8xx driver gets the same error, then the cause
can be a either common bug in sym53c8xx and ncr53c8xx, or caused by a
difference between sym53c8xx/ncr53c8xx and sym-2.1.9.

The main difference that comes to mind is that sym-2 uses the new error
handling interface but sym53c8xx/ncr53c8xx use the old one. If it is the
cause, then the sg driver might get involved in the failure.

 Anybody got any ideas?

No more than the above for now.
Will let you know if I get better ones.

Regards,
  Gérard.

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/