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
> address@hidden
> https://lists.gnu.org/mailman/listinfo/grub-devel