>The original firmware was 3.04 (my co-worker said), it was twice
>upgraded, but I've never tried to write with the original firmware.
>>From the kernel log when the box froze:
>scsi : aborting command due to timeout : pid 32517, scsi0, channel 0, id
>5, lun 0 Write (10) 00 00 00 01 1e 00 00 0d 00
>(scsi0:0:5:0) Aborting scb 33, flags 0x4
>(scsi0:0:5:0) SCB disconnected. Queueing Abort SCB.
>(scsi0:0:5:0) Abort message mailed.
>(scsi0:0:5:0) Reset device, active_scb 26
>(scsi0:0:5:0) Cleaning up status information and delayed_scbs.
>(scsi0:0:5:0) Cleaning QINFIFO.
>(scsi0:0:5:0) Cleaning waiting_scbs.
>(scsi0:0:5:0) Cleaning waiting for selection list.
>(scsi0:0:5:0) Cleaning disconnected scbs list.
>(scsi0:0:5:0:tag33) doesn't match search criteria (scsi0:0:5:0:tag0)
>last message repeated 2 times
>(scsi0:0:0:0:tag58) doesn't match search criteria (scsi0:0:5:0:tag0)
>syslogd 1.3-3: restart.
>On the console:
>aic7xxx: AWAITING_MSG for an SCB that does not have a waiting message.
>In swapper task - not syncing
This may be bad SCSI cabling, bad Firmware or a bad SCSU Hostadapter driver.
>>From the xcdroast log I have only the exact command line:
>Apr 28 02:39:46 XCDR 0.96d: Executing:
>/usr/lib/xcdroast-0.96d/bin/cdrecord-1.6 -v speed=1 dev=0,05,00 -swab
>-audio -nopreemp /home/tmp/audio_01.cdr -audio -nopreemp
>/home/tmp/audio_02.cdr -audio -nopreemp /home/tmp/audio_03.cdr -audio
>-nopreemp /home/tmp/audio_04.cdr -audio -nopreemp /home/tmp/audio_05.cdr
>Here is the log what I have when the box doesn't freeze but stop the
>writing/fixating with error:
>Cdrecord release 1.6a11 Copyright (C) 1995-1998 Jvrg Schilling
>TOC Type: 0 = CD-DA
>scsidev: '0,05,00'
>scsibus: 0 target: 5 lun: 0
>Device type : Removable CD-ROM
>Version : 2
>Response Format: 2
>Capabilities : SYNC LINKED
>Vendor_info : 'MATSHITA'
>Identifikation : 'CD-R CW-7502 '
>Revision : '3.10'
>Device seems to be: Matsushita CW-7502.
>Using generic SCSI-3/mmc CD-R driver (mmc_cdr).
>Driver flags : SWABAUDIO
....
>Track 07: Total bytes read/written: 33798240/33798240 (14370 sectors).
>Starting new track at sector: 328177
>Track 08: Total bytes read/written: 34292160/34292160 (14580 sectors).
>Starting new track at sector: 342907
>/usr/lib/xcdroast-0.96d/bin/cdrecord-1.6: Success. write_g1: scsi sendcmd:
>retryable error
>status: 0x2 (CHECK CONDITION)
>Sense Bytes: F0 00 04 00 05 4B EC 0A 00 00 00 00 44 00 00 00
>Sense Key: 0x4 Hardware Error, Segment 0
>Sense Code: 0x44 Qual 0x00 (internal target failure) Fru 0x0
>Sense flags: Blk 347116 (valid)
>cmd finished after 18.176s timeout 20s
This is a problem in the drive!
>------------------------------------------------------------>
>From: Doug Ledford (dledford@dialnet.net)
>Date: Mon, 27 Apr 1998 18:50:58 -0500
>Subject: Re: 2.0.34p11b SCSI (Adaptec) probs?
>Matthew Kirkwood wrote:
>> 2 x Adaptec 2940U's, one with 2x2Gb disks, one with a Yamaha
>> CD-rewriter.
>> I forget the precise error, but can ruin another CD if requested :-)
>I'll probably need this to debug the problem, but before you do ruin
>another CD, check out what I have to say further on.
>> The error comes from cdrecord, not the kernel, and claims to be
>> retryable, but it bombs out shortly after.
>>
>OK....before you go ruining a CD, let me explain what one of the most
>important changes in the aic7xxx driver was. Namely, the aic7xxx driver
>now properly passes back the sense data from a drive to the upper levels
>of the kernel and to the user land software (if using the scsi_generic or
>scsi_ioctl interface). The driver in 2.0.33 used to send this data to
>never-never land, scribbling on memory and never returning the true state
>of the drive to the application program in the process. Fixing this bug
>alone is enough to bring up all sorts of problems in software trying to
>parse the sense data from a device. Where as the sense data used to be
>all 0 bytes, it now has valid sense data and if the software doesn't
>properly handle this sense data, then it can puke.
>Now, along with proper sense data returns, this seems to have possibly
>uncovered a bug in the more generic SCSI layer processing in regards to
>specific commands common to CD writers. Namely, the timeout value for
>some commands is too short. I haven't looked into the mid level code
>because I haven't had the time, but at least one other person is able to
>cause bus resets without even doing a real write to his cd recorder. The
>condition appears to be something along the lines of the software saying
>"OK, prepare for a write", at which point the CD-R starts to check out the
>CD and make sure it can write, and in the process, the command times out.
>I'm not sure if this is a mid level code thing or the user land software
>is setting its own timeout too short, I haven't even looked into how it's
>done that much. So, as soon as I can get my hands on a CD-R device and
>start testing, I'll get it figured out and fixed.
Believe me, I do all my development on SunOS/Solaris and my /dev/scg driver
gives all error codes for about 12 years, that is far longer than Linux exists.
You cannot do SCSI userland program development on Linux because there
are several error situations you won't get from Linux:
- actual DMA count (resp. DMA residual count)
- SCSI status code
- SCSI bus transport status
- The required minimum amount of sense data (18 Bytes)
Crercord development is done on Solaris and not on Linux.
Cdrecord deals with all error conditions correctly and has always ben
able to evaluate all error codes.
If you have problems, they are either related to your cabling, to
the Linux drviers or to a bad drive.
Of course, you are right with your statement, if you are talking about
the SANE scanner project. The SANE guys do not deal correctly with
SCSI error codes and got big surprises when they started to support
Solaris by using my scg driver. Unforetunately, then did not adopt to my
portable SCSI user transport library but stuck with their solution
in hiding all unknown error situations.
Jörg
EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
js@cs.tu-berlin.de (uni) If you don't have iso-8859-1
schilling@fokus.gmd.de (work) chars I am J"org Schilling
URL: http://www.fokus.gmd.de/usr/schilling ftp://ftp.fokus.gmd.de/pub/unix
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu