grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Missing USB devices.


From: Aleš Nesrsta
Subject: Re: Missing USB devices.
Date: Sat, 10 Aug 2013 00:24:31 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130806 Thunderbird/17.0.8

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]