From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1VMZN5-0006kr-4f for mharc-grub-devel@gnu.org; Thu, 19 Sep 2013 04:13:55 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57293) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VMZN1-0006jt-OJ for grub-devel@gnu.org; Thu, 19 Sep 2013 04:13:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VMZMy-0004Em-Td for grub-devel@gnu.org; Thu, 19 Sep 2013 04:13:51 -0400 Received: from mail-ea0-x22b.google.com ([2a00:1450:4013:c01::22b]:46269) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VMZMy-0004Eg-Ib for grub-devel@gnu.org; Thu, 19 Sep 2013 04:13:48 -0400 Received: by mail-ea0-f171.google.com with SMTP id n15so3986626ead.16 for ; Thu, 19 Sep 2013 01:13:47 -0700 (PDT) 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:content-type; bh=AqfN5FFgeMZo0c4z0KwLiAbX2VY7Zeh1EiUA8xvlMbU=; b=mi9g1xm0bP7wpKTzmCTPg9l4OcR22LuGfitNMXZIXoLophexfub64WlhxoI6cPGujr BNZ82l2Vc9EkJ0Hs8f5S+DDoZtpETubybdvwzh90t9ZbL3Ou9NFcyEg7iTovFyh1DKf3 VgR53o0NKBau+n7aIRWs42+hMVKh5XUk01HNIqYT7qDKDRnz/xlblvlLd/0hOgYiaWFl UlgxtPlvUQ70IS98RZVqPSWPDrS3rjW/f8fFoL70Mtpa2pMeO/IPAih85JuSrke5t3ew 4w/rJxFT7jLAFGfxOZSM3SUrb/Kf2Q7ZZkkl3aHXmHLPOFzLLKkhfullfazY9QpVnzm2 pebA== X-Received: by 10.14.38.14 with SMTP id z14mr385926eea.89.1379578427694; Thu, 19 Sep 2013 01:13:47 -0700 (PDT) Received: from ?IPv6:2001:67c:10ec:3f42:8000::1340? ([2001:67c:10ec:3f42:8000::1340]) by mx.google.com with ESMTPSA id i1sm9319098eeg.0.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 19 Sep 2013 01:13:46 -0700 (PDT) Message-ID: <523AB23A.6010008@gmail.com> Date: Thu, 19 Sep 2013 10:13:46 +0200 From: =?UTF-8?B?VmxhZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28=?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130821 Icedove/17.0.8 MIME-Version: 1.0 To: The development of GNU GRUB Subject: Re: [PATCH] Re: [grub-devel] loongson-2f mini-pc (fuloong) elf image generation. References: <508D6906.5000100@gmail.com> <1351547244.2511.11.camel@king.jenpiliny.cz> <1351628069.2535.33.camel@king.jenpiliny.cz> <51E00C7F.6080700@gmail.com> <51E45E19.6080401@volny.cz> <51E59E32.4080608@volny.cz> <51E59EFE.6080301@volny.cz> <51E81366.10804@volny.cz> In-Reply-To: <51E81366.10804@volny.cz> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="----enig2CQNPDFDNPJQNBBRGCVWW" X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4013:c01::22b 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: Thu, 19 Sep 2013 08:13:54 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2CQNPDFDNPJQNBBRGCVWW Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Go ahead On 18.07.2013 18:10, Ale=C5=A1 Nesrsta wrote: > Hi, >=20 > after some debugging I have found bug(s) in handling of QHs related to > EHCI low speed split interrupt transfers. >=20 > Attached patch seems to solve problem described below (non-working USB > keyboard attached to the same port where was USB disk previously). >=20 > Please try it - maybe it solves also reported keyboard problem on > fuloong/loongson. >=20 > BR, > Ales >=20 >> I forgot one more thing - if You want to try repeat USBMS/USB keyboard= >> problem described below, You need to access the connected USB disk (e.= g. >> by "ls" command) before removing it. >> >>> Hi Vladimir, >>> >>> I have some additional information - results of some today's >>> experiments. >>> The main important thing related to USB keyboard: >>> >>> USB keyboard doesn't work if it is connected as first device to the s= ame >>> non-root hub port, where was connected USBMS device previously! >>> If the keyboard is disconnected and connected again to the same port,= it >>> works. >>> this behavior is systematical, it can be repeated at any time (at lea= st >>> on my PC). >>> >>> What is very interesting, USB keyboard is listed by command "usb". >>> And it doesn't matter if previously connected USBMS device was HIGH o= f >>> FULL device. >>> >>> I.e., according these test results, even if the USB keybord is not >>> working, it is connected to port and addressed properly and its contr= ol >>> pipe is working, but device itself is not working - maybe there is >>> something wrong in "high level" driver (usb_keyboard) - ? >>> >>> >>> There is also another bad thing - after some number of >>> connecting/disconnecting of the keyboard (at least about 20 and more)= >>> the GRUB crashes - more properly, it reboots PC, i.e. there is probab= ly >>> also some memory leak... >>> >>> BR, >>> Ales >>> >>>> >>>> 1. >>>> Some of my USBMS devices have problems to work properly. It seems to= be >>>> some regression because they worked well on some older revisions... = :-( >>>> I did not make any investigation it this direction yet, as this prob= lem >>>> is probably not related to latest changes (fix of root ports) - so I= >>>> ignore them for now. >>>> >>>> 2. >>>> Sometimes some devices are not recognized (not working) in the case >>>> when >>>> they are connected before USB "starting" time (before the moment whe= n >>>> USB modules/drivers are loaded) or when hub with this device is >>>> connected. >>>> Additionally, it seems to happen only if device is connected via >>>> hub(s), >>>> not directly into root port - at least it was behavior during my tes= ts >>>> (but I did only few tests on root ports, I focused my tests to USB >>>> keyboard connected via hub(s) etc.). >>>> It looks like, in some rare cases, usbhub.c maybe miss some non-root= >>>> hub >>>> port change(s). Unfortunately I had no enough time to try debug thes= e >>>> situations. >>>> >>>> So I went through Your changes in usbhub.c and other USB related fil= es. >>>> Unfortunately, I did not found reason of the problem mentioned above= in >>>> point 2. yet. >>>> But I found some another points to discuss: >>>> >>>> a) >>>> I found my old mistake related to variable "pending_reset". >>>> Meaning of this variable is to avoid concurrent reset on devices whi= ch >>>> are connected to the same controller HW instance. >>>> This variable is stored in wrong place - it should be located not in= >>>> "struct grub_usb_controller_dev" but in "struct grub_*hci" (i.e. >>>> grub_uhci, grub_ohci etc.). >>>> In fact, its current location is not totally bad - it is also workin= g, >>>> but it can slow down handling of USB devices (mainly in USB "startin= g" >>>> phase) in case when there are more controllers of the same type. >>>> >>>> >>>> b) >>>> There is missing waiting for device stable power in case when device= is >>>> connected to ROOT hub later than in USB "starting" time. >>>> This could possibly lead to wrong device reset and malfunction. >>>> >>>> I.e. the "first half" of "grub_usb_poll_devices" should be little bi= t >>>> changed, it is not correct to call "attach_root_port" immediately wh= en >>>> "detect_dev" detected device connection - it should be done e.g. in >>>> similar way as in "grub_usb_controller_dev_register" (or maybe >>>> better in >>>> some another, "background" way, like You did for non-root hub - to >>>> prevent unwanted delay in execution of another GRUB parts). >>>> >>>> >>>> c) >>>> I thought about this old code: >>>> >>>> "... >>>> poll_nonroot_hub (grub_usb_device_t dev) >>>> { >>>> grub_usb_err_t err; >>>> unsigned i; >>>> grub_uint8_t changed; >>>> grub_size_t actual, len; >>>> >>>> if (!dev->hub_transfer) >>>> return; >>>> ..." >>>> >>>> I think, as the possible "error recovery", the better than current >>>> immediate return could be to try to call >>>> "grub_usb_bulk_read_background" >>>> to schedule new background transfer for this hub before return - ? >>>> >>>> >>>> d) >>>> Cosmetic thing: >>>> It will be fine to rename declaration >>>> static struct grub_usb_hub *hubs; >>>> to >>>> static struct grub_usb_hub *root_hubs; >>>> to be more self explanative... :-) >>>> >>>> >>>> What do You think about the points a)-d) ? >>>> >>>> BR, >>>> Ales >>>> >>>> _______________________________________________ >>>> Grub-devel mailing list >>>> Grub-devel@gnu.org >>>> https://lists.gnu.org/mailman/listinfo/grub-devel >>>> >>> >>> _______________________________________________ >>> Grub-devel mailing list >>> Grub-devel@gnu.org >>> https://lists.gnu.org/mailman/listinfo/grub-devel >>> >> >> _______________________________________________ >> Grub-devel mailing list >> Grub-devel@gnu.org >> https://lists.gnu.org/mailman/listinfo/grub-devel >> >=20 >=20 > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel >=20 ------enig2CQNPDFDNPJQNBBRGCVWW 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.14 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iF4EAREKAAYFAlI6sjoACgkQNak7dOguQgmI0AD/b/11e/d4oipPoNAOctiNgs04 vs1qa/lKQfEt9zrDzH8A/1Cq+Ioce2Bmiu1hfL5Jmww2HHyPaPHJoYlU8AckapcA =dNe7 -----END PGP SIGNATURE----- ------enig2CQNPDFDNPJQNBBRGCVWW--