Douglas Gilbert wrote:
>
> Arnd Bergmann wrote:
> >
> > [snip]
> > AFAIK, mode2 is a format where a sector has not 2048 but 2336 bytes
> > and the error detection is accomplished differently. You need this
> > to write cd-i and some cd-xa disks. But as my problem did not show
> > up with earlier kernels, I don't think it is a cdrecord problem.
>
> I knew CD-RWs where 2352 bytes longs. I hadn't heard of
> 2336 byte long sectors.
2352 bytes is the size of a raw `red book' sector that is used for
audio CDs. `Mode 1' data sectors have additional additional header
and ECC information that limits the size to 2048 bytes.
`Mode 2' data sectors seem to have a 16 byte header but no ECC.
There is no difference between CD-R and CD-RW wrt the sector format
Writing an audio cd with 2352 byte sectors _does_ work without crash.
FYI, this is a list of the sector sizes from cdrecord.h:
/*
* Defines for data block type (from SCSI-3/mmc)
*/
#define DB_RAW 0 /* 2352 bytes of raw data */
#define DB_RAW_PQ 1 /* 2368 bytes (raw data + P/Q Subchannel)*/
#define DB_RAW_PW 2 /* 2448 bytes (raw data + P-W Subchannel)*/
#define DB_RAW_PW_R 3 /* 2448 bytes (raw data + P-W raw
Subchannel)*/
#define DB_RES_4 4 /* - Reserved */
#define DB_RES_5 5 /* - Reserved */
#define DB_RES_6 6 /* - Reserved */
#define DB_VU_7 7 /* - Vendor specific */
#define DB_ROM_MODE1 8 /* 2048 bytes Mode 1 (ISO/IEC 10149) */
#define DB_ROM_MODE2 9 /* 2336 bytes Mode 2 (ISO/IEC 10149) */
#define DB_XA_MODE1 10 /* 2048 bytes Mode 1? (CD-ROM XA form 1) */
#define DB_XA_MODE2 10 /* 2048 bytes Mode 2! (CD-ROM XA form 1) */
#define DB_XA_MODE2_F1 11 /* 2056 bytes Mode 2 (CD-ROM XA form 1) */
#define DB_XA_MODE2_F2 12 /* 2324 bytes Mode 2 (CD-ROM XA form 2) */
#define DB_XA_MODE2_MIX 13 /* 2332 bytes Mode 2 (CD-ROM XA 1/2+subhdr)*/
#define DB_RES_14 14 /* - Reserved */
#define DB_VU_15 15 /* - Vendor specific
*/
>
> > [snip]
> > Well, there are usually no preocesses with STAT 'SL':
> >
> > F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME
> > COMMAND
> > 100 0 762 638 0 0 5500 5500 end SL tty1 0:04
> > cdrecord -V
> > 140 0 763 762 0 0 5412 5388 nanosl SL tty1 0:00
> > cdrecord -V
>
> No "[eh_...]" type process/thread around? I notice that the
> aha1542 does use the new "eh" error regime while the advansys
> 5140 ISA adapter that I tested on uses the old regime.
Sorry, I grep'ed out everything except cdrecord. This is the line you
were probably missing:
040 0 6 1 0 0 0 0 down_i SW ? 0:00
[scsi_eh_0]
>
> > [snip]
> > > The new sg driver will
> > > allow you to do the following during a freeze:
> > > $ cat /proc/scsi/sg/debug
> > >
> > > I would be interested in the output.
> > This is what is said after crashing:
> >
> > dev_max=45 max_active_device=2 (origin 1)
> > scsi_dma_free_sectors=224 sg_pool_secs_aval=320 def_reserved_size=32768
> > >>> device=0(sga) scsi0 chan=0 id=3 lun=0 em=0 sg_tablesize=16 excl=0
> > FD(1): timeout=4050 bufflen=32768 (res)sgat=0 low_dma=1
> > cmd_q=0 f_packid=0 k_orphan=0 closed=0
> > reserved_buff>> act: id=76 t_o/elap=40500/158390 sgat=0 op=0x2a
> > >>> device=1(sgb) scsi1 chan=0 id=0 lun=0 em=1 sg_tablesize=256
> > excl=0
> >
> > The 'closed' bit changed to 1 when I killed cdrecord. The elap timer is
> > still
> > running.
> >
>
> Thanks for that output. It shows that sg sent a request
> to the mid-level with a timeout of 40.5 seconds and
> 158.39 seconds later nothing had happened. It confirms the
> packet was a "write" with a buffer length <= 32,768 bytes.
> No scatter gather is being used. Only a few of the
> available sectors in the scsi mid level pool are in use.
>
> It is correct for the closed bit to flip to 1 when a
> signal kills the cdrecord process because the Linux
> kernel is kind enough to call sg_release() in that
> situation.
>
> All in all, no real surprises. The write has failed and
> the "eh" error handling is unable to cope with it.
>
> Also I didn't quite understand, did it work with cdr18a28
> but fail with cdr18a35?
No, both failed with 'cdrecord -V -dummy -mode2 image.iso'
and worked with 'cdrecord -V -dummy -data image.iso'.
But now it's getting strange: I just tried cdrdao and that
does not show this problem with any sector format.
Arnd <><
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
