From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1OwuLI-0006qJ-Jc for mharc-grub-devel@gnu.org; Sat, 18 Sep 2010 06:08:24 -0400 Received: from [140.186.70.92] (port=54838 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OwuLE-0006pQ-Bx for grub-devel@gnu.org; Sat, 18 Sep 2010 06:08:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OwuLC-00061F-Q9 for grub-devel@gnu.org; Sat, 18 Sep 2010 06:08:20 -0400 Received: from mail-bw0-f41.google.com ([209.85.214.41]:58507) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OwuLC-000618-HO for grub-devel@gnu.org; Sat, 18 Sep 2010 06:08:18 -0400 Received: by bwz10 with SMTP id 10so4631547bwz.0 for ; Sat, 18 Sep 2010 03:08:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=pxYjW0FYzHJyNV+WhR+YEsXKbrKNX2Rb4gVwC5i+g/E=; b=fUo9RVyHuzBcT6wnj8b6YVTpK3r8xhiNmYZjBvo9O/HVRAFbTral01A2QkE4xdCCFS +Jv0RHy7sFSlrRiHtV+E3Ol9b9vsFoPxkjZTQYkfEWFnZ0JnudMAJhpgjvbAmQM/6k5R f3kop3qwg1Jf/O0/QFnQ4rZbf5iTeGRayX6f4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-enigmail-version:content-type; b=l0RcXkVVdPaa1LGWRqkETPzNjS9tbgUczwD5NQOV2UbIDzCIM3S8GIc9PwzlOos7Ai RsaZ5Ho3VvkWLwKRSaf3x7ufCLxGy+R97LspRD5gZbzxP6PL+I/BV5fJBm7BGoqZHSbL G8sYg5hyeXieNbmk0DNedBwsemmQ5SpQJ0A8o= Received: by 10.204.65.145 with SMTP id j17mr4500848bki.209.1284804496114; Sat, 18 Sep 2010 03:08:16 -0700 (PDT) Received: from debian.bg45.phnet (cx-public-docking-1-249.ethz.ch [129.132.149.249]) by mx.google.com with ESMTPS id d27sm4549986bku.10.2010.09.18.03.08.12 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 18 Sep 2010 03:08:14 -0700 (PDT) Message-ID: <4C948F82.3010608@gmail.com> Date: Sat, 18 Sep 2010 12:08:02 +0200 From: =?UTF-8?B?VmxhZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28=?= User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.11) Gecko/20100805 Icedove/3.0.6 MIME-Version: 1.0 To: grub-devel@gnu.org References: <4C7519E8.90907@gmail.com> <20100826230527.GA26246@pina.cat> <4C76F58D.6020304@gmail.com> <1282995082.14285.4.camel@pracovna> <4C7AF2BB.2040606@gmail.com> <4C7AF7E1.7020204@gmail.com> <1283551348.27688.89.camel@pracovna> In-Reply-To: <1283551348.27688.89.camel@pracovna> X-Enigmail-Version: 1.0.1 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig5923E7EE4491BA2D06CA21D9" X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) Subject: Re: Plans on 1.99 release - USB issues X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 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: Sat, 18 Sep 2010 10:08:21 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5923E7EE4491BA2D06CA21D9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 09/04/2010 12:02 AM, Ale=C5=A1 Nesrsta wrote: > Vladimir '=CF=86-coder/phcoder' Serbinenko wrote: > =20 >>> The issue was that we were using getStatus every time we polled for n= ew >>> devices which suposedly (I fixed few other bugs in the code I used at= >>> the time so, I'm not sure) drove hub in my USB keyboard crazy. The >>> correct way is to poll interrupt pipe. >>> =20 >>> =20 >> Just to be clear: polling interrupt pipe on hub is what I have >> implemented in keylayouts, just so you don't implement it again >> =20 >>> Another thing I added is the ability to do background transfers. It i= s >>> important for USB keyboard support because otherwise we lose messages= on >>> keyboard interrupt pipe. It triggered a bug in uhci module. Now there= >>> are 2 issues: >>> 1) code is new or modified. Needs testing. >>> 2) On yeeloong the data read from mass storage is sometimes corrupted= =2E >>> Happens in mainline, not sure about other branches. It seems that it >>> wasn't the case before. It's either a regression (perhaps from my cod= e >>> for partial transfers) or cache issues (some cache isn't correctly fl= ushed) >>> =20 >>> =20 >>>> Could I help You with it - at least with testing ? >>>> =20 >>>> =20 >>>> =20 >>> Yes, a test run of keylayouts branch on your hardware would be helpfu= l. >>> Especially I'm interested if USB data corruption happens in your case= too. >>> =20 > Hi Vladimir, > > I made some tests on machine with UHCI with kbdlayouts branch (rev. > 2424). > I did not notice any evident data corruption. But there were some > another odd results: > > 1. > My USB keyboard is low speed device (Genius KB-06XE, model no. K639). > Low speed device transfer was not properly handled - I made some simple= > patch - see attachment, I did not commit it into repository. > Control type transfer with keyboard is working with this patch, but bul= k > (interrupt) transfer returns always err=3D7 and in UHCI TD status&contr= ol > are set bits "CRC/Time Out Error" (bit 18) and "Stalled" (bit 22). It i= s > the same behavior as some normal full speed mass-storage devices do als= o > (I reported it in some previous e-mails). I have some idea right now - > probably there is bad handling of UHCI transfer status in uhci.c when > more than one bit is set - GRUB_USB_ERR_TIMEOUT is returned instead of > GRUB_USB_ERR_STALL. I will try to play with this part during weekend an= d > I will report to You if some success happens... > > 2. > Next bad thing is some problem with device attachment detection or > handling of newly attached device on non-root hubs. Behavior of this > problem looks little bit randomly and probably depends also on used por= t > of hub - some ports are often working, some not (but all hub ports are > working normally in Linux/Windows). I did not find reason yet. > > =20 Perhaps has something to do with port number. Or perhaps unlike mine your router doesn't send initial device status change. > 3. > Sometimes partitions of USB mass storage devices were not properly > detected - maybe disk cache problem again? > Maybe it is data corruption which is reported by you - but I never > detected data corruption when I read data from files. > > --- > I am not sure if interrupt transfers can be handled via bulk queue on > OHCI - according specification, it should be handled via interrupt > pointers table which is currently not implemented in ohci.c. Did you > test background polling of interrupt pipe on some PC with OHCI? > =20 I could use USB keyboard just fine on Yeeloong. > --- > At the end some maybe bad idea - if I am not wrong, two simultaneous > transfers can happen (be active in UHCI/OHCI) with current background > bulk/interrupt transfer. There is question if are all related functions= > fully reentrant ? I.e., is correct handling of some shared data ? > For the first look I don't see such problem - with one exception: > donehead interrupt can be probably incorrectly handled in ohci.c - it > can be detected and misinterpreted by wrong call of > grub_ohci_check_transfer. The first aid in this case can be forcing of > OHCI driver into "bad OHCI" mode, i.e. donehead interrupt ignoring - in= > this mode it should work properly. > =20 It might have been the reason of yeeloong data corruption > Regards > Ales > > =20 > > > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/grub-devel > =20 --=20 Regards Vladimir '=CF=86-coder/phcoder' Serbinenko --------------enig5923E7EE4491BA2D06CA21D9 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.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREKAAYFAkyUj4kACgkQNak7dOguQgneoAD9Hlw8qNSSMQErAhc0Qq+2ubZd Fa5MpekgUJdChIJYpnkA/jgtSvGxvYglFZ+RlfgZOdqxdjj5FbmjRDpltvoOhzto =NFpH -----END PGP SIGNATURE----- --------------enig5923E7EE4491BA2D06CA21D9--