> Premise: me and phcoder think its a bad/slow USB drive. Of course, the USB device could be "bad" - I met some devices which have not good implementation of USB mass storage class (or SCSI) specification. What is surprising, most of these devices were able to work correctly in Linux or Windows (at least for the first look) - and I was not able to find why. I expect there are many workarounds (or "quirks") in Linux or Windows drivers related to these situations.
But it could be also some mistake in GRUB USB controller/USBMS/SCSI modules - they are not perfect, unfortunately... :-( ... > This changed nothing, so then this fix was attempted (after reverting > the patches above): > http://paste.debian.net/70174/ > > After this change, USB booting worked successfully 3 times, but then > started failing again with these errors: > error: USB Mass Storage stalled I think it is not good idea to use Clear Feature HALT in another situations than specified in USB mass storage specification(s). It usually leads to definitive stall or some another unexpected behavior of whole USB device or similar wrong situations - according to my experiences/experiments. Thus, similar solutions should not be used generally, they should be used only if some specific device is detected (some known bad Vendors/Product IDs etc.). > > Then this fix was attempted (after reverting the above): > http://paste.debian.net/70186/ > > This also changed nothing. > > > What other approaches could be taken to resolve this issue? It is hard to say if the main reason of the problem is not known. Timeout should never occur - mostly it does not mean that the device is slow: timeout happens when something went wrong, usually when something unexpected was sent to the device or something expected was not read from device etc. - and, additionally, if timeout happens, the whole USB device very often goes to permanent frozen state (e.g. there is no answer to any command) and finally only reset of related USB port can help in such situation. (Note: It is not possible to perform port (device) reset in GRUB from "higher" level, e.g. from USBMS driver etc. Additionally, port reset possibly changes USB device address and identification in GRUB etc.) One reason of bad behavior could be that the drive is not able to read longer block of data, e.g. more than one sector / 512 bytes in one SCSI read command etc. Does the USB flash drive work normally in Linux/Windows on the same PC/port? (E.g. on some older PCs I met problem of bad contacts on too often used USB connectors.) Did you try with GRUB any other flash drive with the same result? Which GRUB USB module driver is used - UHCI, OHCI or EHCI? In case you are using EHCI, did you try also UHCI/OHCI without EHCI loaded? And vice versa... - i.e., is it the same behavior of flash drive on both USB controllers (USB 1.1 / USB 2.0)? Which USB flash drive is it (USB ID, vendor and product name etc.)? Could you send output of following Linux command sudo lsusb -vvv when the problematic USB flash drive is connected? Additionally, I cannot easily found which USB controllers are inside Lenovo Thinkpad X60 - could you send also output of sudo lspci -vvv to know which exact USB controller(s) are installed in PC? BR, Ales
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Grub-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/grub-devel
