Re: flash drive timing out, can't boot vmlinuz/initrd (coreboot payload)

[Aleš Nesrsta]

> 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