[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [edk2] nonzero LUN on USB Bulk Only Transfer fails with
From: |
Laszlo Ersek |
Subject: |
Re: [Qemu-devel] [edk2] nonzero LUN on USB Bulk Only Transfer fails with QEMU+edk2 |
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 |
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 <https://bugzilla.redhat.com/show_bug.cgi?id=917702>.
>> -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 <https://bugzilla.redhat.com/show_bug.cgi?id=917702>, 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