From owner-freebsd-scsi@FreeBSD.ORG Mon Nov 8 11:07:05 2010 Return-Path: Delivered-To: freebsd-scsi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 03B361065674 for ; Mon, 8 Nov 2010 11:07:05 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id E47AB8FC28 for ; Mon, 8 Nov 2010 11:07:04 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id oA8B74QY088200 for ; Mon, 8 Nov 2010 11:07:04 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id oA8B74HK088198 for freebsd-scsi@FreeBSD.org; Mon, 8 Nov 2010 11:07:04 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 8 Nov 2010 11:07:04 GMT Message-Id: <201011081107.oA8B74HK088198@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-scsi@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-scsi@FreeBSD.org X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2010 11:07:05 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o docs/151336 scsi Missing documentation of scsi_ and ata_ functions in c o kern/149502 scsi [mpt] Latent buglet in debug print code o kern/148083 scsi [aac] Strange device reporting o kern/147704 scsi [mpt] sys/dev/mpt: new chip revision, partially unsupp o kern/146287 scsi [ciss] ciss(4) cannot see more than one SmartArray con o kern/145768 scsi [mpt] can't perform I/O on SAS based SAN disk in freeb o kern/144648 scsi [aac] Strange values of speed and bus width in dmesg o kern/144301 scsi [ciss] [hang] HP proliant server locks when using ciss o kern/142351 scsi [mpt] LSILogic driver performance problems o kern/141934 scsi [cam] [patch] add support for SEAGATE DAT Scopion 130 o kern/134488 scsi [mpt] MPT SCSI driver probes max. 8 LUNs per device o kern/132250 scsi [ciss] ciss driver does not support more then 15 drive o kern/132206 scsi [mpt] system panics on boot when mirroring and 2nd dri o kern/130621 scsi [mpt] tranfer rate is inscrutable slow when use lsi213 o kern/129602 scsi [ahd] ahd(4) gets confused and wedges SCSI bus o kern/128452 scsi [sa] [panic] Accessing SCSI tape drive randomly crashe o kern/128245 scsi [scsi] "inquiry data fails comparison at DV1 step" [re o kern/127927 scsi [isp] isp(4) target driver crashes kernel when set up o kern/127717 scsi [ata] [patch] [request] - support write cache toggling o kern/124667 scsi [amd] [panic] FreeBSD-7 kernel page faults at amd-scsi o kern/123674 scsi [ahc] ahc driver dumping o sparc/121676 scsi [iscsi] iscontrol do not connect iscsi-target on sparc o kern/120487 scsi [sg] scsi_sg incompatible with scanners o kern/120247 scsi [mpt] FreeBSD 6.3 and LSI Logic 1030 = only 3.300MB/s o kern/119668 scsi [cam] [patch] certain errors are too verbose comparing o kern/114597 scsi [sym] System hangs at SCSI bus reset with dual HBAs o kern/110847 scsi [ahd] Tyan U320 onboard problem with more than 3 disks o kern/99954 scsi [ahc] reading from DVD failes on 6.x [regression] o kern/94838 scsi Kernel panic while mounting SD card with lock switch o o kern/92798 scsi [ahc] SCSI problem with timeouts o kern/90282 scsi [sym] SCSI bus resets cause loss of ch device o kern/76178 scsi [ahd] Problem with ahd and large SCSI Raid system o kern/74627 scsi [ahc] [hang] Adaptec 2940U2W Can't boot 5.3 s kern/61165 scsi [panic] kernel page fault after calling cam_send_ccb o kern/60641 scsi [sym] Sporadic SCSI bus resets with 53C810 under load o kern/60598 scsi wire down of scsi devices conflicts with config s kern/57398 scsi [mly] Current fails to install on mly(4) based RAID di o bin/57088 scsi [cam] [patch] for a possible fd leak in libcam.c o kern/52638 scsi [panic] SCSI U320 on SMP server won't run faster than o kern/44587 scsi dev/dpt/dpt.h is missing defines required for DPT_HAND o kern/40895 scsi wierd kernel / device driver bug o kern/39388 scsi ncr/sym drivers fail with 53c810 and more than 256MB m o kern/35234 scsi World access to /dev/pass? (for scanner) requires acce 43 problems total. From owner-freebsd-scsi@FreeBSD.ORG Mon Nov 8 15:29:52 2010 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1907E106564A; Mon, 8 Nov 2010 15:29:52 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id AE9628FC0C; Mon, 8 Nov 2010 15:29:50 +0000 (UTC) Received: by gwj16 with SMTP id 16so3581158gwj.13 for ; Mon, 08 Nov 2010 07:29:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=hK5AjbK/34d6o7wWT8R1kXxlCJK8H6zqeWYCjxqm2sA=; b=vM8A0TrWV3jFGd0rXZ+8lkaFXNsRSUACZi7BQMtOdJANuFwFnHhFr4nK61K2pailtp iQ5tt37drxuKCABYuYg/DXKggru/aFAPpcyvhhGuwhsJVvj4YU2KCnxUDKM87s1OeSoN 8Jag6Rx02K8BP7PSk/y3xJ0yJttOp6m7Y2tSs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=xyJTPsvxbvhiCQ1+2v0QgSJQbyYohHsGMQAVCODDOJxPqJ8UIlZLBuhjZtEkjVMCJn DrSducQFlPwbZe/NIT5W1iB4E1A5RNbtP74J8aOIlxyP8MK+9OKTIP4aBfG+TuQgblhs jf5q9IOnHuRwiKYb465RMNyuWIBwQfkHkb2ME= Received: by 10.204.51.142 with SMTP id d14mr5090827bkg.48.1289230189712; Mon, 08 Nov 2010 07:29:49 -0800 (PST) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id r21sm2791bkj.22.2010.11.08.07.29.46 (version=SSLv3 cipher=RC4-MD5); Mon, 08 Nov 2010 07:29:47 -0800 (PST) Sender: Alexander Motin Message-ID: <4CD81759.3040109@FreeBSD.org> Date: Mon, 08 Nov 2010 17:29:29 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Alexander Best , freebsd-scsi@freebsd.org References: <4CD455A3.2010803@FreeBSD.org> In-Reply-To: <4CD455A3.2010803@FreeBSD.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Re: panic with high kern.cam.boot_delay value X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2010 15:29:52 -0000 Alexander Motin wrote: > Alexander Best wrote: >> i just stumbled upon a panic in connection with a very high kern.cam.boot_delay >> value (=100000). this is on HEAD (r214809; amd64). unfortunately i couldn't >> enter the debugger, because the panic occured before my usb keyboard attached. >> >> the panic however occured in sched_priority(). can anybody reproduce this? just >> before the panic i saw some xpt_* message in connection with a 60 second delay. > > I have feeling that it is related not to CAM, but to new event timers > infrastructure and SCHED_ULE. I have one report about panic in > sched_priority() on virtual machine. Unluckily, I can't reproduce any of > cases. r214987 should fix the problem. -- Alexander Motin From owner-freebsd-scsi@FreeBSD.ORG Mon Nov 8 16:30:04 2010 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C158D10656A9 for ; Mon, 8 Nov 2010 16:30:04 +0000 (UTC) (envelope-from joerg.schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com) Received: from relay01-haj2.antispameurope.com (relay01-haj2.antispameurope.com [83.246.65.51]) by mx1.freebsd.org (Postfix) with ESMTP id 3C1BC8FC21 for ; Mon, 8 Nov 2010 16:30:03 +0000 (UTC) Received: by relay01-haj2.antispameurope.com (ASE-Secure-MTA, from userid 1000) id 99EB016005D; Mon, 8 Nov 2010 17:19:11 +0100 (CET) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by relay01-haj2.antispameurope.com (ASE-Secure-MTA) with ESMTP id 8C831160053; Mon, 8 Nov 2010 17:19:09 +0100 (CET) Received: from EXCHSRV.fokus.fraunhofer.de (bohr.fokus.fraunhofer.de [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.14.2/8.14.2) with SMTP id oA8GJ3Yp026804; Mon, 8 Nov 2010 17:19:08 +0100 (MET) Received: from rigel ([10.147.65.195]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Mon, 8 Nov 2010 17:18:42 +0100 Date: Mon, 08 Nov 2010 17:18:39 +0100 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) To: mav@freebsd.org, marius@alchemy.franken.de Message-ID: <4cd822df.o/wBtwsNCXiy8xZn%Joerg.Schilling@fokus.fraunhofer.de> References: <4CD45209.5010607@FreeBSD.org> <20101105192028.GA68728@alchemy.franken.de> In-Reply-To: <20101105192028.GA68728@alchemy.franken.de> User-Agent: nail 11.22 3/20/05 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 08 Nov 2010 16:18:42.0976 (UTC) FILETIME=[9C854A00:01CB7F60] Cc: freebsd-scsi@freebsd.org, freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Sense fetching [Was: cdrtools /devel ...] X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2010 16:30:04 -0000 Marius Strobl wrote: > On Fri, Nov 05, 2010 at 08:50:49PM +0200, Alexander Motin wrote: > > 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. Your patch to libscg looks definitely OK if we only look at the new corrected kernel driver behavior. There is a problem: In case that there is a sense data residual > 0, libscg will asume that there is less sense data that really present in case that a "new" libscg is runnung on an old kernel. Given the fact that many drives will probably only return 18 bytes of sense data, this will happen every time libscg is told to fetch more sense than the drive is willing to return. Is there a way to distinct an old kernel from a new one? > > 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. This is what we need! > > 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. I see no advantage in removing the call to fillbytes(). > Please don't commit this to the port directly but let it loop back > via upstream (CC'ed) instead, otherwise we would need to obey the > following, which is undesirable, especially if these really are > mostly cosmetic issues: > /* > * Warning: you may change this source, but if you do that > * you need to change the _scg_version and _scg_auth* string below. > * You may not return "schily" for an SCG_AUTHOR request anymore. > * Choose your name instead of "schily" and make clear that the version > * string is related to a modified source. > */ > > > > > 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. Did you test a modified libscg on an unmodified kernel? Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From owner-freebsd-scsi@FreeBSD.ORG Mon Nov 8 17:07:12 2010 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B4601106566C; Mon, 8 Nov 2010 17:07:12 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3E1878FC17; Mon, 8 Nov 2010 17:07:11 +0000 (UTC) Received: by gya6 with SMTP id 6so3656542gya.13 for ; Mon, 08 Nov 2010 09:07:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=mKLa3Rhl/UcBVIRyAaMGm5Q/nCbrZQiygnc0ugu78rw=; b=A3XV+P5mrQmXOKz9L7KZfb7bYXFwW//qua9paFfJh1RJ6uig2tmHkl2Zv2mTfmFgiP t/n/dfyIJ2FVIYlvUDIebhzg5SVI4kzY5ieHUOp/GTuo+rxcPRYOCZjx8hXr42wIaVLl YcNr9r+uQkRRsud/nAT0eZbADQ57nno8EXYrQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=aet/aXVnQY3M3DJkssNRvfM2Xjne+7wCV/FN6RXf1dQFrB/XhLCSUFk7jI2sEDQ27y zM4d2HkmByjxQ0nEq2FktO+YOZcqOj0Uwkq0SLryFbbdcam2tCETyvxwWGV2NoA/redd M6AHDjyYel3npX1w0VzzcG6WcM+qiLWfOjG/Q= Received: by 10.204.83.215 with SMTP id g23mr4999124bkl.211.1289236030919; Mon, 08 Nov 2010 09:07:10 -0800 (PST) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id p34sm103871bkf.3.2010.11.08.09.07.07 (version=SSLv3 cipher=RC4-MD5); Mon, 08 Nov 2010 09:07:08 -0800 (PST) Sender: Alexander Motin Message-ID: <4CD82E2A.3070407@FreeBSD.org> Date: Mon, 08 Nov 2010 19:06:50 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Joerg Schilling References: <4CD45209.5010607@FreeBSD.org> <20101105192028.GA68728@alchemy.franken.de> <4cd822df.o/wBtwsNCXiy8xZn%Joerg.Schilling@fokus.fraunhofer.de> In-Reply-To: <4cd822df.o/wBtwsNCXiy8xZn%Joerg.Schilling@fokus.fraunhofer.de> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-scsi@freebsd.org, freebsd-current@freebsd.org, freebsd-stable@freebsd.org, marius@alchemy.franken.de Subject: Re: Sense fetching [Was: cdrtools /devel ...] X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2010 17:07:12 -0000 Joerg Schilling wrote: > Marius Strobl wrote: >> On Fri, Nov 05, 2010 at 08:50:49PM +0200, Alexander Motin wrote: >>> 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. > > Your patch to libscg looks definitely OK if we only look at the new corrected > kernel driver behavior. > > There is a problem: > > In case that there is a sense data residual > 0, libscg will asume that there > is less sense data that really present in case that a "new" libscg is runnung > on an old kernel. > > Given the fact that many drives will probably only return 18 bytes of sense > data, this will happen every time libscg is told to fetch more sense than the > drive is willing to return. > > Is there a way to distinct an old kernel from a new one? I don't see the problem. Previous kernel in most cases reported sesnse_resid == 0, lying that there is more sense data then really is. New one should report real (often positive) value. In both cases sesnse_resid value measured from the value submitted to the kernel. >>> 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. > > This is what we need! Agree. >>> 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. > > I see no advantage in removing the call to fillbytes(). scgcheck tests how much sense data received by counting 0x00 and 0xff bytes. Zero-filling response buffer breaks that check. Though I have no idea if other crdtools' applications depend on these zeros. There could be some internal inconsistency. >> Please don't commit this to the port directly but let it loop back >> via upstream (CC'ed) instead, otherwise we would need to obey the >> following, which is undesirable, especially if these really are >> mostly cosmetic issues: >> /* >> * Warning: you may change this source, but if you do that >> * you need to change the _scg_version and _scg_auth* string below. >> * You may not return "schily" for an SCG_AUTHOR request anymore. >> * Choose your name instead of "schily" and make clear that the version >> * string is related to a modified source. >> */ >> >>> 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. > > Did you test a modified libscg on an unmodified kernel? Unmodified kernel by default doesn't return any sense data at all for new CAM-based ATA -- this changes should be invariant. New scgcheck runs same bad as old. It just can't become worse. :) Legacy atapicam wrapper ignores sense_len on input and doesn't fill sense_resig on output -- I haven't tested, but it also should be invariant. -- Alexander Motin From owner-freebsd-scsi@FreeBSD.ORG Mon Nov 8 17:23:31 2010 Return-Path: Delivered-To: freebsd-scsi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4F5331065672 for ; Mon, 8 Nov 2010 17:23:31 +0000 (UTC) (envelope-from joerg.schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com) Received: from relay01-haj2.antispameurope.com (relay01-haj2.antispameurope.com [83.246.65.51]) by mx1.freebsd.org (Postfix) with ESMTP id D19A08FC17 for ; Mon, 8 Nov 2010 17:23:30 +0000 (UTC) Received: by relay01-haj2.antispameurope.com (ASE-Secure-MTA, from userid 1000) id 210EF160098; Mon, 8 Nov 2010 18:23:28 +0100 (CET) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by relay01-haj2.antispameurope.com (ASE-Secure-MTA) with ESMTP id 7C4EB160082; Mon, 8 Nov 2010 18:23:26 +0100 (CET) Received: from EXCHSRV.fokus.fraunhofer.de (bohr.fokus.fraunhofer.de [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.14.2/8.14.2) with SMTP id oA8HNQ3s028569; Mon, 8 Nov 2010 18:23:26 +0100 (MET) Received: from rigel ([10.147.65.195]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Mon, 8 Nov 2010 18:23:26 +0100 Date: Mon, 08 Nov 2010 18:23:22 +0100 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) To: mav@FreeBSD.org Message-ID: <4cd8320a.U7/OjtLLBVtE4dTy%Joerg.Schilling@fokus.fraunhofer.de> References: <4CD45209.5010607@FreeBSD.org> <20101105192028.GA68728@alchemy.franken.de> <4cd822df.o/wBtwsNCXiy8xZn%Joerg.Schilling@fokus.fraunhofer.de> <4CD82E2A.3070407@FreeBSD.org> In-Reply-To: <4CD82E2A.3070407@FreeBSD.org> User-Agent: nail 11.22 3/20/05 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 08 Nov 2010 17:23:26.0747 (UTC) FILETIME=[A76DB6B0:01CB7F69] Cc: freebsd-scsi@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org, marius@alchemy.franken.de Subject: Re: Sense fetching [Was: cdrtools /devel ...] X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2010 17:23:31 -0000 Alexander Motin wrote: > > Your patch to libscg looks definitely OK if we only look at the new corrected > > kernel driver behavior. > > > > There is a problem: > > > > In case that there is a sense data residual > 0, libscg will asume that there > > is less sense data that really present in case that a "new" libscg is runnung > > on an old kernel. > > > > Given the fact that many drives will probably only return 18 bytes of sense > > data, this will happen every time libscg is told to fetch more sense than the > > drive is willing to return. > > > > Is there a way to distinct an old kernel from a new one? > > I don't see the problem. Previous kernel in most cases reported > sesnse_resid == 0, lying that there is more sense data then really is. > New one should report real (often positive) value. In both cases > sesnse_resid value measured from the value submitted to the kernel. Did the old kernel return a zero sense_resid for any implemented SCSI transport? Libscg is a generic SCSI transport library and cdrecord is just one user of this lib. > > I see no advantage in removing the call to fillbytes(). > > scgcheck tests how much sense data received by counting 0x00 and 0xff > bytes. Zero-filling response buffer breaks that check. Though I have no > idea if other crdtools' applications depend on these zeros. There could > be some internal inconsistency. O, I need to check other low level transport adaptation layers and think about this statement. > > Did you test a modified libscg on an unmodified kernel? > > Unmodified kernel by default doesn't return any sense data at all for > new CAM-based ATA -- this changes should be invariant. New scgcheck runs > same bad as old. It just can't become worse. :) > > Legacy atapicam wrapper ignores sense_len on input and doesn't fill > sense_resig on output -- I haven't tested, but it also should be invariant. I am not only talking about ATAPI but abut SCSI in general. Do you know the CAM behavior for other SCSI transports? Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From owner-freebsd-scsi@FreeBSD.ORG Mon Nov 8 17:37:14 2010 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A4C541065679; Mon, 8 Nov 2010 17:37:14 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 2B2458FC32; Mon, 8 Nov 2010 17:37:13 +0000 (UTC) Received: by gwj16 with SMTP id 16so3708623gwj.13 for ; Mon, 08 Nov 2010 09:37:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=J6iMJgoeWVi8OfHg7wJvIJktNxMfinvbWbpZDwyVoMM=; b=N3dxE/P7PSaaZHVB+cjmJML6yL9AVXJJFNVAbFmSfsMDpERNxFHaRcSIV1hEMAYB3P qFOWxtCjgYWbxkx5caGuLXo98jP1SVksBjh9WuIJ41qfco7MsHG5iGH4RTk1qx7rNNwU 2SU6TGDVMg+R9MO1bQ0BG0YuahnjJKqO6Ou6o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=bKyHCwuueJ/v8BgRu8SHAQcomYuFQ1UUHpTb7F8uigb/cvfHAa52TvUc7O6jnAPFDM mnlhfNR8+vqjeHvUhalIHIRMZms3G8LGl80cGvY8byZQoyhwmY6+6c7Pyu29ZBXYQJkV fJW75t1MJ0UpZjh1UFitr1p9Lr5SrVNJ/u1p4= Received: by 10.204.60.199 with SMTP id q7mr684335bkh.39.1289237832362; Mon, 08 Nov 2010 09:37:12 -0800 (PST) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id p22sm126133bkp.21.2010.11.08.09.37.10 (version=SSLv3 cipher=RC4-MD5); Mon, 08 Nov 2010 09:37:11 -0800 (PST) Sender: Alexander Motin Message-ID: <4CD83535.1010008@FreeBSD.org> Date: Mon, 08 Nov 2010 19:36:53 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Joerg Schilling References: <4CD45209.5010607@FreeBSD.org> <20101105192028.GA68728@alchemy.franken.de> <4cd822df.o/wBtwsNCXiy8xZn%Joerg.Schilling@fokus.fraunhofer.de> <4CD82E2A.3070407@FreeBSD.org> <4cd8320a.U7/OjtLLBVtE4dTy%Joerg.Schilling@fokus.fraunhofer.de> In-Reply-To: <4cd8320a.U7/OjtLLBVtE4dTy%Joerg.Schilling@fokus.fraunhofer.de> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-scsi@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org, marius@alchemy.franken.de Subject: Re: Sense fetching [Was: cdrtools /devel ...] X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2010 17:37:14 -0000 Joerg Schilling wrote: > Alexander Motin wrote: >>> Your patch to libscg looks definitely OK if we only look at the new corrected >>> kernel driver behavior. >>> >>> There is a problem: >>> >>> In case that there is a sense data residual > 0, libscg will asume that there >>> is less sense data that really present in case that a "new" libscg is runnung >>> on an old kernel. >>> >>> Given the fact that many drives will probably only return 18 bytes of sense >>> data, this will happen every time libscg is told to fetch more sense than the >>> drive is willing to return. >>> >>> Is there a way to distinct an old kernel from a new one? >> I don't see the problem. Previous kernel in most cases reported >> sesnse_resid == 0, lying that there is more sense data then really is. >> New one should report real (often positive) value. In both cases >> sesnse_resid value measured from the value submitted to the kernel. > > Did the old kernel return a zero sense_resid for any implemented SCSI > transport? Libscg is a generic SCSI transport library and cdrecord is just one > user of this lib. Not sure I understand your question. Zero sesnse_resid is absolutely normal situation if device gave same amount of sense as application requested. As I can see, many of SCSI controllers report sesnse_resid properly. I may assume that some, like atapicd don't -- in that case you'll also see 0 there. >>> I see no advantage in removing the call to fillbytes(). >> scgcheck tests how much sense data received by counting 0x00 and 0xff >> bytes. Zero-filling response buffer breaks that check. Though I have no >> idea if other crdtools' applications depend on these zeros. There could >> be some internal inconsistency. > > O, I need to check other low level transport adaptation layers and think about > this statement. > >>> Did you test a modified libscg on an unmodified kernel? >> Unmodified kernel by default doesn't return any sense data at all for >> new CAM-based ATA -- this changes should be invariant. New scgcheck runs >> same bad as old. It just can't become worse. :) >> >> Legacy atapicam wrapper ignores sense_len on input and doesn't fill >> sense_resig on output -- I haven't tested, but it also should be invariant. > > I am not only talking about ATAPI but abut SCSI in general. > > Do you know the CAM behavior for other SCSI transports? I don't have real SCSI CD to test, but a as I can see, most of SCSI controllers return sense data automatically. Sense fetching changes should not affect/break anything there. -- Alexander Motin From owner-freebsd-scsi@FreeBSD.ORG Thu Nov 11 10:05:40 2010 Return-Path: Delivered-To: freebsd-scsi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8CCF01065674 for ; Thu, 11 Nov 2010 10:05:40 +0000 (UTC) (envelope-from joerg.schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com) Received: from relay03-haj2.antispameurope.com (relay03-haj2.antispameurope.com [83.246.65.53]) by mx1.freebsd.org (Postfix) with ESMTP id 017118FC12 for ; Thu, 11 Nov 2010 10:05:39 +0000 (UTC) Received: by relay03-haj2.antispameurope.com (ASE-Secure-MTA, from userid 1000) id 19FF463C1F6; Thu, 11 Nov 2010 11:05:37 +0100 (CET) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by relay03-haj2.antispameurope.com (ASE-Secure-MTA) with ESMTP id 34ED063C239; Thu, 11 Nov 2010 11:05:36 +0100 (CET) Received: from EXCHSRV.fokus.fraunhofer.de (bohr.fokus.fraunhofer.de [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.14.2/8.14.2) with SMTP id oABA5ZAW000889; Thu, 11 Nov 2010 11:05:35 +0100 (MET) Received: from rigel ([10.147.65.195]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 11 Nov 2010 11:05:36 +0100 Date: Thu, 11 Nov 2010 11:05:35 +0100 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) To: mav@FreeBSD.org Message-ID: <4cdbbfef.v4cr/k2jZr9gdpyF%Joerg.Schilling@fokus.fraunhofer.de> References: <4CD45209.5010607@FreeBSD.org> <20101105192028.GA68728@alchemy.franken.de> <4cd822df.o/wBtwsNCXiy8xZn%Joerg.Schilling@fokus.fraunhofer.de> <4CD82E2A.3070407@FreeBSD.org> <4cd8320a.U7/OjtLLBVtE4dTy%Joerg.Schilling@fokus.fraunhofer.de> <4CD83535.1010008@FreeBSD.org> In-Reply-To: <4CD83535.1010008@FreeBSD.org> User-Agent: nail 11.22 3/20/05 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 11 Nov 2010 10:05:36.0084 (UTC) FILETIME=[FC21E940:01CB8187] Cc: freebsd-scsi@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org, marius@alchemy.franken.de Subject: Re: Sense fetching [Was: cdrtools /devel ...] X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 10:05:40 -0000 Alexander Motin wrote: > >>> Given the fact that many drives will probably only return 18 bytes of sense > >>> data, this will happen every time libscg is told to fetch more sense than the > >>> drive is willing to return. > >>> > >>> Is there a way to distinct an old kernel from a new one? > >> I don't see the problem. Previous kernel in most cases reported > >> sesnse_resid == 0, lying that there is more sense data then really is. > >> New one should report real (often positive) value. In both cases > >> sesnse_resid value measured from the value submitted to the kernel. > > > > Did the old kernel return a zero sense_resid for any implemented SCSI > > transport? Libscg is a generic SCSI transport library and cdrecord is just one > > user of this lib. > > Not sure I understand your question. Zero sesnse_resid is absolutely > normal situation if device gave same amount of sense as application > requested. As I can see, many of SCSI controllers report sesnse_resid > properly. I may assume that some, like atapicd don't -- in that case > you'll also see 0 there. FreeBSD-CAM did try to fetcth more than 18 bytes of sense data and it may be that some drives did return only 18 bytes. In this case, I would asume that there is a resid > 0. > > Do you know the CAM behavior for other SCSI transports? > > I don't have real SCSI CD to test, but a as I can see, most of SCSI > controllers return sense data automatically. Sense fetching changes > should not affect/break anything there. The question still remains whether the previous implementation did return resid > 0 in some cases. In this case, I would need to implement both variants in the libscg adaption layer and I would need to know whether I am running on an old version or on a new version kernel. Do you know of a simple method to implement this distinction? Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From owner-freebsd-scsi@FreeBSD.ORG Thu Nov 11 10:29:12 2010 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 06340106564A; Thu, 11 Nov 2010 10:29:12 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 27D458FC08; Thu, 11 Nov 2010 10:29:10 +0000 (UTC) Received: by bwz2 with SMTP id 2so1745219bwz.13 for ; Thu, 11 Nov 2010 02:29:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=IBkmn7OjqaG8WH8tmY8jbDAX2tB+EFBeKS8TkX98YRo=; b=Im8CNONFvQTsxaC/ORkRK9l2KSrirGk9O0x3ONTGEzEL/QHLLUNfB6sC6ykQWW4U5A cwNvB6wnEgz22xVgUABtb41mQFxhj3Vi1OUAGAU2MsGBMf7rfkS43QgZjsr75VLIMeD7 otLa5gKixxFsoncTuRUD+qnbFyw/vDdMwHRbM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=puHTSR07x7EZyr2Yer1RraanUVyXIpAjDQ+4c97ebMUP27VTHwyTzNuwCy6te2PyS1 7Bajt99mILHleAdHp8+ip8npwIRgLzTe+ic0PurArYm3rPDOgb13XnM/A8O3bx0t2HHc Kos4RANrezdPhpCV2Y+aKY8SzBFJDEThs7NvY= Received: by 10.204.27.20 with SMTP id g20mr1051611bkc.114.1289471349947; Thu, 11 Nov 2010 02:29:09 -0800 (PST) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id r21sm845182bkj.22.2010.11.11.02.29.07 (version=SSLv3 cipher=RC4-MD5); Thu, 11 Nov 2010 02:29:08 -0800 (PST) Sender: Alexander Motin Message-ID: <4CDBC55B.1040307@FreeBSD.org> Date: Thu, 11 Nov 2010 12:28:43 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Joerg Schilling References: <4CD45209.5010607@FreeBSD.org> <20101105192028.GA68728@alchemy.franken.de> <4cd822df.o/wBtwsNCXiy8xZn%Joerg.Schilling@fokus.fraunhofer.de> <4CD82E2A.3070407@FreeBSD.org> <4cd8320a.U7/OjtLLBVtE4dTy%Joerg.Schilling@fokus.fraunhofer.de> <4CD83535.1010008@FreeBSD.org> <4cdbbfef.v4cr/k2jZr9gdpyF%Joerg.Schilling@fokus.fraunhofer.de> In-Reply-To: <4cdbbfef.v4cr/k2jZr9gdpyF%Joerg.Schilling@fokus.fraunhofer.de> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-scsi@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org, marius@alchemy.franken.de Subject: Re: Sense fetching [Was: cdrtools /devel ...] X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 10:29:12 -0000 Joerg Schilling wrote: > Alexander Motin wrote: >>>>> Given the fact that many drives will probably only return 18 bytes of sense >>>>> data, this will happen every time libscg is told to fetch more sense than the >>>>> drive is willing to return. >>>>> >>>>> Is there a way to distinct an old kernel from a new one? >>>> I don't see the problem. Previous kernel in most cases reported >>>> sesnse_resid == 0, lying that there is more sense data then really is. >>>> New one should report real (often positive) value. In both cases >>>> sesnse_resid value measured from the value submitted to the kernel. >>> Did the old kernel return a zero sense_resid for any implemented SCSI >>> transport? Libscg is a generic SCSI transport library and cdrecord is just one >>> user of this lib. >> Not sure I understand your question. Zero sesnse_resid is absolutely >> normal situation if device gave same amount of sense as application >> requested. As I can see, many of SCSI controllers report sesnse_resid >> properly. I may assume that some, like atapicd don't -- in that case >> you'll also see 0 there. > > FreeBSD-CAM did try to fetcth more than 18 bytes of sense data and it may be > that some drives did return only 18 bytes. In this case, I would asume that > there is a resid > 0. As I have said, many drivers return resid properly, but some others - don't. These changes should just improve situation. >>> Do you know the CAM behavior for other SCSI transports? >> I don't have real SCSI CD to test, but a as I can see, most of SCSI >> controllers return sense data automatically. Sense fetching changes >> should not affect/break anything there. > > The question still remains whether the previous implementation did return resid >> 0 in some cases. In this case, I would need to implement both variants in the > libscg adaption layer and I would need to know whether I am running on an old > version or on a new version kernel. Do you know of a simple method to implement > this distinction? Yes, some drivers were permanently reporting zero resid, while others (mostly real SCSI) were reporting proper values. Now it is the same, just more cases should work properly. Why do you want/need to distinguish them? You should already handle non-zero resid properly. Zero resid may be wrong in some cases, but at first I don't see fatal problem from it and at second I don't see what can you do about it. If I am missing something - sorry, explain it to me please. -- Alexander Motin From owner-freebsd-scsi@FreeBSD.ORG Thu Nov 11 10:33:07 2010 Return-Path: Delivered-To: freebsd-scsi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 89D0810656A7 for ; Thu, 11 Nov 2010 10:33:07 +0000 (UTC) (envelope-from joerg.schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com) Received: from relay01-haj2.antispameurope.com (relay01-haj2.antispameurope.com [83.246.65.51]) by mx1.freebsd.org (Postfix) with ESMTP id 16C9E8FC1E for ; Thu, 11 Nov 2010 10:33:06 +0000 (UTC) Received: by relay01-haj2.antispameurope.com (ASE-Secure-MTA, from userid 1000) id D0FA71600DE; Thu, 11 Nov 2010 11:33:04 +0100 (CET) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by relay01-haj2.antispameurope.com (ASE-Secure-MTA) with ESMTP id 31E5B1600B1; Thu, 11 Nov 2010 11:33:03 +0100 (CET) Received: from EXCHSRV.fokus.fraunhofer.de (bohr.fokus.fraunhofer.de [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.14.2/8.14.2) with SMTP id oABAX3S6001742; Thu, 11 Nov 2010 11:33:03 +0100 (MET) Received: from rigel ([10.147.65.195]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 11 Nov 2010 11:33:04 +0100 Date: Thu, 11 Nov 2010 11:33:03 +0100 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) To: mav@FreeBSD.org Message-ID: <4cdbc65f.bo+mYNFB2GPwXmq7%Joerg.Schilling@fokus.fraunhofer.de> References: <4CD45209.5010607@FreeBSD.org> <20101105192028.GA68728@alchemy.franken.de> <4cd822df.o/wBtwsNCXiy8xZn%Joerg.Schilling@fokus.fraunhofer.de> <4CD82E2A.3070407@FreeBSD.org> <4cd8320a.U7/OjtLLBVtE4dTy%Joerg.Schilling@fokus.fraunhofer.de> <4CD83535.1010008@FreeBSD.org> <4cdbbfef.v4cr/k2jZr9gdpyF%Joerg.Schilling@fokus.fraunhofer.de> <4CDBC55B.1040307@FreeBSD.org> In-Reply-To: <4CDBC55B.1040307@FreeBSD.org> User-Agent: nail 11.22 3/20/05 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 11 Nov 2010 10:33:04.0173 (UTC) FILETIME=[D27855D0:01CB818B] Cc: freebsd-scsi@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org, marius@alchemy.franken.de Subject: Re: Sense fetching [Was: cdrtools /devel ...] X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 10:33:07 -0000 Alexander Motin wrote: > > The question still remains whether the previous implementation did return resid > >> 0 in some cases. In this case, I would need to implement both variants in the > > libscg adaption layer and I would need to know whether I am running on an old > > version or on a new version kernel. Do you know of a simple method to implement > > this distinction? > > Yes, some drivers were permanently reporting zero resid, while others > (mostly real SCSI) were reporting proper values. Now it is the same, > just more cases should work properly. > > Why do you want/need to distinguish them? You should already handle > non-zero resid properly. Zero resid may be wrong in some cases, but at > first I don't see fatal problem from it and at second I don't see what > can you do about it. > > If I am missing something - sorry, explain it to me please. Compare the number of sense bytes I like to request (18) with the number previous FreeBSD versions did actually request. It is obvious that in case there is a resid reported onm an old kernel, libscg (with your chanhge) would believe that probably less that the absolute minumum of sense data is available. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From owner-freebsd-scsi@FreeBSD.ORG Thu Nov 11 13:07:31 2010 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6A96E1065694; Thu, 11 Nov 2010 13:07:31 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 884CB8FC08; Thu, 11 Nov 2010 13:07:30 +0000 (UTC) Received: by bwz2 with SMTP id 2so1889170bwz.13 for ; Thu, 11 Nov 2010 05:07:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=a+pDfTT/zJsOxqc61Ol7WgkltbK1q8HNA3j1kujoJrQ=; b=rb+dMtjoYOvHnUg+J03C+pDstOgGpdMNfsp4e8BRN+8ZWj0DCHCdTW/iB+twBRdpjF l0HcEfypqvdpt48s/LyToeZgC0C1/pubTl2s31KS4n62INEt0/ftwos2wokLnM996k5B ytZaY5hX3KdxvtArO2IIgGiZ482aSV0ZXmTxM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=FxafP9goUSkzLj23mec3y3Ogy48FcQJlI+3u0WibEwH4nALNl/xwC7zgVa0gl2NDBK u5rJr8at9SlxI+0n4lHyB8hfCCsTA3Nr+KxdHfnrX0GAGTPjQGU14Bus/ijw5KdDbk20 m9X4vP3sZzj0SdFbV3zYUNFqaYvtzlurVS4E4= Received: by 10.204.76.67 with SMTP id b3mr1332240bkk.62.1289480848796; Thu, 11 Nov 2010 05:07:28 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 4sm919804bki.1.2010.11.11.05.07.26 (version=SSLv3 cipher=RC4-MD5); Thu, 11 Nov 2010 05:07:27 -0800 (PST) Sender: Alexander Motin Message-ID: <4CDBEA8B.1020306@FreeBSD.org> Date: Thu, 11 Nov 2010 15:07:23 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.24 (X11/20100402) MIME-Version: 1.0 To: Joerg Schilling References: <4CD45209.5010607@FreeBSD.org> <20101105192028.GA68728@alchemy.franken.de> <4cd822df.o/wBtwsNCXiy8xZn%Joerg.Schilling@fokus.fraunhofer.de> <4CD82E2A.3070407@FreeBSD.org> <4cd8320a.U7/OjtLLBVtE4dTy%Joerg.Schilling@fokus.fraunhofer.de> <4CD83535.1010008@FreeBSD.org> <4cdbbfef.v4cr/k2jZr9gdpyF%Joerg.Schilling@fokus.fraunhofer.de> <4CDBC55B.1040307@FreeBSD.org> <4cdbc65f.bo+mYNFB2GPwXmq7%Joerg.Schilling@fokus.fraunhofer.de> In-Reply-To: <4cdbc65f.bo+mYNFB2GPwXmq7%Joerg.Schilling@fokus.fraunhofer.de> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-scsi@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org, marius@alchemy.franken.de Subject: Re: Sense fetching [Was: cdrtools /devel ...] X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 13:07:31 -0000 Joerg Schilling wrote: > Alexander Motin wrote: > >>> The question still remains whether the previous implementation did return resid >>>> 0 in some cases. In this case, I would need to implement both variants in the >>> libscg adaption layer and I would need to know whether I am running on an old >>> version or on a new version kernel. Do you know of a simple method to implement >>> this distinction? >> Yes, some drivers were permanently reporting zero resid, while others >> (mostly real SCSI) were reporting proper values. Now it is the same, >> just more cases should work properly. >> >> Why do you want/need to distinguish them? You should already handle >> non-zero resid properly. Zero resid may be wrong in some cases, but at >> first I don't see fatal problem from it and at second I don't see what >> can you do about it. >> >> If I am missing something - sorry, explain it to me please. > > Compare the number of sense bytes I like to request (18) with the number > previous FreeBSD versions did actually request. It is obvious that in case > there is a resid reported onm an old kernel, libscg (with your chanhge) would > believe that probably less that the absolute minumum of sense data is available. Kernel code I have changed affects only controllers without automatic sense fetching. For such controllers CAM previously always reported zero sense_resid, independently of requested size (which actually was also ignored in this case). So previously whatever you asked for 18 or 32 bytes - sense_resid was always zero, like if you got full 18 or 32 bytes. That was wrong. Now, in the same situation, if device wants to return let's say 20 bytes -- you will get 0 and 12 bytes of sense_resid respectively, meaning 18 and 20 bytes of received sense. AFAIK sense_resid always measured from the requested sense_len. In my patch for libscg you may see that I have changed both request and response paths. Resulted sense_count should be absolutely the same. -- Alexander Motin From owner-freebsd-scsi@FreeBSD.ORG Thu Nov 11 13:17:28 2010 Return-Path: Delivered-To: freebsd-scsi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8317B1065673 for ; Thu, 11 Nov 2010 13:17:28 +0000 (UTC) (envelope-from joerg.schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com) Received: from relay01-haj2.antispameurope.com (relay01-haj2.antispameurope.com [83.246.65.51]) by mx1.freebsd.org (Postfix) with ESMTP id 0E7728FC1E for ; Thu, 11 Nov 2010 13:17:27 +0000 (UTC) Received: by relay01-haj2.antispameurope.com (ASE-Secure-MTA, from userid 1000) id C2161160068; Thu, 11 Nov 2010 14:17:26 +0100 (CET) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by relay01-haj2.antispameurope.com (ASE-Secure-MTA) with ESMTP id 622DE160049; Thu, 11 Nov 2010 14:17:25 +0100 (CET) Received: from EXCHSRV.fokus.fraunhofer.de (bohr.fokus.fraunhofer.de [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.14.2/8.14.2) with SMTP id oABDHOf3007031; Thu, 11 Nov 2010 14:17:24 +0100 (MET) Received: from rigel ([10.147.65.195]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 11 Nov 2010 14:17:24 +0100 Date: Thu, 11 Nov 2010 14:17:21 +0100 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) To: mav@FreeBSD.org Message-ID: <4cdbece1.EWYSqdvnx6XWF8EF%Joerg.Schilling@fokus.fraunhofer.de> References: <4CD45209.5010607@FreeBSD.org> <20101105192028.GA68728@alchemy.franken.de> <4cd822df.o/wBtwsNCXiy8xZn%Joerg.Schilling@fokus.fraunhofer.de> <4CD82E2A.3070407@FreeBSD.org> <4cd8320a.U7/OjtLLBVtE4dTy%Joerg.Schilling@fokus.fraunhofer.de> <4CD83535.1010008@FreeBSD.org> <4cdbbfef.v4cr/k2jZr9gdpyF%Joerg.Schilling@fokus.fraunhofer.de> <4CDBC55B.1040307@FreeBSD.org> <4cdbc65f.bo+mYNFB2GPwXmq7%Joerg.Schilling@fokus.fraunhofer.de> <4CDBEA8B.1020306@FreeBSD.org> In-Reply-To: <4CDBEA8B.1020306@FreeBSD.org> User-Agent: nail 11.22 3/20/05 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 11 Nov 2010 13:17:24.0928 (UTC) FILETIME=[C7F02400:01CB81A2] Cc: freebsd-scsi@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org, marius@alchemy.franken.de Subject: Re: Sense fetching [Was: cdrtools /devel ...] X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 13:17:28 -0000 Alexander Motin wrote: > > Compare the number of sense bytes I like to request (18) with the number > > previous FreeBSD versions did actually request. It is obvious that in case > > there is a resid reported onm an old kernel, libscg (with your chanhge) would > > believe that probably less that the absolute minumum of sense data is available. > > Kernel code I have changed affects only controllers without automatic > sense fetching. For such controllers CAM previously always reported zero > sense_resid, independently of requested size (which actually was also > ignored in this case). So previously whatever you asked for 18 or 32 > bytes - sense_resid was always zero, like if you got full 18 or 32 > bytes. That was wrong. Now, in the same situation, if device wants to > return let's say 20 bytes -- you will get 0 and 12 bytes of sense_resid > respectively, meaning 18 and 20 bytes of received sense. > > AFAIK sense_resid always measured from the requested sense_len. In my > patch for libscg you may see that I have changed both request and > response paths. Resulted sense_count should be absolutely the same. What is the requested size with the various HBAs in earlier kernels? Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From owner-freebsd-scsi@FreeBSD.ORG Thu Nov 11 13:28:52 2010 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 90E44106566B; Thu, 11 Nov 2010 13:28:52 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id B53498FC08; Thu, 11 Nov 2010 13:28:51 +0000 (UTC) Received: by fxm19 with SMTP id 19so1277894fxm.13 for ; Thu, 11 Nov 2010 05:28:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=yZyM3gleemwPTCnpdko7NZf+EbCOFHP1Uk2zwbC8N44=; b=DR91x+fwCrStGLnv6wxRB3RVyU8cP216qRnN1R0Az5UqXQLRqdaHFTFgrKySZ70RdY B9v9PG0rLOHLoA2H6tCl7t3HbN+SpJqusw7zBVyU4o3OmmJRZuv691253J53HqsDe4V6 xda6Pi6StgjmZ3PXxZlpm45cdl2noV0drsK+k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=OBeNX+ckUDfEF0K2C+NI2OQPDCu89qKyy2WFojEswsJexiR+4dr9xI0fkPv+GeotBR BOEJxdYKYeBOai/BD1wZCUUgqdKbXvFkrKfnl0nXIAIkUAFzq0PUe0Rwq5INcKCdfG+T QzyrCPTgyS7I8neqtrRGx8tgyz8obpbCS1gt0= Received: by 10.204.54.82 with SMTP id p18mr1306551bkg.205.1289482130301; Thu, 11 Nov 2010 05:28:50 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id p22sm926623bkp.21.2010.11.11.05.28.48 (version=SSLv3 cipher=RC4-MD5); Thu, 11 Nov 2010 05:28:49 -0800 (PST) Sender: Alexander Motin Message-ID: <4CDBEF8D.5080001@FreeBSD.org> Date: Thu, 11 Nov 2010 15:28:45 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.24 (X11/20100402) MIME-Version: 1.0 To: Joerg Schilling References: <4CD45209.5010607@FreeBSD.org> <20101105192028.GA68728@alchemy.franken.de> <4cd822df.o/wBtwsNCXiy8xZn%Joerg.Schilling@fokus.fraunhofer.de> <4CD82E2A.3070407@FreeBSD.org> <4cd8320a.U7/OjtLLBVtE4dTy%Joerg.Schilling@fokus.fraunhofer.de> <4CD83535.1010008@FreeBSD.org> <4cdbbfef.v4cr/k2jZr9gdpyF%Joerg.Schilling@fokus.fraunhofer.de> <4CDBC55B.1040307@FreeBSD.org> <4cdbc65f.bo+mYNFB2GPwXmq7%Joerg.Schilling@fokus.fraunhofer.de> <4CDBEA8B.1020306@FreeBSD.org> <4cdbece1.EWYSqdvnx6XWF8EF%Joerg.Schilling@fokus.fraunhofer.de> In-Reply-To: <4cdbece1.EWYSqdvnx6XWF8EF%Joerg.Schilling@fokus.fraunhofer.de> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-scsi@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org, marius@alchemy.franken.de Subject: Re: Sense fetching [Was: cdrtools /devel ...] X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 13:28:52 -0000 Joerg Schilling wrote: > Alexander Motin wrote: > >>> Compare the number of sense bytes I like to request (18) with the number >>> previous FreeBSD versions did actually request. It is obvious that in case >>> there is a resid reported onm an old kernel, libscg (with your chanhge) would >>> believe that probably less that the absolute minumum of sense data is available. >> Kernel code I have changed affects only controllers without automatic >> sense fetching. For such controllers CAM previously always reported zero >> sense_resid, independently of requested size (which actually was also >> ignored in this case). So previously whatever you asked for 18 or 32 >> bytes - sense_resid was always zero, like if you got full 18 or 32 >> bytes. That was wrong. Now, in the same situation, if device wants to >> return let's say 20 bytes -- you will get 0 and 12 bytes of sense_resid >> respectively, meaning 18 and 20 bytes of received sense. >> >> AFAIK sense_resid always measured from the requested sense_len. In my >> patch for libscg you may see that I have changed both request and >> response paths. Resulted sense_count should be absolutely the same. > > What is the requested size with the various HBAs in earlier kernels? For HBAs with automatic sense fetching -- as passed in sence_len request field. In case of libscg it was SSD_FULL_SIZE before and I've set it to be real value now. Returned sense_resid should be real in both cases, respecting submitted sense_len. For HBAs without sense fetching, CAM was always requesting SSD_FULL_SIZE and returned fake zero sense_resid, like if it just completely fulfilled sense_len from request. Now it should start honor sense_len on request and return real sense_resid on reply, relative to sense_len. -- Alexander Motin From owner-freebsd-scsi@FreeBSD.ORG Thu Nov 11 13:45:49 2010 Return-Path: Delivered-To: freebsd-scsi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 64B9A106566C for ; Thu, 11 Nov 2010 13:45:49 +0000 (UTC) (envelope-from joerg.schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com) Received: from relay03-haj2.antispameurope.com (relay03-haj2.antispameurope.com [83.246.65.53]) by mx1.freebsd.org (Postfix) with ESMTP id E29E18FC1C for ; Thu, 11 Nov 2010 13:45:48 +0000 (UTC) Received: by relay03-haj2.antispameurope.com (ASE-Secure-MTA, from userid 1000) id CE1FD63C083; Thu, 11 Nov 2010 14:45:45 +0100 (CET) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by relay03-haj2.antispameurope.com (ASE-Secure-MTA) with ESMTP id B195C63C24E; Thu, 11 Nov 2010 14:45:42 +0100 (CET) Received: from EXCHSRV.fokus.fraunhofer.de (bohr.fokus.fraunhofer.de [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.14.2/8.14.2) with SMTP id oABDjg5P007828; Thu, 11 Nov 2010 14:45:42 +0100 (MET) Received: from rigel ([10.147.65.195]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 11 Nov 2010 14:45:42 +0100 Date: Thu, 11 Nov 2010 14:45:42 +0100 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) To: mav@FreeBSD.org Message-ID: <4cdbf386.cAc+PtgM+41jseN5%Joerg.Schilling@fokus.fraunhofer.de> References: <4CD45209.5010607@FreeBSD.org> <20101105192028.GA68728@alchemy.franken.de> <4cd822df.o/wBtwsNCXiy8xZn%Joerg.Schilling@fokus.fraunhofer.de> <4CD82E2A.3070407@FreeBSD.org> <4cd8320a.U7/OjtLLBVtE4dTy%Joerg.Schilling@fokus.fraunhofer.de> <4CD83535.1010008@FreeBSD.org> <4cdbbfef.v4cr/k2jZr9gdpyF%Joerg.Schilling@fokus.fraunhofer.de> <4CDBC55B.1040307@FreeBSD.org> <4cdbc65f.bo+mYNFB2GPwXmq7%Joerg.Schilling@fokus.fraunhofer.de> <4CDBEA8B.1020306@FreeBSD.org> <4cdbece1.EWYSqdvnx6XWF8EF%Joerg.Schilling@fokus.fraunhofer.de> <4CDBEF8D.5080001@FreeBSD.org> In-Reply-To: <4CDBEF8D.5080001@FreeBSD.org> User-Agent: nail 11.22 3/20/05 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 11 Nov 2010 13:45:42.0628 (UTC) FILETIME=[BBD89A40:01CB81A6] Cc: freebsd-scsi@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org, marius@alchemy.franken.de Subject: Re: Sense fetching [Was: cdrtools /devel ...] X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 13:45:49 -0000 Alexander Motin wrote: > > What is the requested size with the various HBAs in earlier kernels? > > For HBAs with automatic sense fetching -- as passed in sence_len request > field. In case of libscg it was SSD_FULL_SIZE before and I've set it to > be real value now. Returned sense_resid should be real in both cases, > respecting submitted sense_len. > > For HBAs without sense fetching, CAM was always requesting SSD_FULL_SIZE > and returned fake zero sense_resid, like if it just completely fulfilled > sense_len from request. Now it should start honor sense_len on request > and return real sense_resid on reply, relative to sense_len. Then your patch to libscg seems to be OK and without risk. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From owner-freebsd-scsi@FreeBSD.ORG Sat Nov 13 02:11:10 2010 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4B288106566B; Sat, 13 Nov 2010 02:11:10 +0000 (UTC) (envelope-from jamesbrandongooch@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id AC4278FC0A; Sat, 13 Nov 2010 02:11:09 +0000 (UTC) Received: by wyb36 with SMTP id 36so605654wyb.13 for ; Fri, 12 Nov 2010 18:11:08 -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; bh=XTZtD7hKiaN8YOXPK3hT+aftPBaAHfLBCbTu3Tf4Keo=; b=oC5Ztad57ScrtV0Dv8/CGBiHVwCqTyM0HZc6lVQtqtMYd5zWQ7kTMllCOtElG4BKsl xcuEgga2bMLYj4hH+uTLBQxuf1eMFFcllTz/oNwLV8zHjMsaiS5TBI8/S/8fpnQr1Bzd d4hIw8PmDv6G6gNTLiG91IkCAzp/xIaJRWgHM= 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; b=Y4qttIXt0J2ILt/McwctD1RAMO5KOolgNHQfvhqkmrykZqd/U9QrgOTp0p3E7xagLA Bw5i8N5IriEatVYIF3xeIRA2a4GIusi5su3ukQ4N5ET/ltOF2eh3+DRfSQ+JBRFZ9XAp DMRfgfHKCeK6/CxChKs/eVkxlY6Y/mn1xch9A= MIME-Version: 1.0 Received: by 10.216.171.75 with SMTP id q53mr2596431wel.74.1289612661936; Fri, 12 Nov 2010 17:44:21 -0800 (PST) Received: by 10.216.12.80 with HTTP; Fri, 12 Nov 2010 17:44:21 -0800 (PST) In-Reply-To: <4CD45209.5010607@FreeBSD.org> References: <4CD45209.5010607@FreeBSD.org> Date: Fri, 12 Nov 2010 19:44:21 -0600 Message-ID: From: Brandon Gooch To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-scsi@freebsd.org, FreeBSD-Current , FreeBSD Stable Subject: Re: Sense fetching [Was: cdrtools /devel ...] X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Nov 2010 02:11:10 -0000 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 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... -Brandon From owner-freebsd-scsi@FreeBSD.ORG Sat Nov 13 09:34:14 2010 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8CAC4106566B; Sat, 13 Nov 2010 09:34:14 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id AE7708FC14; Sat, 13 Nov 2010 09:34:13 +0000 (UTC) Received: by bwz2 with SMTP id 2so3794627bwz.13 for ; Sat, 13 Nov 2010 01:34:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=JYmhMzNeU5OnbnDeUrtS0qRDtJv+dv+6J3HXRmLkOLc=; b=blUU6zzlg0GENwyADU+RZS0V1/ejTnubAGC57nrxVtp7Qjqj4a7aDstkxbslKAEOqh cN/ZpaeXYHpO9y0hhjWC/Hz/yK8p6MJoeFQeBnlBFazkLjpmp9wR/7DVq7g4NiDu8Zsn g4uaAbQAmMFXgrjoT0UjTg/+tryGKpw+GTiMI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=EyHpdeynSoto2XbB2vJRTb08CQJ2MTZNPe5HtvcQibh7KO2SGt6Ef1JJ4oe1YMVoDY q4a5+dkiJRnB7GJsJBmZYWHS47njKIoYgetQES9fF/e8Oeao/2vXe15KbRBhScv4K0JK rW2OoG/RacUEbaakWnj/XMgvPvSW0HykSyNtQ= Received: by 10.204.116.74 with SMTP id l10mr3840744bkq.113.1289640851774; Sat, 13 Nov 2010 01:34:11 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 4sm1950121bki.1.2010.11.13.01.34.08 (version=SSLv3 cipher=RC4-MD5); Sat, 13 Nov 2010 01:34:09 -0800 (PST) Sender: Alexander Motin Message-ID: <4CDE5B8C.4000102@FreeBSD.org> Date: Sat, 13 Nov 2010 11:34:04 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.24 (X11/20100402) MIME-Version: 1.0 To: Brandon Gooch References: <4CD45209.5010607@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-scsi@freebsd.org, FreeBSD-Current , FreeBSD Stable Subject: Re: Sense fetching [Was: cdrtools /devel ...] X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Nov 2010 09:34:14 -0000 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 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. -- Alexander Motin From owner-freebsd-scsi@FreeBSD.ORG Sat Nov 13 18:19:05 2010 Return-Path: Delivered-To: freebsd-scsi@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-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem 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