On 27.08.2013 22:21, Aleš Nesrsta wrote: > 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 don't see any messages in mymailbox from you tagged as pending patches. Can you tell me the date and subject? > I am not sure if I can commit this patch without his agreement or at > 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 > 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 >> hook-based and only thing >> that happens is that the refcounter goes up if I load them more than >> one 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 > "duplicate/redundant" module loading etc. - that's the main reason why I > recommended to test another situation. I don't expect such bug - but who > 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 >> doing 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 >> way 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 >> going to break a couple of cases of exotic hardware too. > > 1. > I didn't such (nativedisk related) changes in USB drivers, it is some > "global" action of other developers... > I was surprised myself little bit with this GRUB behavior change at the > time when I wanted to debug EHCI module some time ago -> for the first > time I thought it is some GRUB bug... :-) > > To understand: I am really not typical GRUB developer/contributor - I > participate in GRUB development only from time to time and more or less > I am interested only in things very closed to USB. Additionally, I am > monitoring only ML, not discussion(s) on IRC. -> So, I missed > discussions/patches related to nativedisk philosophy (and many other > things...). -> I have no exact overview how it is done nor why it is > done in this way etc. -> So currently I cannot say anything positive or > negative about nativedisk and related changes in USB modules -> I > suppose it is probably something more or less experimental, not > 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 > something like that: > When You load USB module, You "disconnect" from BIOS any device which is > connected to related USB controller - possibly also some mass storage > device(s) or keyboard(s) which were used by GRUB as BIOS disk(s) or BIOS > keyboard(s) up to this time. > When (later) GRUB calls BIOS routines related to such "disconnected" > device(s), it can crash/freeze (BIOSes are sometimes (often?) buggy...). > AFAIK, GRUB has no way how to (automatically) prevent such BIOS call of > "disconnected" device(s) - GRUB probably has no chance to get > information how the BIOS disk/keyboard is connected to PC (to which > controller) etc. > From my point of view, something like that could be one of the reasons > why loading of USB modules requires nativedisk - maybe developers > decided it will be better to avoid such situation even if the nativedisk > solution can bring another problems... > > 3. > I agree that the nativedisk is unfortunately really slow, and, of > 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 > well on my PC - GRUB found only two disks from my three connected disks > in nativedisk mode (as I remember, it found only SATA disks, not PATA > disk - or something like that) - but maybe it is solved now, I didn't > test it again yet. > > BR, > Ales > >> >> Regards, >> C >>> -----Original Message----- >>> From: grub-devel-bounces+christian.melki=saabgroup....@gnu.org >>> [mailto:grub-devel-bounces+christian.melki=saabgroup....@gnu.org] On >>> Behalf Of Aleš 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š 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 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 >>>>> >>>>> <use getkey here in some program> >>>>> >>>>> 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 >>>>> >>>> >>>> _______________________________________________ >>>> 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 >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
