grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Long USB transfers problem


From: Aleš Nesrsta
Subject: Re: [PATCH] Long USB transfers problem
Date: Mon, 10 Dec 2012 18:49:08 +0100

Vladimir 'φ-coder/phcoder' Serbinenko píše v Po 10. 12. 2012 v 11:57
+0100:
> On 01.12.2012 23:46, Aleš Nesrsta wrote:
> 
> > 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.
> > 
> 
> Can this be computed from the device info rather than hardwired to 2K?
That is very good question but I probably cannot say definite answer.
Theoretically we have two possible low limits related to each USBMS
device:
- SCSI device block size (sector size)
- USB device maximal packet size

I think - according to general USB specification - that the partial
intermediate bulk transfer of "large" data block can be any multiple of
endpoint wMaxPacketSize which is lower than or equal to unread length of
data.
But wMaxPacketSize itself is too low value in case of USB 1 devices, we
need some larger value to be more effective - i.e. at least we should
choose some multiplier...

So, probably better will be to use SCSI device block (sector) size.
Valid SCSI device block size should be included in data structure
returned by device as answer to Read Capacity X - this value is read by
grub_scsi_open function during USBMS device initialization.

Using of SCSI block size will be possible only in case of USB mass
storage device - but it is probably not problem, see my answer to Your
second question.


> Also do we have any other use for long USB transfers? If not, it's
> easier to put this logic in scsi.c rather than adding it another time in
> USB subsystem.
Currently GRUB supports only these three kind of USB devices:
- mass storage
- keyboard
- two USB-serial converters
Keyboard uses very short interrupt data blocks, serial converter
probably should not use longer bulk transfer than its internal buffer
size, i.e. around 256 bytes.
So, there is probably only one source of "long" transfers - mass storage
device, e.g. we can put splitting logic in scsi.c.

There is only one question, if scsi.c is really right place - scsi.c
could be potentially used for another kind of devices than USBMS and if
we split "long" transfers in scsi.c, we can lost performance on such
another devices.

As this problem is together USB implementation specific and USB mass
storage specific, I suggest to do splitting in usbms.c.
Functions grub_usbms_read and grub_usbms_write have access to related
grub_scsi structure, i.e. splitting in these functions can use SCSI
device block size of related USB mass storage device without any
additional modifications.

BR,
Ales




reply via email to

[Prev in Thread] Current Thread [Next in Thread]