From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1Tx2iS-0007g1-AM for mharc-grub-devel@gnu.org; Sun, 20 Jan 2013 16:46:12 -0500 Received: from eggs.gnu.org ([208.118.235.92]:54635) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tx2iP-0007fZ-7l for grub-devel@gnu.org; Sun, 20 Jan 2013 16:46:10 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Tx2iO-0000EM-2S for grub-devel@gnu.org; Sun, 20 Jan 2013 16:46:09 -0500 Received: from mail-ee0-f50.google.com ([74.125.83.50]:49563) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tx2iN-0000EF-SY for grub-devel@gnu.org; Sun, 20 Jan 2013 16:46:08 -0500 Received: by mail-ee0-f50.google.com with SMTP id e51so2633710eek.23 for ; Sun, 20 Jan 2013 13:46:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; bh=wYozhwQ3sKlkTIEOwmrCOiknjUDl0pRM3VmLs1Uilyo=; b=zaHuNVpjhbujkCljPWRC46S3kEMJwcqsx5JG1RGOgze60nWYNfqDcYCSBJbrn8ZQQo sWL62fj5LVZ4CUMemHgfpNc667QSUGjzqU8onCnXAj/7ce7lWzk4z6VB90KZBJCRLWRd 1L3KuUMvzn/rcH2+VNzC0k1gpFS01bgGAbkV4aM6+xHoNN8et4JVgWkF7ogBmGFOHI/j Cz7Gags4qZyRgByPeEC5tEPI58mxUmzmLK6iaDeD25ztiKqrXswTrHPi7wjTaA+VmvHJ 9YhpDhIGoy9/k5Swioxw+SGqDZ5Rv6a7jIiJ5omjD3CJ5kuFJMJaUB+DeY9wjLUH4bCi KIxA== X-Received: by 10.14.224.199 with SMTP id x47mr52620574eep.19.1358718367072; Sun, 20 Jan 2013 13:46:07 -0800 (PST) Received: from debian.x201.phnet (90-165.78-83.cust.bluewin.ch. [83.78.165.90]) by mx.google.com with ESMTPS id f49sm19369577eep.12.2013.01.20.13.46.05 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 20 Jan 2013 13:46:06 -0800 (PST) Message-ID: <50FC659C.6020105@gmail.com> Date: Sun, 20 Jan 2013 22:46:04 +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="------------enig8A6394004AF9F23B7FFE3AD3" X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 74.125.83.50 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: Sun, 20 Jan 2013 21:46:10 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8A6394004AF9F23B7FFE3AD3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Committed, thanks 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 > 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 --------------enig8A6394004AF9F23B7FFE3AD3 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/ iF4EAREKAAYFAlD8ZZwACgkQNak7dOguQgkF7AD8CLdYmrF8wAThWCjfU1o8IXkb 4Cozw7jbvhhtiappWcMA/0jFXeTRyLCwjtoEoeDJiVL5W31XFno5/xtxuLOHOCJd =WZVu -----END PGP SIGNATURE----- --------------enig8A6394004AF9F23B7FFE3AD3--