Re: Missing USB devices.

[Vladimir 'φ-coder/phcoder' Serbinenko]

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: address@hidden
>>> [mailto:address@hidden 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
>>>>> address@hidden
>>>>> https://lists.gnu.org/mailman/listinfo/grub-devel
>>>>>
>>>>
>>>> _______________________________________________
>>>> Grub-devel mailing list
>>>> address@hidden
>>>> https://lists.gnu.org/mailman/listinfo/grub-devel
>>>>
>>>
>>> _______________________________________________
>>> Grub-devel mailing list
>>> address@hidden
>>> https://lists.gnu.org/mailman/listinfo/grub-devel
>>
>> _______________________________________________
>> Grub-devel mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/grub-devel
>>
> 
> _______________________________________________
> Grub-devel mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/grub-devel
>

signature.asc
Description: OpenPGP digital signature