From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=209.132.183.28; helo=mx1.redhat.com; envelope-from=lersek@redhat.com; receiver=edk2-devel@lists.01.org Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id D321120886D88 for ; Wed, 13 Feb 2019 16:14:03 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 39DB35A1EB; Thu, 14 Feb 2019 00:14:03 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-120-136.rdu2.redhat.com [10.10.120.136]) by smtp.corp.redhat.com (Postfix) with ESMTP id 3799A60C54; Thu, 14 Feb 2019 00:13:54 +0000 (UTC) To: =?UTF-8?Q?Philippe_Mathieu-Daud=c3=a9?= , Gerd Hoffmann , Ray Ni Cc: edk2-devel-01 , qemu devel list , Markus Armbruster References: <49268e92-0abf-a2d3-a523-2c14e009e9cd@redhat.com> From: Laszlo Ersek Message-ID: Date: Thu, 14 Feb 2019 01:13:53 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <49268e92-0abf-a2d3-a523-2c14e009e9cd@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Thu, 14 Feb 2019 00:14:03 +0000 (UTC) Subject: Re: nonzero LUN on USB Bulk Only Transfer fails with QEMU+edk2 X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 00:14:05 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit On 02/13/19 18:00, Philippe Mathieu-Daudé wrote: > On 2/13/19 9:37 AM, Laszlo Ersek wrote: >> >> using QEMU, when I specify a nonzero LUN for the hard disk that sits on >> the "SCSI bus" that embodies the USB Bulk Only Transfer device, then >> UsbMassStorageDxe fails to recognize the hard disk. >> >> (1) Consider the following QEMU command line snippet: >> >> -drive id=disk1,if=none,format=raw,readonly,file=$APPDISK \ >> -device qemu-xhci,id=xhci1,p3=15,addr=02.0 \ >> -device usb-bot,bus=xhci1.0,port=3,id=bot1 \ > > Do you have a specific need to use the 'usb-bot' device? Nothing beyond . >> -device scsi-hd,drive=disk1,bus=bot1.0,lun=0,bootindex=1 \ [...] >> In this case, edk2 recognizes the disk and things work fine. >> >> (In fact, for lun=0, the QemuBootOrderLib pattern matching / translation >> works fine as well -- verifying which was my original goal, before I ran >> into the issues below, for nonzero LUNs. But, I digress.) >> >> >> (2) If I change the cmdline to "lun=5", then the exchange is: > > From qemu/docs/usb-storage.txt: > > The LUN numbers must be continuous, i.e. for three devices you must > use 0+1+2. The 0+1+5 numbering from the "usb-uas" example isn't going > to work with "usb-bot". > > A failure is expected :/ OK, that explains the issue in (2). Wrong config. Thanks! [...] >> (3) Starting again from the original command line, if I change "lun=0" >> to "lun=1" (rather than to "lun=5"), then OVMF even hangs, with the >> following log: [...] >>> ASSERT MdeModulePkg/Bus/Pci/XhciDxe/XhciSched.c(1915): TrsRing != ((void *) 0) >> >> In this case, edk2 seems to recognize that a nonzero LUN is available on >> the target, but the initialization never completes, and then an >> assertion fails, apparently in the lower-level XHCI transport code. > > Can you try using the 'usb-uas' device instead of the 'usb-bot'? Thanks, but no, thanks. :) For USB storage options, I prefer the absolute minimum. I thought that usb-storage was the end of the story -- it works perfectly fine; please see the scope in: - https://bugzilla.redhat.com/show_bug.cgi?id=1458192 - https://github.com/tianocore/edk2/commit/f9c59fa44ae2 Due to , usb-bot now looks relevant as well. I'm trying to see how that maps to the existent usb-storage support code, and what extensions if any are needed. "usb-uas" remains totally out of scope though. --*-- Anyway, now I realize that my test (3) was invalid too, because, by *changing* lun0 to lun1 (rather than adding lun1 after lun0), I again created a discontiguous LUN space. (4) Unfortunately, the same assertion failure hits in edk2, even if I add *both* lun0 and lun1: -drive id=disk1,if=none,format=raw,readonly,file=$APPDISK \ -drive id=disk2,if=none,format=raw,readonly,file=$APPDISK \ -device qemu-xhci,id=xhci1,p3=15,addr=02.0 \ -device usb-bot,bus=xhci1.0,port=4,id=bot1 \ -device scsi-hd,drive=disk1,bus=bot1.0,lun=0,bootindex=1 \ -device scsi-hd,drive=disk2,bus=bot1.0,lun=1,bootindex=2 \ Based on the last paragraphs in "docs/usb-storage.txt" (specifically step (2b)), I'd expect this to work -- do you agree? Thank you! Laszlo