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 _______________________________________________ edk2-devel mailing list firstname.lastname@example.org https://lists.01.org/mailman/listinfo/edk2-devel