From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1UzAvk-0006at-Pm for mharc-grub-devel@gnu.org; Tue, 16 Jul 2013 15:29:00 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49458) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UzAvg-0006ak-Sn for grub-devel@gnu.org; Tue, 16 Jul 2013 15:28:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UzAvc-0008CA-Rf for grub-devel@gnu.org; Tue, 16 Jul 2013 15:28:56 -0400 Received: from smtp.volny.cz ([2001:4de8:71c:62::33]:53064) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UzAvc-0008B6-HB for grub-devel@gnu.org; Tue, 16 Jul 2013 15:28:52 -0400 Received: from [192.168.6.11] (unknown [193.86.90.90]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: starous@volny.cz) by smtp.volny.cz (Postfix) with ESMTPSA id 9F9AD260B79 for ; Tue, 16 Jul 2013 21:28:50 +0200 (CEST) Message-ID: <51E59EFE.6080301@volny.cz> Date: Tue, 16 Jul 2013 21:29:02 +0200 From: =?windows-1252?Q?Ale=9A_Nesrsta?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: The development of GNU GRUB Subject: 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> In-Reply-To: <51E59E32.4080608@volny.cz> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4de8:71c:62::33 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: Tue, 16 Jul 2013 19:28:59 -0000 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 same > 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 least > 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 of > 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 control > 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 probably > 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 problem >> 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 when >> 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 tests >> (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 these >> situations. >> >> So I went through Your changes in usbhub.c and other USB related files. >> 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 which >> 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 working, >> but it can slow down handling of USB devices (mainly in USB "starting" >> 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 bit >> changed, it is not correct to call "attach_root_port" immediately when >> "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 >