From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1OreLG-0003ma-E0 for mharc-grub-devel@gnu.org; Fri, 03 Sep 2010 18:02:38 -0400 Received: from [140.186.70.92] (port=59116 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OreLD-0003mN-Lb for grub-devel@gnu.org; Fri, 03 Sep 2010 18:02:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OreLC-0006cY-7a for grub-devel@gnu.org; Fri, 03 Sep 2010 18:02:35 -0400 Received: from smtp-out4.iol.cz ([194.228.2.92]:36238) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OreLB-0006cQ-RM for grub-devel@gnu.org; Fri, 03 Sep 2010 18:02:34 -0400 Received: from antivir6.iol.cz (unknown [192.168.30.215]) by smtp-out4.iol.cz (Postfix) with ESMTP id D115FCE42D2 for ; Fri, 3 Sep 2010 22:02:30 +0000 (UTC) Received: from localhost (antivir6.iol.cz [127.0.0.1]) by antivir6.iol.cz (Postfix) with ESMTP id BC1DB720055 for ; Sat, 4 Sep 2010 00:02:30 +0200 (CEST) X-Virus-Scanned: amavisd-new at iol.cz Received: from antivir6.iol.cz ([127.0.0.1]) by localhost (antivir6.iol.cz [127.0.0.1]) (amavisd-new, port 10224) with LMTP id N7QzuuXPAVhL for ; Sat, 4 Sep 2010 00:02:30 +0200 (CEST) Received: from port2.iol.cz (unknown [192.168.30.92]) by antivir6.iol.cz (Postfix) with ESMTP id 8390B720058 for ; Sat, 4 Sep 2010 00:02:30 +0200 (CEST) X-SBRS: None X-SBRS-none: None X-RECVLIST: MTA-OUT-IOL X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtEKAPoMgUxVRnXk/2dsb2JhbAAHgxGBActpkXuESHME Received: from 228.117.broadband3.iol.cz (HELO [192.168.6.160]) ([85.70.117.228]) by port2.iol.cz with ESMTP; 04 Sep 2010 00:02:30 +0200 From: =?UTF-8?Q?Ale=C5=A1?= Nesrsta To: The development of GNU GRUB In-Reply-To: <4C7AF7E1.7020204@gmail.com> 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> Content-Type: multipart/mixed; boundary="=-e5PDQNW0xIsufpZ9KPOD" Date: Sat, 04 Sep 2010 00:02:28 +0200 Message-Id: <1283551348.27688.89.camel@pracovna> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) 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: Fri, 03 Sep 2010 22:02:36 -0000 --=-e5PDQNW0xIsufpZ9KPOD Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Vladimir '=CF=86-coder/phcoder' Serbinenko wrote: > > 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 > Just to be clear: polling interrupt pipe on hub is what I have > implemented in keylayouts, just so you don't implement it again > > 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= . > > 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 > >> Could I help You with it - at least with testing ? > >> =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. 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 bulk (interrupt) transfer returns always err=3D7 and in UHCI TD status&control are set bits "CRC/Time Out Error" (bit 18) and "Stalled" (bit 22). It is the same behavior as some normal full speed mass-storage devices do also (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 and 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 port 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. 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? --- 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. Regards Ales --=-e5PDQNW0xIsufpZ9KPOD Content-Disposition: attachment; filename=usb_low_speed_100903_0 Content-Type: text/x-patch; name=usb_low_speed_100903_0; charset=UTF-8 Content-Transfer-Encoding: 7bit --- kbdlayouts/grub-core/bus/usb/uhci.c 2010-09-03 22:13:28.000000000 +0200 +++ kbdlayouts_changed/grub-core/bus/usb/uhci.c 2010-09-01 21:10:24.000000000 +0200 @@ -414,7 +414,7 @@ grub_uhci_transaction (struct grub_uhci *u, unsigned int endp, grub_transfer_type_t type, unsigned int addr, unsigned int toggle, grub_size_t size, - grub_uint32_t data) + grub_uint32_t data, grub_usb_speed_t speed) { grub_uhci_td_t td; static const unsigned int tf[] = { 0x69, 0xE1, 0x2D }; @@ -439,7 +439,8 @@ td->linkptr = 1; /* Active! Only retry a transfer 3 times. */ - td->ctrl_status = (1 << 23) | (3 << 27); + td->ctrl_status = (1 << 23) | (3 << 27) | + ((speed == GRUB_USB_SPEED_LOW) ? (1 << 26) : 0); /* If zero bytes are transmitted, size is 0x7FF. Otherwise size is size-1. */ @@ -495,7 +496,8 @@ td = grub_uhci_transaction (u, transfer->endpoint & 15, tr->pid, transfer->devaddr, tr->toggle, - tr->size, tr->data); + tr->size, tr->data, + transfer->dev->speed); if (! td) { grub_size_t actual = 0; --=-e5PDQNW0xIsufpZ9KPOD--