From owner-freebsd-current@FreeBSD.ORG Sun Jan 8 16:55:25 2012 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 3241B1065673; Sun, 8 Jan 2012 16:55:25 +0000 (UTC) (envelope-from freebsd@chillt.de) Received: from dd28124.kasserver.com (dd28124.kasserver.com [85.13.146.180]) by mx1.freebsd.org (Postfix) with ESMTP id E392A8FC13; Sun, 8 Jan 2012 16:55:24 +0000 (UTC) Received: from taiko.lan (82.131.56.111.cable.starman.ee [82.131.56.111]) by dd28124.kasserver.com (Postfix) with ESMTPSA id 947681D801F4; Sun, 8 Jan 2012 17:55:23 +0100 (CET) Message-ID: <4F09CA6E.5090802@chillt.de> Date: Sun, 08 Jan 2012 18:55:10 +0200 From: Bartosz Fabianowski User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20111227 Thunderbird/9.0 MIME-Version: 1.0 To: Hans Petter Selasky , freebsd-current@freebsd.org, freebsd-usb@freebsd.org, poyopoyo@puripuri.plala.or.jp References: <4EF9D06C.9060501@chillt.de> <201201031726.03885.hselasky@c2i.net> <4F03317D.6080702@chillt.de> <201201031815.32624.hselasky@c2i.net> <86r4zagqyv.wl%sf@FreeBSD.org> <4F09BD0E.5090606@chillt.de> In-Reply-To: <4F09BD0E.5090606@chillt.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 08 Jan 2012 17:27:49 +0000 Cc: Subject: Re: umass regression 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: Sun, 08 Jan 2012 16:55:25 -0000 Looking into this further, I think that the issue is down to Garmin devices supplying incorrect information. In reply to the SCSI INQUIRY command, the HISUP bit is not set. This means that single level LUN structure is used (which appears to be all that FreeBSD supports anyway). Consequently, the second LUN should be of the form: 00 01 00 00 00 00 00 00 Instead, the device reports a second LUN of: 00 00 00 00 00 00 00 01 This is invalid as it uses all four addressing levels, not the single level LUN structure. I think a quirk will be needed here, for example one that ignores the list entries and looks at the length of the list only, assuming that for a list of length n, the LUNs will be 0, 1, 2, ..., n - 1. - Bartosz