RE: Missing USB devices.

[Melki Christian (consultant)]

> 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

handback.patch
Description: handback.patch