"Erich J. Ritzmann" wrote:
>
> I don't have your specific hardware, but I have a Yamaha CRW4416S
> rewritable CD device, on an Adaptec 2940UW HBA which also gets weird
> sense errors, has problems writing a CD successfully, and has trouble
> even reading standard audio CDs. The details of which I posted to the
> list about a month back.
>
> I know that there are some obscure firmware problems with the 4416S, but I
> suspect the SCSI driver software in Linux to be the culprit in this case.
Well I upgraded my 4416S from 1.0f (as your trace shows) to
1.0g . The upgrade notes say: "... drive not being detected
or causing the 'blue screen' error when connecting
to the narrow bus of wide or ultra2 SCSI card ...".
It is not easy to browse the source of that OS
but I guess a bus reset (as your trace shows
when starting to fixate) may cause such a blue screen.
BTW The website to get the firmware is:
http://www.yamahayst.com
The DOS route worked for me.
Also the minimum fill of 29% shown by cdrecord seems
dangerously low. My system shows around 90% for x4
burns (AMD 300MHz).
My system contains a Advansys 940UW and a 4416S and I'm
yet to have such a problem (before or after the upgrade).
The SCSI error report in your /var/log/messages about
the UNKNOWN command is a READ SUB-CHANNEL command. That
is correctly reported in 2.2.10-ac10 however I don't
know why it occured on your system and haven't seen it
on my hardware.
> Certainly, this bit of sympathy is falling short of the answer you were
> hoping for. Some consolation that we have the source code, but, I have
> other software to develop, and debugging device drivers code that should
> be stable is at this point more of an irritation than a challenge,
> admittedly.
The error that killed cdrecord was a UNIT ATTENTION
alerting the app that a bus reset had occurred.
If the log didn't show the mid or low level
causing a bus reset then something else caused it.
Any device on a SCSI bus can cause a bus reset.
>
> On Fri, 9 Jul 1999, Sven Anders wrote:
>
> > Once again: Can anybody confirm this behaviour ?!
> >
> > I'm trying to track the problem and my current status is the following:
> >
> > I turned some debugging information in 'sr.c' on and get the attached
> > output.
> > When you look at it you will see, that the CD-Writer returns a
> > VOLUME_OVERFLOW sense key and the driver will correctly get the last
> > blocks. In the case of the DVD-ROM the driver gets an 'Illegal Request'
> > and the driver does not branch into the special routines to get the
> > last blocks.
> >
> > Is the DVD-ROM buggy in sending an error (0x70) instead of valid sense
> > data (0xf0) or does the driver behave wrong ?!
> >
If you wish to take a closer look at what is happening
then perhaps you could download the utilities tarball at:
http://www.torque.net/sg [follow utilities link]
You will need to have the sg device driver available
(either built into the kernel or as a module). Then try:
# sg_readcap /dev/sr0 [or /dev/sr1]
to see what your block size is and the address of the
last block. For example, if your block size is 2048
and the last block address is 332529 then try:
# sg_dd2048 if=/dev/sgc of=/dev/null skip=332529 count=1
This utility is just like "dd" but will report any
SCSI error directly to you (and bypasses the cdrom
code). This example assumes the sg device /dev/sgc
is the same as the cdrom driver you wish to test.
Sg devices are allocated in the same number and order
seen in 'cat /proc/scsi/scsi'.
Such a test works ok for CDRs burnt on my Yamaha 4416S
by cdrecord. However a friend who uses similar hardware
and NT to burn CDRs always seems to get an error on
the last block just as you seem to. However those CDRs
give a "L-EC UNCORRECTABLE ERROR" error which is different
from your report.
Also the position of the error you have reported is
awfully close to the 650 MB limit for a CDR.
Hope this helps.
Doug Gilbert
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
