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

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

[The Gluglug]

I am trying to boot a USB flash drive in GRUB2, when used as a payload 
for coreboot.
This is on a Lenovo Thinkpad X60.

I am using this config to boot from a Trisquel live USB (the config in 
correct; it has worked on occasion):
menuentry 'Boot Trisquel USB' {
     linux (usb0)/casper/vmlinuz boot=casper noprompt noeject idle=halt
     initrd (usb0)/casper/initrd
}

Sometimes, the linux line fails, and I am taken back to grub menu.
Other times, the linux line works, but the initrd line fails (in this 
case, it boots the kernel but it panics)
Sometimes both lines work, and I am able to boot into a Trisquel live 
usb sucessfully - very rarely.
Regardless, when one of the 2 above is true (either vmlinuz and/or 
initrd fails to load), I get this message:
error: USB Mass Storage request failed

Premise: me and phcoder think its a bad/slow USB drive.

Here are the attempted fixes (reposted so that they never expire):
http://paste.debian.net/70166/
After this, I got the message:
error: USB Mass Storage request failed (USB Error 7).

Then I tried this (reposted to never expire):
http://paste.debian.net/70171/
(increase timeout from 1 second to 10 seconds)

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

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?

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

[Aleš Nesrsta]

[-- Attachment #1: Type: text/plain, Size: 3352 bytes --]

> 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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 295 bytes --]

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

[Melki Christian (consultant)]

I think you should plug a USB snooper and look at the flow.
This is initial stuff, so it shouldn't be that much data to look at.

Also, dump the device descriptors using linux (lsusb) for example.
It should help with quirk-searching.

> I am trying to boot a USB flash drive in GRUB2, when used as a payload
> for coreboot.
> This is on a Lenovo Thinkpad X60.
> 
> I am using this config to boot from a Trisquel live USB (the config in
> correct; it has worked on occasion):
> menuentry 'Boot Trisquel USB' {
>      linux (usb0)/casper/vmlinuz boot=casper noprompt noeject idle=halt
>      initrd (usb0)/casper/initrd
> }
> 
> Sometimes, the linux line fails, and I am taken back to grub menu.
> Other times, the linux line works, but the initrd line fails (in this
> case, it boots the kernel but it panics)
> Sometimes both lines work, and I am able to boot into a Trisquel live
> usb sucessfully - very rarely.
> Regardless, when one of the 2 above is true (either vmlinuz and/or
> initrd fails to load), I get this message:
> error: USB Mass Storage request failed
> 
> Premise: me and phcoder think its a bad/slow USB drive.
> 
> Here are the attempted fixes (reposted so that they never expire):
> http://paste.debian.net/70166/
> After this, I got the message:
> error: USB Mass Storage request failed (USB Error 7).
> 
> Then I tried this (reposted to never expire):
> http://paste.debian.net/70171/
> (increase timeout from 1 second to 10 seconds)
> 
> 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
> 
> 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?
> 
> 
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel

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

[Aleš Nesrsta]

[-- Attachment #1: Type: text/plain, Size: 136 bytes --]

Hi,
I probably found the reason of this bad behavior.
Try patch included in ML thread "[PATCH] EHCI/USBMS corrections".
BR,
Ales


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 295 bytes --]