From: "Aleš Nesrsta" <starous@volny.cz>
To: grub-devel@gnu.org
Subject: [PATCH] Long USB transfers problem
Date: Sat, 01 Dec 2012 23:46:49 +0100 [thread overview]
Message-ID: <1354402009.2479.108.camel@pracovna> (raw)
[-- Attachment #1: Type: text/plain, Size: 1908 bytes --]
Hi,
I found some USB problem:
Some part of GRUB wants read "long" data block from USB mass storage
device when GRUB opens USB disk, e.g. when "ls" command is entered first
time after EHCI/UHCI/OHCI module is loaded.
"Long" means data block of 0x8000 bytes length - it is not too much
nowadays :-)
But:
Some USB devices have too low limit of bulk data packet size, e.g. 32
bytes or less - so, in such case the USB driver needs to use lot of
Transfer Descriptors (TDs) to transfer 32Kbytes of data.
Unfortunately, number of TDs is limited in GRUB driver(s) - and there is
not enough TDs in this situation.
The result is internal error, no data transfer is initiated by driver
and error code is returned to calling function from usbms.c.
It is vary bad situation: USB device receives CBW command to transfer
0x8000 bytes - but transfer of data is never started because driver run
out of TDs...
Some devices could be automatically recovered from such situation and
works normally later when GRUB tries read disk by smaller parts.
But some devices remains confused even if they are reset by USBMS
specific reset command.
So, I wrote simple experimental patch which splits "long" transfer into
smaller parts - it looks to solve this issue.
Patch solves only read transfer - AFAIK GRUB loader is not designed to
write some data into disk, so there probably never be transfer of "long"
data block in direction into USB mass storage device.
Maximal size 2Kbyte of USB data transfer data block (defined in
usbtrans.h) looks to be more or less optimal value.
It is probably not critical patch because this situation happens mainly
if USB device is full speed device - i.e. this problem is related mainly
to very old USB flash disks or some (older) special mass storage devices
like GPS devices, cameras, card readers etc. - which will be probably
never used as boot devices... (but - who knows...) :-)
BR,
Ales
[-- Attachment #2: usb_patch_121201_0 --]
[-- Type: text/x-patch, Size: 1421 bytes --]
--- ./grub/include/grub/usbtrans.h 2012-11-11 21:01:57.000000000 +0100
+++ ./grub_patched/include/grub/usbtrans.h 2012-11-30 21:35:11.000000000 +0100
@@ -19,6 +19,8 @@
#ifndef GRUB_USBTRANS_H
#define GRUB_USBTRANS_H 1
+#define MAX_USB_TRANSFER_LEN 0x0800
+
typedef enum
{
GRUB_USB_TRANSFER_TYPE_IN,
--- ./grub/grub-core/bus/usb/usbtrans.c 2012-11-11 21:01:57.000000000 +0100
+++ ./grub_patched/grub-core/bus/usb/usbtrans.c 2012-11-30 22:42:04.000000000 +0100
@@ -351,11 +351,23 @@ grub_usb_err_t
grub_usb_bulk_read (grub_usb_device_t dev,
int endpoint, grub_size_t size, char *data)
{
- grub_size_t actual;
+ grub_size_t actual, transferred;
grub_usb_err_t err;
- err = grub_usb_bulk_readwrite (dev, endpoint, size, data,
- GRUB_USB_TRANSFER_TYPE_IN, 1000, &actual);
- if (!err && actual != size)
+ grub_size_t current_size, position;
+
+ for (position = 0, transferred = 0;
+ position < size; position += MAX_USB_TRANSFER_LEN)
+ {
+ current_size = size - position;
+ if (current_size >= MAX_USB_TRANSFER_LEN)
+ current_size = MAX_USB_TRANSFER_LEN;
+ err = grub_usb_bulk_readwrite (dev, endpoint, current_size,
+ &data[position], GRUB_USB_TRANSFER_TYPE_IN, 1000, &actual);
+ transferred += actual;
+ if (err || (current_size != actual) ) break;
+ }
+
+ if (!err && transferred != size)
err = GRUB_USB_ERR_DATA;
return err;
}
next reply other threads:[~2012-12-01 22:47 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-01 22:46 Aleš Nesrsta [this message]
2012-12-10 10:57 ` [PATCH] Long USB transfers problem Vladimir 'φ-coder/phcoder' Serbinenko
2012-12-10 17:49 ` Aleš Nesrsta
2012-12-10 20:33 ` Vladimir 'φ-coder/phcoder' Serbinenko
2012-12-11 20:40 ` Aleš Nesrsta
2013-01-20 21:46 ` Vladimir 'φ-coder/phcoder' Serbinenko
2013-02-11 23:13 ` Aleš Nesrsta
2013-02-24 18:37 ` Vladimir 'φ-coder/phcoder' Serbinenko
2013-02-24 19:09 ` Vladimir 'φ-coder/phcoder' Serbinenko
2013-02-24 19:25 ` Vladimir 'φ-coder/phcoder' Serbinenko
2013-03-07 19:19 ` Aleš Nesrsta
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1354402009.2479.108.camel@pracovna \
--to=starous@volny.cz \
--cc=grub-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.