Intel Sd Host Controller Windows 7
Ariano Waiker
I have connected a second monitor to the USB 3.1 port on my HP EliteBook 850 G5. Everything worked fine at first. However, when I remove the plug from the USB 3.1 port and plug it back in, the monitor no longer receives a signal. I then have to switch off the laptop and reset the USB 3.1 port by pressing the power button for approx. 30 seconds
(I found this in a forum). What is the problem or is there a driver from Intel that solves this problem?
The driver on my laptop is from Microsoft (driver version: 10.0.22621.2506).
I'm sorry that I don't have a OP to quote however from memory I am nearly certain that this is a UEFI firmware bug and whether it's Intel or WHQL signed drivers eXtensible Host Controller despite saying it's a 3.0 controller I can assure you that this device is properly controlling the USB 3.1 gen2 monitor at Intel Spec 3.2.
That's necessary because to make the monitor connected to UEFI video there's a bios variable that gets set to the NVRAM and the UEFI of this first generation tech was never programmed with code to allow USB Controller to modify the NVRAM variables representing each video device in UEFI prior to this chipset could never reassign them automatically after reconnected it gets a new disiplay variable but the graphics are still pointing to the now detached and reattached removable display.
There's an extremely moderate to moderate-extreme difficulty actual real solution but most people are far too lazy and uncomfortable working with anything lower than Windows but because this is not a windows issue either we have to go to the BIOS NVRAM itself. When you are running Windows or another UEFI OS the UEFI shell is usually accessible via boot manager, various escape signals, but Windows is fully controlling the displays and GPUs by taking over control of those things with aforementioned drivers. In my personal opinion RS232 UART-to-USB or UART-to-JTAG serial port console or virtual emulated console UEFI drivers for WHY
TO CONTINUE TO ACCESS THE UEFI SHELL POST-SECONDARY BOOT WHILE WINDOWS IS STILL CONTROLLING THE MACHINE because you'll have to manually name every display adapter that you use USING UEFI SHELL CODE and requiring to be aware of device vendor's VERY SPECIFIC MEMORY ADDRESSES that are not going to be the same for a Lenovo as a ASUS though maybe identical Intel 945's as THESE VARIABLES ARE SOMETIMES blocked FROM END USED, sometimes found on some forum device builder message boards by the system manufacturer, sometimes an option right in the bios setup phase like click with your mouse exposed, most people actually have at the address space to look at what is in memory and figure it out it is possible to Turn-Key provision a way to switch video intelligently.
Basically the very next generation of bios for newer hardware took care of it naming every adapter fb0 fb1 fb2 etc. and so forth and the USB controller spec updates was a rushed release so you unplug the monitor and relocate and when you plug in the monitor again it's created fb3 except fb2 still exists! The conflict and yes the reboots but yeah-
Just so you know if you're a contractor and someone is demanding perfect pinbutton function with a machine based on this chipset it's doable like not impossible at all there's a couple ways you could go about it
WARNING if you know your way around a UEFI bios shell and do manage TO create MEMORY RESIDENT static device names for multiple displays you'd just need to set the bit to memory to manually initialize the specific graphics adapter and you want enabled and attache all the USB hot plug no problem it's assising displays identifiers like Linux assigns dev files sda sdb sdX ... except it's in the freaking BIOS and not about storage
So #2 in summary is the capability is there to statically assign displays TO AVOID COLD REBOOT AND the dummy way of enumerateting for the actual MUX devices BUT now that you will no longer be concerned with rebooting you should know after reprogramming NVRAM if you cold restart for any reason ALL video is permanently discoupled THINK BLACK SCREEN OF DEATH so IF YOU NEED TO BE HOT PLUGGING THIS MONITOR PEACE OF CAKE BUT ONCE YOU GO THAT WAY it's not easy to just reset your firmware and get video on boot THAT'S JUST IF YOU REBOOT WITH THE MONITOR NOT ATTACHED could even write a usermode driver and bake a gui into your Sysprep to toggle the ways displays enumerated by UEFI improvised modes or just basically the additional logic that's in the windows and the Intel Chipset but missing from UEFI bios probably stubs hiding partial implementations.
Of course #3 sweet 3 buy a newer computer mfg about literally just a year later or maybe some experimental community homebrew BIOS like flash the EEPROM and compile yourself something cobbled from TianoCore sunset.
Intel does not verify all solutions, including but not limited to any file transfers that may appear in this community. Accordingly, Intel disclaims all express and implied warranties, including without limitation, the implied warranties of merchantability, fitness for a particular purpose, and non-infringement, as well as any warranty arising from course of performance, course of dealing, or usage in trade.
Hello when "VirtualHere USB 3 eXtensible Host Controller" is installed in device tree, at reboot one of the hardware USB drivers fails (and my docking station will refuse to work).
The error displayed on the hardware USB Device is: Code 31: "Object Name already exists"
Everythings returns normal if I remove "VirtualHere USB 3 eXtensible Host Controller" from the Device Manager.
Lenovo Thinkpad P52, Windows 10 Professional 64 bit.
Hello I have updated the Thinkpad drivers multiple times at the link you supplied and yes now it is all updated.
I am having this trouble (main symptom: docking station not recognized at boot time) since months.
During these monts of trouble, I have:
* updated drivers, updated bios, updated docking station firmware, several times.
* updated vhui64 multiple times
So, now:
* when "VirtualHere USB 3 eXtensible Host Controller" is installed in device tree, at reboot one of the hardware USB drivers fails (and my docking station will refuse to work).
* The error displayed on the hardware USB Device is: Code 31: "Object Name already exists"
* Everythings returns normal if I remove "VirtualHere USB 3 eXtensible Host Controller" from the Device Manager.
I have fixed my problem so this fix is not so urgent for me, but I think there is some flaw in the VirtualHere device driver and I would like to help since it is a great and useful piece of technology.
In Device Manager under "Universal Serial Bus Controllers" right click on any "xxx Host Controller" device listed and select Properties Driver->Driver Details and tell me what files it has listed there. Also click on Details tab and see if this is any entries containing the word "Filter" e.g "UpperFilter" "LowerFilter" and let me know if you find that.
I debugged with v.marolda and it ended up being the Intel USB 3.1 controller wants to be called HCD1. Its a bug in their driver. I couldnt find any way to alert intel to a bug via email without joining some technical support program. So i hope they just fix it as it will conflict with other normal hardware host controllers.
On boot virtualhere searches for a spare host controller name. HCD0 is taken by the root host controller, so HCD1 is usually available and virtualhere driver calls itself that. However sometimes there is a race condition with another driver and so virtualhere will take the next number HCD2.
However the intel driver doesnt do this, it just fails if HCD1 is taken. Whereas really it should fall back to taking the next name e.g HCD2 or HCD3 but it doesnt and thats the "Object name already exists " error
I feel like this should be noted.
I have Dell Latitude laptop with Win 10 21H2 that has two internal HCs and a Thunderbolt 3 dock also with two HCs.
After VirtualHere installation I found that USBs on dock stopped working if dock being hotplugged after boot. After experimenting a little I found that if I set HCD=4 - one of dock controllers starts working; HCD=5 - everything works.
This looks like enumeration issue - maybe VirtualHere controller ID somehow not being counted as "used"?
Thanks for the detailed information. Yes the reason is when the computer boots virtualhere will choose an unused device name. E.g HCD1 or HCD2 etc However the Intel driver will default to just using HCD1, HCD2 etc, even if that name is in use. If the driver order changes then the conflict occurs. Ive asked Intel to modify their driver so that it also chooses a unused name when booting however they said no. They should also do it the same way as virtualhere to avoid conflicts..
>Thats great news, thanks for letting me know. (Im having trouble finding the release notes for this version... to confirm)
sorry - it still isn't working, I wasn't restarted - then it steps out.
by the way - this registry entry also doesn't help - may it can be added to the settings etc?
The Advanced Host Controller Interface (AHCI) is a technical standard defined by Intel that specifies the register-level interface of Serial ATA (SATA) host controllers in a non-implementation-specific manner in its motherboard chipsets.[1]
The specification describes a system memory structure for computer hardware vendors to exchange data between host system memory and attached storage devices. AHCI gives software developers and hardware designers a standard method for detecting, configuring, and programming SATA/AHCI adapters. AHCI is separate from the SATA 3 Gbit/s standard, although it exposes SATA's advanced capabilities (such as hot swapping and native command queuing) such that host systems can utilize them. For modern solid state drives, the interface has been superseded by NVMe.[2]
Many SATA controllers offer selectable modes of operation: legacy Parallel ATA emulation (more commonly called IDE Mode), standard AHCI mode (also known as Native Mode), or vendor-specific RAID (which generally enables AHCI in order to take advantage of its capabilities). Intel recommends choosing RAID mode on their motherboards (which also enables AHCI) rather than AHCI/SATA mode for maximum flexibility.[3] Legacy mode is a software backward-compatibility mechanism intended to allow the SATA controller to run in legacy operating systems which are not SATA-aware or where a driver does not exist to make the operating system SATA-aware.
64591212e2