Missing USB devices.

Missing USB devices.

[Melki Christian (consultant)]

[-- Attachment #1: Type: text/plain, Size: 727 bytes --]

Hi.

I'm running trunk version 5079 on a rather normal PC. EHCI + UHCI controller.
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

[-- Attachment #2: Type: text/html, Size: 2760 bytes --]

Re: Missing USB devices.

[Andrey Borzenkov]

В Wed, 7 Aug 2013 08:16:00 +0000
"Melki Christian (consultant)" <Christian.melki@saabgroup.com> пишет:

> Hi.
> 
> I'm running trunk version 5079 on a rather normal PC. EHCI + UHCI controller.

Did it work in earlier versions? 

> 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

RE: Missing USB devices.

[Melki Christian (consultant)]

> > 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

Re: Missing USB devices.

[Aleš Nesrsta]

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
>

Re: Missing USB devices.

[Aleš Nesrsta]

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
>

RE: Missing USB devices.

[Melki Christian (consultant)]

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?

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.
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.

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

Re: Missing USB devices.

[Aleš Nesrsta]

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
>

Re: Missing USB devices.

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 9271 bytes --]

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



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 291 bytes --]

Re: Missing USB devices.

[Aleš Nesrsta]

Hi guys,
sorry for the delay - I was too busy on business trip...


Vladimir:
...
>> 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?
Oh, sorry, maybe I missed something. (Exists/Are somewhere written some 
exact rules how to ask for patch commit?)

I sent the patch for testing at 18.7.2013 18:10 CET in ML thread named 
"[PATCH] Re: [grub-devel] loongson-2f mini-pc (fuloong) elf image 
generation.".
And I wrote some comments related to it at 23.7.2013 23:05 CET in the 
same thread.
But, you are right, nowhere is some exact asking for patch commit.


Christian:
> I'm thinking of the EHCI hand-over. In the case of EHCI handover beeing successful within the timeout, you never clear the USBLEGCTLSTS register (SMI's). You do that in the other cases however. Why? I can not think of any case of a successful handover with SMI's still enabled. To what purpose? A buggy BIOS would maybe act upon such stuff? Maybe thats a case for lost devices etc?
Yes, it could be the bug.

But it is the question:

1) I expect BIOS disables all related SMI during handover procedure of 
EHCI (or OHCI, it has similar procedure).
AFAIK, EHCI (and possibly also OHCI) specification doesn't say anything 
about resetting of SMI bits by OS after handover procedure - but maybe 
it is common thing which it is not worth mentioning.

2) According to the specification, default state of SMI bits should be 0 
-> i.e., after EHCI reset (which is done immediately after ownership 
handover) I expect these bits should be 0. But maybe I am wrong. - ?

Did you try this change? You are probably experienced programmer, so I 
expect such change should be not problem to you... :-) What result did 
you get?


> Also, I've been toying with the black magic EHCI hand-back. I've gotten it to work for some machines. The problem with GRUB and USB is that if you enable USB you have no more control over USB in case a OS needs input before loading it's own USB stack. Do you have any experience with this? Could we make such code execution optional on environment etc (because hand back is even more buggy than everything else.. :)) Maybe users can use it in corner cases when they need USB-input with usb-support in GRUB... if it'll work on their hardware that is.
I don't understand this part - What do you mean by (black magic) EHCI 
hand-back? Do you mean procedure which returns EHCI ownership back to 
the BIOS (SMM) ?
Oh, maybe I understand in this case - You are probably pointing to the 
situation when some OS boots and it wants some input from keyboard to 
select something in boot process - is it correct?
Hmm, maybe it can happen, but I didn't see such situation yet - but I am 
not expert nor OS experimenter/developer etc. :-)
AFAIK, USB drivers are loaded very early or they are (at least can be) 
integral part of any nowadays kernel. I.e., I think such situation can 
happen only in some very very special cases, so it is the question, if 
we should spent our time to try to solve it - or?


BR,
Ales

RE: Missing USB devices.

[Melki Christian (consultant)]

