Re: Missing USB devices.

["Aleš Nesrsta" <starous@volny.cz>]

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
>