From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1VEPld-0005wS-DK for mharc-grub-devel@gnu.org; Tue, 27 Aug 2013 16:21:33 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54213) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VEPlW-0005vG-6f for grub-devel@gnu.org; Tue, 27 Aug 2013 16:21:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VEPlQ-0000bH-9o for grub-devel@gnu.org; Tue, 27 Aug 2013 16:21:26 -0400 Received: from smtp.volny.cz ([62.44.29.27]:45621) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VEPlP-0000ah-Sl for grub-devel@gnu.org; Tue, 27 Aug 2013 16:21:20 -0400 Received: from [10.131.27.54] (unknown [88.128.80.10]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: starous) by smtp.volny.cz (Postfix) with ESMTPSA id AF107260C0B for ; Tue, 27 Aug 2013 22:21:08 +0200 (CEST) Message-ID: <521D0A45.5000407@volny.cz> Date: Tue, 27 Aug 2013 22:21:25 +0200 From: =?ISO-8859-2?Q?Ale=B9_Nesrsta?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130704 Icedove/17.0.7 MIME-Version: 1.0 To: The development of GNU GRUB Subject: Re: Missing USB devices. References: <20130807201137.08332daf@opensuse.site> <520534A0.4030009@volny.cz> <52056C1F.5070003@volny.cz> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 62.44.29.27 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, 27 Aug 2013 20:21:32 -0000 On 08/27/13 13:37, Melki Christian (consultant) wrote: > Hi Ales. > > Sorry that I have not replied yet. I've been busy doing other stuff. > Actually, life seems a little bit brighter with the patch. Not as many = lost devices anyway. > Im running it now and it does not seem to cause any problems anyway, so= I think it should be comitted? I am waiting mainly for Vladimir's "Go on!" :-) I am not sure if I can commit this patch without his agreement or at=20 least his comment/code review - even if the patch solves real bug. But maybe I missed related Vladimir's post in ML. BTW, You are probably the first one, who reports any experience with=20 this patch - thanks. > > Regarding the latest stuff with nativedisk etc (which I don't like...). > It should not matter how I load modues or when I load them. They are ho= ok-based and only thing > that happens is that the refcounter goes up if I load them more than on= e time. > If GRUB determines that it needs some module early, that's fine with me= . I don't really care that it loads modules that it think it needs. OK, I agree -> But possibly there could be some bug related to=20 "duplicate/redundant" module loading etc. - that's the main reason why I=20 recommended to test another situation. I don't expect such bug - but who=20 knows... > I have also removed bios-fw-disk disabling from all usb-drivers. > I think it's just stupid to assume that because you load usb you are do= ing mass storage and thus need nativedisk. > Im doing perfectly fine without nativedisk and with usb-support enabled= . > I prefer going all native or just keeping the ata and ahci out of the w= ay until you really need them. > Native disk switching is really slow and so is the disk access in some = cases. > Disabling bios support for disk access and going native is probably goi= ng to break a couple of cases of exotic hardware too. 1. I didn't such (nativedisk related) changes in USB drivers, it is some=20 "global" action of other developers... I was surprised myself little bit with this GRUB behavior change at the=20 time when I wanted to debug EHCI module some time ago -> for the first=20 time I thought it is some GRUB bug... :-) To understand: I am really not typical GRUB developer/contributor - I=20 participate in GRUB development only from time to time and more or less=20 I am interested only in things very closed to USB. Additionally, I am=20 monitoring only ML, not discussion(s) on IRC. -> So, I missed=20 discussions/patches related to nativedisk philosophy (and many other=20 things...). -> I have no exact overview how it is done nor why it is=20 done in this way etc. -> So currently I cannot say anything positive or=20 negative about nativedisk and related changes in USB modules -> I=20 suppose it is probably something more or less experimental, not=20 final/release state... 2. I think maybe it is not so easy as You may imagine. I have no detailed information/knowledge but there could happen=20 something like that: When You load USB module, You "disconnect" from BIOS any device which is=20 connected to related USB controller - possibly also some mass storage=20 device(s) or keyboard(s) which were used by GRUB as BIOS disk(s) or BIOS=20 keyboard(s) up to this time. When (later) GRUB calls BIOS routines related to such "disconnected"=20 device(s), it can crash/freeze (BIOSes are sometimes (often?) buggy...). AFAIK, GRUB has no way how to (automatically) prevent such BIOS call of=20 "disconnected" device(s) - GRUB probably has no chance to get=20 information how the BIOS disk/keyboard is connected to PC (to which=20 controller) etc. From my point of view, something like that could be one of the reasons=20 why loading of USB modules requires nativedisk - maybe developers=20 decided it will be better to avoid such situation even if the nativedisk=20 solution can bring another problems... 3. I agree that the nativedisk is unfortunately really slow, and, of=20 course, possibly it cannot be used on more or less non standard HW. Additionally, it looks like the native AHCI driver is maybe not working=20 well on my PC - GRUB found only two disks from my three connected disks=20 in nativedisk mode (as I remember, it found only SATA disks, not PATA=20 disk - or something like that) - but maybe it is solved now, I didn't=20 test it again yet. BR, Ales > > Regards, > C >> -----Original Message----- >> From: grub-devel-bounces+christian.melki=3Dsaabgroup.com@gnu.org >> [mailto:grub-devel-bounces+christian.melki=3Dsaabgroup.com@gnu.org] On >> Behalf Of Ale=B9 Nesrsta >> Sent: den 10 augusti 2013 00:25 >> To: The development of GNU GRUB >> Subject: Re: Missing USB devices. >> >> Hi, >> I forgot one important thing - try to use "nativedisk" command instead= of >> separate loading ehci&uhci modules. >> BR, >> Ales >> >> Dne 9.8.2013 20:27, Ale=B9 Nesrsta napsal(a): >>> 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 ye= t >>> - 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 device= s >>>> 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 le= t >>>> 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 fro= m >>>> the term layer. >>>> That's just annoying. >>>> >>>>> >>>>>> I load all USB drivers including OHCI. Now with this latest versio= n >>>>>> 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 ca= n >>>>>> do control transfers but not real transfers. (lost configuration, >>>>>> reset >>>>>> device?) I >>>>> noticed that Ales had a similar problem with the fuloong device wit= h >>>>> 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 >>>> >>> >>> _______________________________________________ >>> 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 >