[-- Attachment #1: Type: text/plain, Size: 5269 bytes --]

> Hi guys,
> sorry for the delay - I was too busy on business trip...
> 
> 
> Vladimir:
> ...
> >> 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?
> Oh, sorry, maybe I missed something. (Exists/Are somewhere written some
> exact rules how to ask for patch commit?)
> 
> I sent the patch for testing at 18.7.2013 18:10 CET in ML thread named
> "[PATCH] Re: [grub-devel] loongson-2f mini-pc (fuloong) elf image
> generation.".
> And I wrote some comments related to it at 23.7.2013 23:05 CET in the same
> thread.
> But, you are right, nowhere is some exact asking for patch commit.
> 
> 
> Christian:
> > I'm thinking of the EHCI hand-over. In the case of EHCI handover beeing
> successful within the timeout, you never clear the USBLEGCTLSTS register
> (SMI's). You do that in the other cases however. Why? I can not think of any
> case of a successful handover with SMI's still enabled. To what purpose? A
> buggy BIOS would maybe act upon such stuff? Maybe thats a case for lost
> devices etc?
> Yes, it could be the bug.
> 
> But it is the question:
> 
> 1) I expect BIOS disables all related SMI during handover procedure of EHCI
> (or OHCI, it has similar procedure).
> AFAIK, EHCI (and possibly also OHCI) specification doesn't say anything about
> resetting of SMI bits by OS after handover procedure - but maybe it is
> common thing which it is not worth mentioning.
> 
> 2) According to the specification, default state of SMI bits should be 0
> -> i.e., after EHCI reset (which is done immediately after ownership
> handover) I expect these bits should be 0. But maybe I am wrong. - ?
> 
> Did you try this change? You are probably experienced programmer, so I
> expect such change should be not problem to you... :-) What result did
> you get?

I did try the change and discovered that my machines here, their BIOS:es leave the OS change bit or not touch the register at all.
One BIOS really made a mess of it all. But also to my dismay, the BIOS:es would go in and finger the SMI settings after the OS has 0:ed them.
Looking at Linux, the default(?) pci ehci quirk is to kill all SMI's.  

> > Also, I've been toying with the black magic EHCI hand-back. I've gotten it to
> work for some machines. The problem with GRUB and USB is that if you
> enable USB you have no more control over USB in case a OS needs input
> before loading it's own USB stack. Do you have any experience with this?
> Could we make such code execution optional on environment etc (because
> hand back is even more buggy than everything else.. :)) Maybe users can use
> it in corner cases when they need USB-input with usb-support in GRUB... if
> it'll work on their hardware that is.
> I don't understand this part - What do you mean by (black magic) EHCI
> hand-back? Do you mean procedure which returns EHCI ownership back to
> the BIOS (SMM) ?
> Oh, maybe I understand in this case - You are probably pointing to the
> situation when some OS boots and it wants some input from keyboard to
> select something in boot process - is it correct?
> Hmm, maybe it can happen, but I didn't see such situation yet - but I am
> not expert nor OS experimenter/developer etc. :-)
> AFAIK, USB drivers are loaded very early or they are (at least can be)
> integral part of any nowadays kernel. I.e., I think such situation can
> happen only in some very very special cases, so it is the question, if
> we should spent our time to try to solve it - or?

Exactly.
The EHCI handback is provided by the EHCI spec handover state machine. Problem is, most BIOS:es don't implement it, or just screw it up trying.
The scenario is like this:
Load grub2 with EHCI usb.
Grub2 loads windows 7 or something.
Windows 7 goes b0rk and requests input (diskcheck etc).
User only has USB-keyboard.
Eeep, can't enter anything because windows 7 has not loaded usb-stuff yet.
Most windows queries are with timeout, but some are not. Then you are just stuck forever. If you don't boot it in some other way.

