From owner-freebsd-current@FreeBSD.ORG Wed Feb 20 15:43:58 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 65F1ACA2; Wed, 20 Feb 2013 15:43:58 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bk0-f46.google.com (mail-bk0-f46.google.com [209.85.214.46]) by mx1.freebsd.org (Postfix) with ESMTP id C59B6CF7; Wed, 20 Feb 2013 15:43:57 +0000 (UTC) Received: by mail-bk0-f46.google.com with SMTP id j5so3639114bkw.5 for ; Wed, 20 Feb 2013 07:43:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=KG9DDG7SQOfaMfoJ47hcAvxzicRmQqgC4KgC72aiq/8=; b=FFiynGpNAnZ3KyD38VtQOrgSGVgzwby4HZG6gbtU8SjmD8reElj8sf5k8nZSiL16dB ldnKfep3RM4qyD0IUiRhnrIXNkTsj3E7v8rR91BqP0bP8H2pebdkzFUOPPgRcmX7mher ASUjzFBX2ie5iOVptA/ecp0iYGwmnXdqreyvsD5Gq/JoSHlgBxSDMCTle0CVFRn/5tF2 u6MC13G2X6sOmzmpX71ZO4+tL+xTHGu5M5NGOR6fG9GsBiwDJY36Z0alrGowkkbQ6qSJ IDF8YyjEpKLdf8Ni2ZdBBOZdcL8h7gv9VQ7t6PyPb6vtF8wlktq3dccxWRqLwSnDlWeo VwBQ== X-Received: by 10.205.122.80 with SMTP id gf16mr8835541bkc.130.1361375036615; Wed, 20 Feb 2013 07:43:56 -0800 (PST) Received: from mavbook.mavhome.dp.ua (mavhome.mavhome.dp.ua. [213.227.240.37]) by mx.google.com with ESMTPS id k4sm23510787bkv.18.2013.02.20.07.43.54 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 20 Feb 2013 07:43:55 -0800 (PST) Sender: Alexander Motin Message-ID: <5124EF38.7080302@FreeBSD.org> Date: Wed, 20 Feb 2013 17:43:52 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130125 Thunderbird/17.0.2 MIME-Version: 1.0 To: Joel Dahl Subject: Re: HEAD memsticks broken? [USB/CAM Problems?] References: <20130209073241.GN21730@jd.benders.se> <20130209230939.GQ21730@jd.benders.se> <20130211222105.GC838@jd.benders.se> <201302120851.18810.hselasky@c2i.net> <20130214193707.GD84888@jd.benders.se> <20130216100719.GB47553@jd.benders.se> In-Reply-To: <20130216100719.GB47553@jd.benders.se> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Hans Petter Selasky X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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: Wed, 20 Feb 2013 15:43:58 -0000 On 16.02.2013 12:07, Joel Dahl wrote: > On 14-02-2013 20:37, Joel Dahl wrote: >> On 12-02-2013 8:51, Hans Petter Selasky wrote: >>> On Monday 11 February 2013 23:21:05 Joel Dahl wrote: >>>> On 10-02-2013 0:09, Joel Dahl wrote: >>>>> On 09-02-2013 20:28, Alexander Motin wrote: >>>>>> How long ago that HEAD was built? Could you get full dmesg? I don't >>>>>> think that "PREVENT ALLOW MEDIUM REMOVAL" should cause device drop. "No >>>>>> sense data present" also doesn't look right. >>>>> >>>>> As I mentioned earlier, I've tried several HEAD snapshots. >>>> >>>> Just a quick update on this: I've built quite a few releases now and >>>> managed to track down the problem to somewhere between r235789 and >>>> r237855. It'll probably take me another day or two before I know which >>>> commit actually broke it. >>> >>> Hi, >>> >>> I don't see any relevant USB+UMASS patches for your issue in this interval, >>> but many patches in the SCSI/CAM area. >> >> I finally found it. A r237477 memstick boots fine. A r237478 memstick does not. >> >> 237478 is the following commit by mav@: >> >> ------------------------------------------------------------------------ >> r237478 | mav | 2012-06-23 14:32:53 +0200 (Sat, 23 Jun 2012) | 3 lines >> >> Add scsi_extract_sense_ccb() -- wrapper around scsi_extract_sense_len(). >> It allows to remove number of duplicate checks from several places. >> >> ------------------------------------------------------------------------ > > So, mav@ haven't replied yet so I did some more investigation. I collected > all the USB sticks I had in the office (5 in total, all Kingston but different > size and models) and tried a memstick installation with each stick. Turns out > r237478 only breaks memstick installation in combination with certain USB > sticks: > > # Works: > > da0: Removable Direct Access SCSI-2 device > da0: 40.000MB/s transfers > da0: 7664MB (15695872 512 byte sectors: 255H 63S/T 977C) > > da0: Removable Direct Access SCSI-0 device > da0: 40.000MB/s transfers > da0: 1906MB (3903488 512 byte sectors: 255H 63S/T 242C) > > # Does not work: > > da0: Removable Direct Access SCSI-2 device > da0: 40.000MB/s transfers > da0: 15295MB (31324160 512 byte sectors: 255H 63S/T 1949C) > > da0: Removable Direct Access SCSI-0 device > da0: 40.000MB/s transfers > da0: 3690MB (7557704 512 byte sectors: 255H 63S/T 470C) > > da0: Removable Direct Access SCSI-2 device > da0: 40.000MB/s transfers > da0: 1905MB (3903264 512 byte sectors: 255H 63S/T 242C) > > It seems that only USB sticks labeled as "Kingston DataTraveler G3" > are affected by r237478 (in my limited testing, at least). This particular > model is what you get if you buy the cheapest Kingston model on the market > right now. I've reviewed that change once more and I see no flaws in it. My only guess is that it changes something innocent or unrelated in request order that confuses flash firmware, making it stuck and return errors without SCSI sense information. In log provided I see that when device first detected, it normally reports its size. But later, possibly after some command (SYNCHRONIZE CACHE?, PREVENT ALLOW MEDIUM REMOVAL?), it starts to behave wrong. Wrong answer to another READ CAPACITY request causes "got CAM status 0xXX" message and following device loss. Unfortunately I can't reproduce the problem. All USB sticks I have are working fine without any problems with HEAD system. If I could, I would try to log all commands sent to the stick to find one after which problem begins. Commands could be logged either on CAM layer by running `camcontrol debug -IPpc all` before plugging stick in and `camcontrol debug off` after (you may want to do it in single-user mode or without syslog running to avoid logging activity on other CAM disks), or probably somehow on umass layer, or with usbdump on raw USB layer (in last case some more knowledge will be needed to interpret result). -- Alexander Motin