From owner-freebsd-usb@FreeBSD.ORG Tue Feb 10 09:06:32 2015 Return-Path: Delivered-To: usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C354B37D; Tue, 10 Feb 2015 09:06:32 +0000 (UTC) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6363BB36; Tue, 10 Feb 2015 09:06:32 +0000 (UTC) Received: by mail-wg0-f43.google.com with SMTP id n12so10528740wgh.2; Tue, 10 Feb 2015 01:06:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :mime-version:content-type:content-transfer-encoding; bh=8Xv8vYLmIG4tqA357x1ZBSnROFpBrARI5rkQkUiTSic=; b=s1rXHD2ueeRMUAljQtMoBBJVYp/VKQ+DXshlGdEImRLzcIRuGNZi5skquazJGAp0bD o5UyYb/97fdbWfEB6KJ/mcTn7b+Ndnm+v/zFmcasE4/vD9H0t7t/ClPUh+Z3kONRWtGM 1jTwtHnRa5JigtXmU2DVcydfHlQGN7pHvpF9DRwFLa6AjaLG59B+fknAjdYttkzHBWAL d82SWCnz511k9WIw6e7S9TSuOk41y6DfYz1ildRaL/Q+P/6pMUdJJHaSVyvWuNhBO5iW 2bF639DSTb6N8P6c2qkPfrSHqVXdqrb9WlwJUVoRZ+LMxRajbnKizDiUjnvsTtFYkX+P I4Yw== X-Received: by 10.181.12.49 with SMTP id en17mr11258717wid.62.1423559190376; Tue, 10 Feb 2015 01:06:30 -0800 (PST) Received: from ernst.home (p4FCA67C8.dip0.t-ipconnect.de. [79.202.103.200]) by mx.google.com with ESMTPSA id hr1sm17899650wib.1.2015.02.10.01.06.28 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Feb 2015 01:06:29 -0800 (PST) Date: Tue, 10 Feb 2015 10:06:28 +0100 From: Gary Jennejohn To: Hans Petter Selasky Subject: Re: r276717 causes problems Message-ID: <20150210100628.17c24ac2@ernst.home> In-Reply-To: <54D92B40.10907@selasky.org> References: <20150209183648.7825eee5@ernst.home> <54D92612.6000207@selasky.org> <4020134.66atlK9cJ0@ralph.baldwin.cx> <54D92B40.10907@selasky.org> Reply-To: gljennjohn@gmail.com X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: usb@freebsd.org, John Baldwin X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2015 09:06:33 -0000 On Mon, 09 Feb 2015 22:48:48 +0100 Hans Petter Selasky wrote: Hans, > Can you test this change: > https://svnweb.freebsd.org/changeset/base/278477 > Thanks, but it doesn't help. I updated to 278499. Here's the relevant dmesg output using the new kernel: Feb 10 09:45:20 ernst kernel: ugen0.4: at usbus0 Feb 10 09:45:20 ernst kernel: umass0: on usbus0 Feb 10 09:45:20 ernst kernel: (probe0:umass-sim0:0:0:0): REPORT LUNS. CDB: a0 00 00 00 00 00 00 00 00 10 00 00 Feb 10 09:45:20 ernst kernel: (probe0:umass-sim0:0:0:0): CAM status: SCSI Status Error Feb 10 09:45:20 ernst kernel: (probe0:umass-sim0:0:0:0): SCSI status: Check Condition Feb 10 09:45:20 ernst kernel: (probe0:umass-sim0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:20,0 (Invalid command operation code) Feb 10 09:45:20 ernst kernel: (probe0:umass-sim0:0:0:0): Error 22, Unretryable error Feb 10 09:45:20 ernst kernel: da0 at umass-sim0 bus 0 scbus8 target 0 lun 0 Feb 10 09:45:20 ernst kernel: da0: Fixed Direct Access SCSI-6 device Feb 10 09:45:20 ernst kernel: da0: Serial Number Feb 10 09:45:20 ernst kernel: da0: 400.000MB/s transfers Feb 10 09:45:20 ernst kernel: da0: 1907729MB (3907029168 512 byte sectors: 255H 63S/T 243201C) Feb 10 09:45:20 ernst kernel: da0: quirks=0x2 Note that the vendor/product strings are missing. I'm not certain whether the failure of REPORT LUNS has anything to do with my problem, but it seems like a failed SCSI command shouldn't prevent enumerating the disks in the enclosure. When the enumeration succeeds I always see da0, da1 and da2. Note that I tried a slightly older HEAD (from yesterday, so it already had 278477 in it) with dma_bits forced to 32 and the enumeration also failed. So, there's more to my problem than just the DMA width. There have been so many changes to CAM lately that the cause may lie there. -- Gary Jennejohn