Since the EHCI controller  is not yet owned by windows.. (don't know why), no input can be made.
Normally BIOS would own it until a normal OS requests it.
But now GRUB has already requested it and not handed it back.
Maybe this is not a problem with most Linux distros since they carry all USB-host drivers in initrd or builtin, I don't know. But up until windows 7, this is broken. (have not tried windows 8).

I've played with setting the correct smi-bits and then just flip the OS_OWNED flag. This should make the BIOS take over control again. I did it in the fini-hook and that function gets run when the loader starts running. Patch attach. It is just for toying, not final work or anything. :)
The patch works for some BIOS:es. Most of the time it does nothing to help. Some BIOS:es screw it up when trying to reclaim ownership however. :(

This is also why Dell's etc ship their latitude series (business computers) still with ps2 keyboard and mouse built in. :)
They expect people to run windows with cryptoloaders like macafee safeboot etc.

> 
> BR,
> Ales
> 

Regards,
Christian

[-- Attachment #2: handback.patch --]
[-- Type: application/octet-stream, Size: 2256 bytes --]

Index: grub-core/bus/usb/ehci.c
===================================================================
--- grub-core/bus/usb/ehci.c	(revision 5217)
+++ grub-core/bus/usb/ehci.c	(working copy)
@@ -332,6 +334,8 @@
   grub_ehci_td_t tdfree_virt;	/* Free Transfer Descriptors */
   int flag64;
   grub_uint32_t reset;		/* bits 1-15 are flags if port was reset from connected time or not */
+  grub_pci_device_t dev;
+  grub_uint32_t eecp_offset;
   struct grub_ehci *next;
 };
 
@@ -601,6 +605,7 @@
   /* Is there EECP ? */
   eecp_offset = (grub_ehci_ehcc_read32 (e, GRUB_EHCI_EHCC_CPARAMS)
 		 & GRUB_EHCI_EECP_MASK) >> GRUB_EHCI_EECP_SHIFT;
+  e->eecp_offset = eecp_offset;
 
   /* Check format of data structures requested by EHCI */
   /* XXX: In fact it is not used at any place, it is prepared for future
@@ -767,6 +772,7 @@
     }
 
   grub_dprintf ("ehci", "inithw: EHCI grub_ehci_pci_iter: ownership OK\n");
+  e->dev = dev;
 
   /* Now we can setup EHCI (maybe...) */
 
@@ -1899,6 +1905,9 @@
 grub_ehci_fini_hw (int noreturn __attribute__ ((unused)))
 {
   struct grub_ehci *e;
+  grub_pci_address_t pciaddr_eecp;
+  grub_uint32_t usblegsup = 0;
+  grub_uint32_t usblegctlsts = 0;
 
   /* We should disable all EHCI HW to prevent any DMA access etc. */
   for (e = ehci; e; e = e->next)
@@ -1912,9 +1921,31 @@
       grub_ehci_halt (e);
 
       /* Reset EHCI */
-      grub_ehci_reset (e);
+      grub_ehci_reset (e);      
     }
 
+  /* Try to shift ownership */
+  for (e = ehci; e; e = e->next)
+    {
+      if (e->eecp_offset)
+        {
+          pciaddr_eecp = grub_pci_make_address (e->dev, e->eecp_offset + 4);
+          usblegctlsts = grub_pci_read (pciaddr_eecp);
+          usblegctlsts |= 0x2000;
+          grub_pci_write(pciaddr_eecp, usblegctlsts);
+          usblegctlsts = grub_pci_read (pciaddr_eecp);
+
+          pciaddr_eecp = grub_pci_make_address (e->dev, e->eecp_offset);
+          usblegsup = grub_pci_read (pciaddr_eecp);
+          if (usblegsup & GRUB_EHCI_OS_OWNED)
+            {
+              usblegsup &= ~(GRUB_EHCI_OS_OWNED);
+              grub_pci_write (pciaddr_eecp, usblegsup);
+              usblegsup = grub_pci_read (pciaddr_eecp);
+            }
+        }
+    }
+
   return GRUB_USB_ERR_NONE;
 }
 
 

USB controller hand-back (original thread: Missing USB devices.)

[Aleš Nesrsta]

2.9.2013 09:01, Melki Christian (consultant) wrote:
> Exactly.
> The EHCI handback is provided by the EHCI spec handover state machine. Problem is, most BIOS:es don't implement it, or just screw it up trying.
> The scenario is like this:
> Load grub2 with EHCI usb.
> Grub2 loads windows 7 or something.
> Windows 7 goes b0rk and requests input (diskcheck etc).
> User only has USB-keyboard.
> Eeep, can't enter anything because windows 7 has not loaded usb-stuff yet.

It is surprising for me that Windows does not load USB drivers in such 
case and the above described situation can happen.
I never saw such situation in Linux, but in fact it can probably also 
happen in some (badly) customized kernels/images etc.

> I've played with setting the correct smi-bits and then just flip the OS_OWNED flag. This should make the BIOS take over control again. I did it in the fini-hook and that function gets run when the loader starts running. Patch attach. It is just for toying, not final work or anything. :)
> The patch works for some BIOS:es. Most of the time it does nothing to help. Some BIOS:es screw it up when trying to reclaim ownership however. :(

Interesting. According to results of your experiments it looks like 
really black magic... But maybe it is correct even if we will possibly 
don't like it - see next...

Your patch fits exactly the EHCI specification.
Maybe the patch should include some loop with timeout - waiting for 
finish of "reverse" handover (or, as you say - hand-back).
(And possibly there should be some cosmetic changes related to GRUB 
coding etc., but don't care yet...)

But, anyway, the patch should work in the case when BIOS is correctly 
following EHCI specification "OS Ownership State Machine" in reverse 
direction (OS -> BIOS) together with restarting of legacy USB support. 
So, there is question for the Vladimir, if GRUB will take care about 
"hand-back". If yes, something like that should be implemented also into 
OHCI and UHCI driver.

But, there are at least two questions:
- What happens if BIOS doesn't work correctly during hand-back? Can it 
freeze/crash PC in some way, make it unstable etc.? Can this situation 
prevent ownership handover in driver of booted OS?
- As I don't know details about BIOSes and SMM etc., I am little bit 
afraid of one thing: couldn't happen something wrong with loaded OS 
kernel when BIOS takes ownership of USB controller? I mean e.g. if in 
the case of hand-back cannot happen some memory collision between BIOS 
and loaded/booted kernel/image etc.

Additionally, EHCI specification doesn't say that BIOS (SMM) really must 
implement hand-back and immediately start again legacy support - EHCI 
specifies only handover mechanism. So, in fact, BIOS which does nothing 
in the hand-back case is probably correct - at least according to EHCI 
specification...

If hand-back could be dangerous in some way or could have some 
unexpected/unwanted behavior in some cases, I expect it will be better 
to don't implement it (or implement it only as some very special option 
for experts - but I have no idea in which way...).

What is Vladimir's opinion?

BR,
Ales

Re: USB controller hand-back (original thread: Missing USB devices.)

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 3013 bytes --]

On 02.09.2013 23:33, Aleš Nesrsta wrote:
> 2.9.2013 09:01, Melki Christian (consultant) wrote:
>> Exactly.
>> The EHCI handback is provided by the EHCI spec handover state machine.
>> Problem is, most BIOS:es don't implement it, or just screw it up trying.
>> The scenario is like this:
>> Load grub2 with EHCI usb.
>> Grub2 loads windows 7 or something.
>> Windows 7 goes b0rk and requests input (diskcheck etc).
>> User only has USB-keyboard.
>> Eeep, can't enter anything because windows 7 has not loaded usb-stuff
>> yet.
> 
> It is surprising for me that Windows does not load USB drivers in such
> case and the above described situation can happen.
> I never saw such situation in Linux, but in fact it can probably also
> happen in some (badly) customized kernels/images etc.
> 
>> I've played with setting the correct smi-bits and then just flip the
>> OS_OWNED flag. This should make the BIOS take over control again. I
>> did it in the fini-hook and that function gets run when the loader
>> starts running. Patch attach. It is just for toying, not final work or
>> anything. :)
>> The patch works for some BIOS:es. Most of the time it does nothing to
>> help. Some BIOS:es screw it up when trying to reclaim ownership
>> however. :(
> 
> Interesting. According to results of your experiments it looks like
> really black magic... But maybe it is correct even if we will possibly
> don't like it - see next...
> - As I don't know details about BIOSes and SMM etc., I am little bit
> afraid of one thing: couldn't happen something wrong with loaded OS
> kernel when BIOS takes ownership of USB controller? I mean e.g. if in
> the case of hand-back cannot happen some memory collision between BIOS
> and loaded/booted kernel/image etc.
> 
Linux or any other natively supported payload should handle the problem
correctly
As for chainloading targets, the only way to make sure that they work is
to stick to BIOS drivers and not load native drivers at all.
Do you have a scenario when loading native drivers is necessary when
loading chainloaded target?
> Additionally, EHCI specification doesn't say that BIOS (SMM) really must
> implement hand-back and immediately start again legacy support - EHCI
> specifies only handover mechanism. So, in fact, BIOS which does nothing
> in the hand-back case is probably correct - at least according to EHCI
> specification...
> 
You're correct. Hand-back should never be attempted both for
specification and practical reasons.
> If hand-back could be dangerous in some way or could have some
> unexpected/unwanted behavior in some cases, I expect it will be better
> to don't implement it (or implement it only as some very special option
> for experts - but I have no idea in which way...).
> 
> What is Vladimir's opinion?
> 
> BR,
> Ales
> 
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
> 



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 291 bytes --]

