Re: Missing USB devices.

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

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 
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.com@gnu.org
>> [mailto:grub-devel-bounces+christian.melki=saabgroup.com@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
>