From owner-freebsd-current@FreeBSD.ORG Sat Nov 13 18:19:05 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 56A531065670; Sat, 13 Nov 2010 18:19:05 +0000 (UTC) (envelope-from jamesbrandongooch@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 635698FC13; Sat, 13 Nov 2010 18:19:04 +0000 (UTC) Received: by wwj40 with SMTP id 40so1127917wwj.31 for ; Sat, 13 Nov 2010 10:19:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=gLWMC3n9RgOVqCs8HlNzEPZkHAbNYz215ojbg+6SC2s=; b=lG54Cz4n/BjL8cvnRO18e5p5T+oBkYWGF2a7elEggxx3AUvhwpjkOSuVWBSiqegPu1 6OIusNA6ne1AIHZPKZS9SYVcLBI4sOpSTLMg+uREeNkJBF66gkP0AV4isvT6yAkdjoot CASiUn51FNGdIiSn7KhJC6mJgtyUE6MVkeHDg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=b8nZ69wHMurqKcAqlXbaNMpKGGpn9A+E2utgzQjkWBnklR/dqZLsSBxkQQQ7FM/IG1 +Tk4eZlH74RiGyDVAG+MPAsM/vzX3wRDblJXecHNVIBW1AgBdtHbQhwDFKOwSKtjtK4q P2Pz8lZJHbx8jlbfsnAux2YgifnLoHOMXprmA= MIME-Version: 1.0 Received: by 10.216.93.9 with SMTP id k9mr3250012wef.89.1289672343001; Sat, 13 Nov 2010 10:19:03 -0800 (PST) Received: by 10.216.12.80 with HTTP; Sat, 13 Nov 2010 10:19:02 -0800 (PST) In-Reply-To: <4CDE5B8C.4000102@FreeBSD.org> References: <4CD45209.5010607@FreeBSD.org> <4CDE5B8C.4000102@FreeBSD.org> Date: Sat, 13 Nov 2010 12:19:02 -0600 Message-ID: From: Brandon Gooch To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-scsi@freebsd.org, FreeBSD-Current , FreeBSD Stable Subject: Re: Sense fetching [Was: cdrtools /devel ...] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Nov 2010 18:19:05 -0000 On Sat, Nov 13, 2010 at 3:34 AM, Alexander Motin wrote: > Brandon Gooch wrote: >> 2010/11/5 Alexander Motin : >>> 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 soo= n >>> 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 eve= n >>> 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@x300:~$ sudo cdrecord dev=3D0,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=F6rg 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