RE: USB controller hand-back (original thread: Missing USB devices.)

[Melki Christian (consultant)]

> 2.9.2013 09:01, Melki Christian (consultant) wrote:
> > Exactly.
> > The EHCI handback is provided by the EHCI spec handover state machine.
> Problem is, most BIOS:es don't implement it, or just screw it up trying.
> > The scenario is like this:
> > Load grub2 with EHCI usb.
> > Grub2 loads windows 7 or something.
> > Windows 7 goes b0rk and requests input (diskcheck etc).
> > User only has USB-keyboard.
> > Eeep, can't enter anything because windows 7 has not loaded usb-stuff
> yet.
> 
> It is surprising for me that Windows does not load USB drivers in such case
> and the above described situation can happen.
> I never saw such situation in Linux, but in fact it can probably also happen in
> some (badly) customized kernels/images etc.
> 
> > I've played with setting the correct smi-bits and then just flip the
> > OS_OWNED flag. This should make the BIOS take over control again. I
> > did it in the fini-hook and that function gets run when the loader
> > starts running. Patch attach. It is just for toying, not final work or
> > anything. :) The patch works for some BIOS:es. Most of the time it
> > does nothing to help. Some BIOS:es screw it up when trying to reclaim
> > ownership however. :(
> 
> Interesting. According to results of your experiments it looks like really black
> magic... But maybe it is correct even if we will possibly don't like it - see
> next...
> 
> Your patch fits exactly the EHCI specification.
> Maybe the patch should include some loop with timeout - waiting for finish
> of "reverse" handover (or, as you say - hand-back).
> (And possibly there should be some cosmetic changes related to GRUB
> coding etc., but don't care yet...)

That would not work. Because the SMI interrupts take the CPU out of GRUB control and into the BIOS.
Unless you have another interrupt source to bring you back somehow, you are in the mercy of the BIOS code to complete.
That's why for the most of the time OS developers (especially realtime guys), HATE SMI's. :)
The last pci-write take the control out of GRUB context and execution can hang there, never returning from a buggy BIOS, atleast in GRUB's case.

> But, anyway, the patch should work in the case when BIOS is correctly
> following EHCI specification "OS Ownership State Machine" in reverse
> direction (OS -> BIOS) together with restarting of legacy USB support.
> So, there is question for the Vladimir, if GRUB will take care about "hand-
> back". If yes, something like that should be implemented also into OHCI and
> UHCI driver.
> 
> But, there are at least two questions:
> - What happens if BIOS doesn't work correctly during hand-back? Can it
> freeze/crash PC in some way, make it unstable etc.? Can this situation
> prevent ownership handover in driver of booted OS?

One machine took endlessly long time to enumerate USB (3 minutes before handing back control to GRUB).
The same machine also crashed in windows loading like 50% of the time, most probably to screwed USB somehow (I am not a windows guy).
I would still say that's probably a windows bug, The BIOS beeing slow to re-enumerate is a BIOS bug.

> - As I don't know details about BIOSes and SMM etc., I am little bit afraid of
> one thing: couldn't happen something wrong with loaded OS kernel when
> BIOS takes ownership of USB controller? I mean e.g. if in the case of hand-
> back cannot happen some memory collision between BIOS and
> loaded/booted kernel/image etc.

I don't understand. A normal procedure would be to give it back to BIOS.
And then as OS loads, do the same handover procedure as you would normally do.
But since BIOS'es are far to buggy in this regard, I would not trust this mechanism at all as any default.

> Additionally, EHCI specification doesn't say that BIOS (SMM) really must
> implement hand-back and immediately start again legacy support - EHCI
> specifies only handover mechanism. So, in fact, BIOS which does nothing in
> the hand-back case is probably correct - at least according to EHCI
> specification...
> 
> If hand-back could be dangerous in some way or could have some
> unexpected/unwanted behavior in some cases, I expect it will be better to
> don't implement it (or implement it only as some very special option for
> experts - but I have no idea in which way...).

