Well, back to it.
After a few more tests, I found that the BIOS (SMM) does not restore the companion controllers to their default state, nor does it the EHCI controller. Once I ask for control, the BIOS simply stops catching SMIs, leaving the controllers as they were when I requested control.
To remedy this, I had to set the EHCI's Config bit to 1, gaining control of all companions, *then* setting the Owner bit in each port so that the companions would take over each port. i.e.: restoring the state of the controller(s) to non-EHCI aware/separate independent companion controllers (UHCIs). I had to do it in that order too. If I skipped setting the Config bit, but set the Owner bit in each port, this didn't work, and visa-versa, only setting the Config bit didn't work either.
This was a must, or the BIOS would not release control of the next EHCI. At first, I thought that when I found an EHCI, I could reset it, initialize it to what I wanted, then as one of the last things, give ownership to all companion controllers. Besides, my USB stack will regain control if it finds a high-speed device attached anyway. However, since I have a multi-threading kernel, what happens if my USB stack finds a high-speed device *before* another thread finds the next EHCI? This happened a few times.
I could always make the "USB Stack" thread sleep for 20 seconds or so to make sure that the "PCI Enumerate" thread was done first, either having the "USB Stack" thread wake up after 20 seconds, or have the "PCI Enumerate" thread awaken the "USB Stack" thread.
I decided to go a little different route. Before I start the "PCI Enumerate" thread, another one scans all PCI devices for EHCI controllers, requesting ownership, restoring all companions to the default non-EHCI aware state. This way no matter what, all EHCIs and their companions are already mine when I begin to enumerate them.
This technique works on all machines I tested with, always releasing ownership.
I never did get back to the problem of having the BIOS report an 8042 that had a translation bit that would toggle, yet still only return set 1, i.e.: Translation On no matter the setting of the translation bit. Maybe another day.
Thanks for "listening". I hope that if someone else ever finds this problem, they will be able to find this thread and figure it out.
Ben
http://www.fysnet.net/osdesign_book_series.htm