From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1Ti13q-0001pv-3g for mharc-grub-devel@gnu.org; Mon, 10 Dec 2012 05:58:10 -0500 Received: from eggs.gnu.org ([208.118.235.92]:54445) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ti13j-0001pX-Mi for grub-devel@gnu.org; Mon, 10 Dec 2012 05:58:09 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ti13i-0001un-3k for grub-devel@gnu.org; Mon, 10 Dec 2012 05:58:03 -0500 Received: from mail-ea0-f169.google.com ([209.85.215.169]:38491) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ti13h-0001ua-Tg for grub-devel@gnu.org; Mon, 10 Dec 2012 05:58:02 -0500 Received: by mail-ea0-f169.google.com with SMTP id a12so1157779eaa.0 for ; Mon, 10 Dec 2012 02:58:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-enigmail-version:content-type; bh=/IdiETtDkAQNhugNfJPEN2/TSg4OZfsWXtLn7KLGzms=; b=Sme0VjDHXdS6NwGWtEdcajIlkeoqmWdnxyJpETG4OTOmNzZCmVlmEbqUZoH/N8bYnl LaiCYAxPh0+0SlGauWcFVV39fdikE+/gcJlAUbVGsqV9lYJwnD6hrY5h1AnYXspLYD1/ gKxj5Xl3Nk1i7EyTjudMc3sZw6p6nkvdXt3q1ruUyHxtvwU5LTd5RRM2H9e6E4xGC+Lv zufoCE4DPkHvGR8Lo8o4jiStUVmLBwgeE4NeCCLnLAfltJ6fqhb0SMcs7hR/DUVOlc8k kvJ7/npGFtml6gRWaRuXufm9j5VIFy+m+/VpYKsRrVWTthqcdtCrZbe8zLCXqpy2e8Ap NLmQ== Received: by 10.14.2.196 with SMTP id 44mr48343286eef.25.1355137080748; Mon, 10 Dec 2012 02:58:00 -0800 (PST) Received: from debian.x201.phnet (111-233.197-178.cust.bluewin.ch. [178.197.233.111]) by mx.google.com with ESMTPS id d3sm42900626eeo.13.2012.12.10.02.57.54 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 10 Dec 2012 02:57:59 -0800 (PST) Message-ID: <50C5C028.7000700@gmail.com> Date: Mon, 10 Dec 2012 11:57:44 +0100 From: =?UTF-8?B?VmxhZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28=?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.11) Gecko/20121122 Icedove/10.0.11 MIME-Version: 1.0 To: grub-devel@gnu.org Subject: Re: [PATCH] Long USB transfers problem References: <1354402009.2479.108.camel@pracovna> In-Reply-To: <1354402009.2479.108.camel@pracovna> X-Enigmail-Version: 1.4.1 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig3A270345DB31F65CD2ED9D20" X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 209.85.215.169 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 10:58:09 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3A270345DB31F65CD2ED9D20 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 01.12.2012 23:46, Ale=C5=A1 Nesrsta wrote: > Hi, > I found some USB problem: >=20 > 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 firs= t > time after EHCI/UHCI/OHCI module is loaded. > "Long" means data block of 0x8000 bytes length - it is not too much > nowadays :-) >=20 > 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 i= s > 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. >=20 Can this be computed from the device info rather than hardwired to 2K? 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. > 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. >=20 > 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. >=20 > It is probably not critical patch because this situation happens mainly= > if USB device is full speed device - i.e. this problem is related mainl= y > to very old USB flash disks or some (older) special mass storage device= s > like GPS devices, cameras, card readers etc. - which will be probably > never used as boot devices... (but - who knows...) :-)=20 >=20 > BR, > Ales >=20 >=20 >=20 > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel --=20 Regards Vladimir '=CF=86-coder/phcoder' Serbinenko --------------enig3A270345DB31F65CD2ED9D20 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREKAAYFAlDFwCgACgkQNak7dOguQgkiCQD/YZZSdVnod40jv71QLF/80xl+ zffUGGarZUF4TR59Qu0A/inTKe3f/6G3FK1iPdd3Z/gPIn1d6YOAQb3T37C92TlU =n3Ea -----END PGP SIGNATURE----- --------------enig3A270345DB31F65CD2ED9D20--