Exactly. This code might still be preferred by some targets shipping custom systems.
So maybe not include this code at all as default, but somehow present it as option to integrators of systems who know how their BIOS'es behave?
It's still a neat option to have if you know it works correctly on your system.

> What is Vladimir's opinion?
> 
> BR,
> Ales
> 
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel

RE: Missing USB devices.

[Melki Christian (consultant)]

Ales,

I'm thinking of the EHCI hand-over. In the case of EHCI handover beeing successful within the timeout, you never clear the USBLEGCTLSTS register (SMI's). You do that in the other cases however. Why? I can not think of any case of a successful handover with SMI's still enabled. To what purpose? A buggy BIOS would maybe act upon such stuff? Maybe thats a case for lost devices etc?
Also, I've been toying with the black magic EHCI hand-back. I've gotten it to work for some machines. The problem with GRUB and USB is that if you enable USB you have no more control over USB in case a OS needs input before loading it's own USB stack. Do you have any experience with this? Could we make such code execution optional on environment etc (because hand back is even more buggy than everything else.. :)) Maybe users can use it in corner cases when they need USB-input with usb-support in GRUB... if it'll work on their hardware that is.

Regards,
Christian 

Re: Missing USB devices.

[Aleš Nesrsta]

28.8.2013 08:59, Melki Christian (consultant) wrote:
> I'm thinking of the EHCI hand-over. In the case of EHCI handover beeing successful within the timeout, you never clear the USBLEGCTLSTS register (SMI's). You do that in the other cases however. Why? I can not think of any case of a successful handover with SMI's still enabled. To what purpose? A buggy BIOS would maybe act upon such stuff? Maybe thats a case for lost devices etc?
Ok, I made a short look into Linux USB source code and I saw there is 
USBLEGCTLSTS register reset in any case.
(What is maybe more interesting, Linux driver DOES NOT handover on some 
(broken) devices, only reset SMI...)

