From owner-freebsd-current@FreeBSD.ORG Sun Jan 8 16:14:38 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 52F161065673 for ; Sun, 8 Jan 2012 16:14:38 +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 CD2798FC0C for ; Sun, 8 Jan 2012 16:14:37 +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 BE2FE1D8004D; Sun, 8 Jan 2012 16:58:18 +0100 (CET) Message-ID: <4F09BD0E.5090606@chillt.de> Date: Sun, 08 Jan 2012 17:58:06 +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> In-Reply-To: <86r4zagqyv.wl%sf@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 08 Jan 2012 17:17:45 +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:14:38 -0000 Interesting timing. I am just in the middle of a debug session to try and debug this. I know nothing about umass and/or SCSI, so it is all one big learning experience for me. Here is what I am seeing (snippets from [1]): * SCSI command "REPORT LUNS" is sent: 55 53 42 43 03 00 00 00 18 00 00 00 80 00 0C A0 00 00 00 00 00 00 00 00 18 00 00 00 00 00 00 * List of LUNs is received: 00 00 00 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 This list contains exactly two LUNs, 0 and 1. The list is then processed by scsi_xpt.c. After reading the first entry, LUN 0 is scanned and da0 created. Then, the next entry is read. And something seems to go wrong here. The debug output I get is: cam_debug: next lun to try at index 1 is 0 IMHO, this should not be. The entry at index 1 is LUN 1, not LUN 0. It seems that instead of scanning LUN 0 and LUN 1, the code ends up scanning LUN 0 twice. I have no idea why though. - Bartosz