Re: Sense fetching [Was: cdrtools /devel ...]

From: Brandon Gooch <jamesbrandongooch_at_gmail.com>
Date: Sat, 13 Nov 2010 12:19:02 -0600
On Sat, Nov 13, 2010 at 3:34 AM, Alexander Motin <mav_at_freebsd.org> wrote:
> Brandon Gooch wrote:
>> 2010/11/5 Alexander Motin <mav_at_freebsd.org>:
>>> Hi.
>>>
>>> I've reviewed tests that scgcheck does to SCSI subsystem. It shown
>>> combination of several issues in both CAM, ahci(4) and cdrtools itself.
>>> Several small patches allow us to pass most of that tests:
>>> http://people.freebsd.org/~mav/sense/
>>>
>>> ahci_resid.patch: Add support for reporting residual length on data
>>> underrun. SCSI commands often returns results shorter then expected.
>>> Returned value allows application to know/check how much data it really
>>> has. It is also important for sense fetching, as ATAPI and USB devices
>>> return sense as data in response to REQUEST_SENSE command.
>>>
>>> sense_resid.patch: When manually requesting sense data (ATAPI or USB),
>>> request only as much data as user requested (not the fixed structure
>>> size), and return respective sense residual length.
>>>
>>> pass_autosence.patch: Unless CAM_DIS_AUTOSENSE is set, always fetch
>>> sense if not done by SIM, independently of CAM_PASS_ERR_RECOVER. As soon
>>> as device freeze released before returning to user-level, user-level
>>> application by definition can't reliably fetch sense data if some other
>>> application (like hald) tries to access device same time.
>>>
>>> cdrtools.patch: Make libscg (part of cdrtools) on FreeBSD to submit
>>> wanted sense length to CAM and do not clear sense return buffer. It is
>>> mostly cosmetics, important probably only for scgcheck.
>>>
>>> Testers and reviewers welcome. I am especially interested in opinion
>>> about pass_autosence.patch -- may be we should lower sense fetching even
>>> deeper, to make it work for all cam_periph_runccb() consumers.
>>
>> Hey mav, sorry to chime in after so long here, but have some of these
>> patches been committed (as of r215179)?
>>
>> Which patches are still applicable for testing? I assume the cdrtools
>> patch for sure...
>
> Now uncommitted pass_autosence.patch and possibly cdrtools.patch.
>

OK. Patched kernel and cdrtools has resulted in a working cdrecord
(burned an ISO successfully) and an endless stream of:

...
(pass0:ata0:0:0:0): Requesting SCSI sense data
(pass0:ata0:0:0:0): SCSI status error
(pass0:ata0:0:0:0): Requesting SCSI sense data
(pass0:ata0:0:0:0): SCSI status error
(pass0:ata0:0:0:0): Requesting SCSI sense data
(pass0:ata0:0:0:0): SCSI status error
(pass0:ata0:0:0:0): Requesting SCSI sense data
(pass0:ata0:0:0:0): SCSI status error
...

ad infinitum until I start cdrecord:

(cd0:ata0:0:0:0): SCSI status error
(cd0:ata0:0:0:0): Requesting SCSI sense data
(cd0:ata0:0:0:0): SCSI status error
(cd0:ata0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0
(cd0:ata0:0:0:0): CAM status: SCSI Status Error
(cd0:ata0:0:0:0): SCSI status: Check Condition
(cd0:ata0:0:0:0): SCSI sense: NOT READY asc:4,8 (Logical unit not
ready, long write in progress)
(cd0:ata0:0:0:0): Error 16, Unretryable error
(cd0:ata0:0:0:0): SCSI status error
(cd0:ata0:0:0:0): Requesting SCSI sense data
(cd0:ata0:0:0:0): SCSI status error
(cd0:ata0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0
(cd0:ata0:0:0:0): CAM status: SCSI Status Error
(cd0:ata0:0:0:0): SCSI status: Check Condition
(cd0:ata0:0:0:0): SCSI sense: NOT READY asc:4,8 (Logical unit not
ready, long write in progress)
(cd0:ata0:0:0:0): Error 16, Unretryable error
(cd0:ata0:0:0:0): SCSI status error
(cd0:ata0:0:0:0): Requesting SCSI sense data
(cd0:ata0:0:0:0): SCSI status error
(cd0:ata0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0
(cd0:ata0:0:0:0): CAM status: SCSI Status Error
(cd0:ata0:0:0:0): SCSI status: Check Condition
(cd0:ata0:0:0:0): SCSI sense: NOT READY asc:4,8 (Logical unit not
ready, long write in progress)
(cd0:ata0:0:0:0): Error 16, Unretryable error
(pass0:ata0:0:0:0): SCSI status error
(pass0:ata0:0:0:0): Requesting SCSI sense data

cdrecord output:

brandon_at_x300:~$ sudo cdrecord dev=0,0,0
Fedora-14-i686-Live-Desktop.iso
                                                       (11-13 11:41)
cdrecord: No write mode specified.
cdrecord: Assuming -sao mode.
cdrecord: If your drive does not accept -sao, try -tao.
cdrecord: Future versions of cdrecord may have different drive
dependent defaults.
Cdrecord-ProDVD-ProBD-Clone 3.00 (amd64-unknown-freebsd9.0) Copyright
(C) 1995-2010 Jörg Schilling
scsidev: '0,0,0'
scsibus: 0 target: 0 lun: 0
Using libscg version 'schily-0.9'.
Device type    : Removable CD-ROM
Version        : 0
Response Format: 2
Capabilities   :
Vendor_info    : 'MATSHITA'
Identifikation : 'DVD-RAM UJ-844  '
Revision       : 'RC02'
Device seems to be: Generic mmc2 DVD-R/DVD-RW/DVD-RAM.
Using generic SCSI-3/mmc   CD-R/CD-RW driver (mmc_cdr).
Driver flags   : MMC-3 SWABAUDIO BURNFREE
Supported modes: TAO PACKET SAO
cdrecord: Warning: Cannot read drive buffer.
cdrecord: Warning: The DMA speed test has been skipped.
Starting to write CD/DVD/BD at speed 16 in real SAO mode for single session.
Last chance to quit, starting real write    0 seconds. Operation starts.
Turning BURN-Free off
cdrecord: WARNING: Drive returns wrong startsec (0) using -150
load: 0.00  cmd: cdrecord 2111 [nanslp] 302.32r 0.12u 1.83s 0% 13380k
load: 0.00  cmd: cdrecord 2111 [nanslp] 306.11r 0.12u 1.87s 0% 13380k
load: 0.00  cmd: cdrecord 2111 [nanslp] 306.66r 0.12u 1.87s 0% 13380k
Track 01: Total bytes read/written: 719323136/719323136 (351232 sectors).

After cdrecord completed, the messages reappeared on the console:

...
(pass0:ata0:0:0:0): Requesting SCSI sense data
(pass0:ata0:0:0:0): SCSI status error
(pass0:ata0:0:0:0): Requesting SCSI sense data
(pass0:ata0:0:0:0): SCSI status error
(pass0:ata0:0:0:0): Requesting SCSI sense data
(pass0:ata0:0:0:0): SCSI status error
(pass0:ata0:0:0:0): Requesting SCSI sense data
(pass0:ata0:0:0:0): SCSI status error
...

But most important part: It works, and it burned very quickly! The CD
was created, and fully functional (I booted the Fedora image and
completed an installation).

Let me know what's next...

-Brandon
Received on Sat Nov 13 2010 - 17:19:05 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:09 UTC