So I prepared simple "SMI" patch (attached).

BR,
Ales

[PATCH] Re: Missing USB devices.

[Aleš Nesrsta]

[-- Attachment #1: Type: text/plain, Size: 794 bytes --]

Sorry, I missed the patch... :-)
There it is.

> 28.8.2013 08:59, Melki Christian (consultant) wrote:
>> I'm thinking of the EHCI hand-over. In the case of EHCI handover
>> beeing successful within the timeout, you never clear the USBLEGCTLSTS
>> register (SMI's). You do that in the other cases however. Why? I can
>> not think of any case of a successful handover with SMI's still
>> enabled. To what purpose? A buggy BIOS would maybe act upon such
>> stuff? Maybe thats a case for lost devices etc?
> Ok, I made a short look into Linux USB source code and I saw there is
> USBLEGCTLSTS register reset in any case.
> (What is maybe more interesting, Linux driver DOES NOT handover on some
> (broken) devices, only reset SMI...)
>
> So I prepared simple "SMI" patch (attached).
>
> BR,
> Ales

[-- Attachment #2: usb_patch_130831.diff --]
[-- Type: text/x-patch, Size: 2060 bytes --]

diff -purB ./grub/grub-core/bus/usb/ehci.c ./grub_patched/grub-core/bus/usb/ehci.c
--- ./grub/grub-core/bus/usb/ehci.c	2013-05-12 23:15:17.857567000 +0200
+++ ./grub_patched/grub-core/bus/usb/ehci.c	2013-08-31 20:00:54.846788313 +0200
@@ -716,7 +716,7 @@ grub_ehci_pci_iter (grub_pci_device_t de
       usblegsup = grub_pci_read (pciaddr_eecp);
       if (usblegsup & GRUB_EHCI_BIOS_OWNED)
 	{
-	  grub_boot_time ("Taking ownership of EHCI port");
+	  grub_boot_time ("Taking ownership of EHCI controller");
 	  grub_dprintf ("ehci",
 			"EHCI grub_ehci_pci_iter: EHCI owned by: BIOS\n");
 	  /* Ownership change - set OS_OWNED bit */
@@ -737,13 +737,8 @@ grub_ehci_pci_iter (grub_pci_device_t de
 	      grub_pci_write (pciaddr_eecp, GRUB_EHCI_OS_OWNED);
 	      /* Ensure PCI register is written */
 	      grub_pci_read (pciaddr_eecp);
-	      /* Disable SMI.  */
-	      pciaddr_eecp = grub_pci_make_address (dev, eecp_offset + 4);
-	      grub_pci_write (pciaddr_eecp, 0);
-	      /* Ensure PCI register is written */
-	      grub_pci_read (pciaddr_eecp);
 	    }
-	  grub_boot_time ("Ownership of EHCI port taken");
+	  grub_boot_time ("Ownership of EHCI controller taken");
 	}
       else if (usblegsup & GRUB_EHCI_OS_OWNED)
 	/* XXX: What to do in this case - nothing ? Can it happen ? */
@@ -758,14 +753,15 @@ grub_ehci_pci_iter (grub_pci_device_t de
 	  grub_pci_write (pciaddr_eecp, GRUB_EHCI_OS_OWNED);
 	  /* Ensure PCI register is written */
 	  grub_pci_read (pciaddr_eecp);
-	  /* Disable SMI, just to be sure.  */
-	  pciaddr_eecp = grub_pci_make_address (dev, eecp_offset + 4);
-	  grub_pci_write (pciaddr_eecp, 0);
-	  /* Ensure PCI register is written */
-	  grub_pci_read (pciaddr_eecp);
 	}
     }
 
+  /* Disable SMI, just to be sure.  */
+  pciaddr_eecp = grub_pci_make_address (dev, eecp_offset + 4);
+  grub_pci_write (pciaddr_eecp, 0);
+  /* Ensure PCI register is written */
+  grub_pci_read (pciaddr_eecp);
+
   grub_dprintf ("ehci", "inithw: EHCI grub_ehci_pci_iter: ownership OK\n");
 
   /* Now we can setup EHCI (maybe...) */

[PATCH] Re: Missing USB devices.

[Aleš Nesrsta]

[-- Attachment #1: Type: text/plain, Size: 1100 bytes --]

Hmmm, today is not a good day - I sent wrong patch with mistake, 
sorry... :-(

I hope attached patch is finally OK...

BR,
Ales

> Sorry, I missed the patch... :-)
> There it is.
>
>> 28.8.2013 08:59, Melki Christian (consultant) wrote:
>>> I'm thinking of the EHCI hand-over. In the case of EHCI handover
>>> beeing successful within the timeout, you never clear the USBLEGCTLSTS
>>> register (SMI's). You do that in the other cases however. Why? I can
>>> not think of any case of a successful handover with SMI's still
>>> enabled. To what purpose? A buggy BIOS would maybe act upon such
>>> stuff? Maybe thats a case for lost devices etc?
>> Ok, I made a short look into Linux USB source code and I saw there is
>> USBLEGCTLSTS register reset in any case.
>> (What is maybe more interesting, Linux driver DOES NOT handover on some
>> (broken) devices, only reset SMI...)
>>
>> So I prepared simple "SMI" patch (attached).
>>
>> BR,
>> Ales
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
>

[-- Attachment #2: usb_patch_130831.patch --]
[-- Type: text/x-patch, Size: 1945 bytes --]

--- ./grub/grub-core/bus/usb/ehci.c	2013-05-12 23:15:17.857567000 +0200
+++ ./grub_patched/grub-core/bus/usb/ehci.c	2013-08-31 23:03:54.587218402 +0200
@@ -716,7 +716,7 @@ grub_ehci_pci_iter (grub_pci_device_t de
       usblegsup = grub_pci_read (pciaddr_eecp);
       if (usblegsup & GRUB_EHCI_BIOS_OWNED)
 	{
-	  grub_boot_time ("Taking ownership of EHCI port");
+	  grub_boot_time ("Taking ownership of EHCI controller");
 	  grub_dprintf ("ehci",
 			"EHCI grub_ehci_pci_iter: EHCI owned by: BIOS\n");
 	  /* Ownership change - set OS_OWNED bit */
@@ -737,13 +737,8 @@ grub_ehci_pci_iter (grub_pci_device_t de
 	      grub_pci_write (pciaddr_eecp, GRUB_EHCI_OS_OWNED);
 	      /* Ensure PCI register is written */
 	      grub_pci_read (pciaddr_eecp);
-	      /* Disable SMI.  */
-	      pciaddr_eecp = grub_pci_make_address (dev, eecp_offset + 4);
-	      grub_pci_write (pciaddr_eecp, 0);
-	      /* Ensure PCI register is written */
-	      grub_pci_read (pciaddr_eecp);
 	    }
-	  grub_boot_time ("Ownership of EHCI port taken");
+	  grub_boot_time ("Ownership of EHCI controller taken");
 	}
       else if (usblegsup & GRUB_EHCI_OS_OWNED)
 	/* XXX: What to do in this case - nothing ? Can it happen ? */
@@ -758,12 +753,14 @@ grub_ehci_pci_iter (grub_pci_device_t de
 	  grub_pci_write (pciaddr_eecp, GRUB_EHCI_OS_OWNED);
 	  /* Ensure PCI register is written */
 	  grub_pci_read (pciaddr_eecp);
-	  /* Disable SMI, just to be sure.  */
-	  pciaddr_eecp = grub_pci_make_address (dev, eecp_offset + 4);
-	  grub_pci_write (pciaddr_eecp, 0);
-	  /* Ensure PCI register is written */
-	  grub_pci_read (pciaddr_eecp);
 	}
+
+    /* Disable SMI, just to be sure.  */
+    pciaddr_eecp = grub_pci_make_address (dev, eecp_offset + 4);
+    grub_pci_write (pciaddr_eecp, 0);
+    /* Ensure PCI register is written */
+    grub_pci_read (pciaddr_eecp);
+
     }
 
   grub_dprintf ("ehci", "inithw: EHCI grub_ehci_pci_iter: ownership OK\n");

RE: [PATCH] Re: Missing USB devices.

[Melki Christian (consultant)]

Yes. My patch looked exactly like that. Minus the comment changes. ;)
I can not see any harm from this while running. Maybe this needs to be tested more?
Linux looks like it has it as default.
linux-3.10/drivers/usb/host/pci-quirks.c. Looks like it hands over from BIOS and disable the ehci-controller in preparation for the EHCI driver.

Regards,
Christian

> -----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 31 augusti 2013 23:13
> To: The development of GNU GRUB
> Subject: [PATCH] Re: Missing USB devices.
> 
> Hmmm, today is not a good day - I sent wrong patch with mistake, sorry... :-(
> 
> I hope attached patch is finally OK...
> 
> BR,
> Ales
> 
> > Sorry, I missed the patch... :-)
> > There it is.
> >
> >> 28.8.2013 08:59, Melki Christian (consultant) wrote:
> >>> I'm thinking of the EHCI hand-over. In the case of EHCI handover
> >>> beeing successful within the timeout, you never clear the
> >>> USBLEGCTLSTS register (SMI's). You do that in the other cases
> >>> however. Why? I can not think of any case of a successful handover
> >>> with SMI's still enabled. To what purpose? A buggy BIOS would maybe
> >>> act upon such stuff? Maybe thats a case for lost devices etc?
> >> Ok, I made a short look into Linux USB source code and I saw there is
> >> USBLEGCTLSTS register reset in any case.
> >> (What is maybe more interesting, Linux driver DOES NOT handover on
> >> some
> >> (broken) devices, only reset SMI...)
> >>
> >> So I prepared simple "SMI" patch (attached).
> >>
> >> BR,
> >> Ales
> >
> >
> > _______________________________________________
> > Grub-devel mailing list
> > Grub-devel@gnu.org
> > https://lists.gnu.org/mailman/listinfo/grub-devel
> >

Re: [PATCH] Re: Missing USB devices.

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 323 bytes --]

On 31.08.2013 23:12, Aleš Nesrsta wrote:
> -	  grub_boot_time ("Ownership of EHCI port taken");
> +	  grub_boot_time ("Ownership of EHCI controller taken");
This has to be after SMI_EN is written as writes to SMI_EN may cause SMI
which would take time and may cause trouble. Other than this go ahead
for the patch


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 291 bytes --]

Re: [PATCH] Re: Missing USB devices.

[Aleš Nesrsta]

OK, committed.
I simply removed the line you mentioned...
BR, Ales

Dne 23.9.2013 14:47, Vladimir 'φ-coder/phcoder' Serbinenko napsal(a):
> On 31.08.2013 23:12, Aleš Nesrsta wrote:
>> -	  grub_boot_time ("Ownership of EHCI port taken");
>> +	  grub_boot_time ("Ownership of EHCI controller taken");
> This has to be after SMI_EN is written as writes to SMI_EN may cause SMI
> which would take time and may cause trouble. Other than this go ahead
> for the patch
>
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
>