From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1V7rPq-0007rR-53 for mharc-grub-devel@gnu.org; Fri, 09 Aug 2013 14:27:58 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51648) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V7rPi-0007q7-28 for grub-devel@gnu.org; Fri, 09 Aug 2013 14:27:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V7rPc-0005tw-JN for grub-devel@gnu.org; Fri, 09 Aug 2013 14:27:49 -0400 Received: from smtp.volny.cz ([2001:4de8:71c:62::33]:60319) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V7rPc-0005tV-D3 for grub-devel@gnu.org; Fri, 09 Aug 2013 14:27:44 -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 DD546260A79 for ; Fri, 9 Aug 2013 20:27:40 +0200 (CEST) Message-ID: <520534A0.4030009@volny.cz> Date: Fri, 09 Aug 2013 20:27:44 +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: Missing USB devices. References: <20130807201137.08332daf@opensuse.site> In-Reply-To: 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: Fri, 09 Aug 2013 18:27:56 -0000 Hi, please send output of lspci -vvv lsusb -vvv Run it as root or via sudo. Some general advices: 1. Do not include "insmod usb_keyboard" - this module should be loaded automatically from usb module. 2. If Your keyboard is connected to USB controller via hub (it can be internal, integrated in PC), try my patch which I sent in thread "[PATCH] Re: [grub-devel] loongson-2f mini-pc (fuloong) elf image generation." (sent at 18.7.2013 18:10 CET). AFAIK, this patch is not included in trunk yet (I didn't commit it yet - and probably nobody else) - it may help (if it is Your case). BR, Ales Dne 8.8.2013 09:22, Melki Christian (consultant) napsal(a): >>> Hi. >>> >>> I'm running trunk version 5079 on a rather normal PC. EHCI + UHCI >> controller. >> >> Did it work in earlier versions? > > I made a rather big jump... > from a backported usb stack on 1.99 to trunk. :( > Anyway, I solved both my problems. > I solved them both with letting devices settle before using them. > Don't know why, and I don't like the solution either (letting devices settle that is...) > The keyboard seems just to take a while to get identified properly. > So I do a sleep interruptible to drive the getkey -> usb_poll and let the devices get detected. > > If I just do: > > insmod ehci > insmod uhci > insmod usb_keyboard > > > > things just break... and I get stalls forever from grub when it is trying to talk to the keyboard. > > If I insert a sleep -i 5 before using it and look at the debug from the keyboards I can see that > the keyboards get initialized (takes a while) and then it is perfectly fine to use it. > > This is ugly, I don't like it and there is atleast one bug or an archtectural problem somewhere. > Btw, normal sleep should do the same as interruptible? > Just do the same and throw away the getkey result. > I don't get why they are assymetrical? There is no halt or powersaving anyway. > Normal sleep just stops processing anything since grub is driven from the term layer. > That's just annoying. > >> >>> I load all USB drivers including OHCI. Now with this latest version GRUB >> doesn't seem to want to talk to my keyboard anymore. >>> If I replug the device and reload usb_keyboard then it might work, but not >> right off the bat. >>> I also have a CCID smartcard reader and it is the same story there. >>> A normal keyboard plugged while running seems to work just fine though. >>> All devices are listed with the "usb" command. It looks like it can do >>> control transfers but not real transfers. (lost configuration, reset device?) I >> noticed that Ales had a similar problem with the fuloong device with OHCI. I >> don't run OHCI so... >>> >>> I am a little bit lost > > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel >