Sponsored Links
No, but you get my point. Or you should do by now.
It's almost certainly a corrupted registry, nothing more. USB is designed to 'just work', and so it usually does.
Open up the device manager, go to the view menu and have it show hidden devices, and remove (that is, 'uninstall') any entries for mice or HID devices which you do not have connected. If you can't tell, don't worry, if it turns out to be the mouse you're using you just unplug it and plug it back in.
If that doesn't work it'll require some more drastic cleaning, and I honestly can't remember how (I haven't seen this happen in a long time).
Monkeh
Ok it could well be a corrupted registry entry, Id only expect this when there been some device enumeration that means that windows sees a device classifies it and then stores this information (you are right, within the registry).
No matter what you unplug or uninstall (short of the bus or device driver which would hopefully remove this UUID classification of the device) then ti will always attempt to use the same upon re-insertion.
My point is that this mistaken enumeration is normally due to the bus driver passing on invalid information to "Windows" because the Windows driver does not contain the proprietary add on bit of code that entails it to discover the device properly.
Thus, and I have also seen this, even a full reinstall of windows and therefore a destructive registry, doesn't help.
Ideally you'd research and assure that you have the valid usb bus driver an then also, do as you mention, and remove the "cached" registry entries and let the PnP rediscover the (hopefully now) valid UUID's
Ok it could well be a corrupted registry entry, Id only expect this when there been some device enumeration that means that windows sees a device classifies it and then stores this information (you are right, within the registry).
No matter what you unplug or uninstall (short of the bus or device driver which would hopefully remove this UUID classification of the device) then ti will always attempt to use the same upon re-insertion.
My point is that this mistaken enumeration is normally due to the bus driver passing on invalid information to "Windows" because the Windows driver does not contain the proprietary add on bit of code that entails it to discover the device properly.
Thus, and I have also seen this, even a full reinstall of windows and therefore a destructive registry, doesn't help.
Ideally you'd research and assure that you have the valid usb bus driver an then also, do as you mention, and remove the "cached" registry entries and let the PnP rediscover the (hopefully now) valid UUID's
The odds of the controller not being a bog standard chipset-integrated UHCI or OHCI example are so insane that I really don't see your theory (which, as I said, is precisely why we have OHCI and EHCI, to allow USB to live up to its name) being realistic.
And please, if you work or have worked for a company producing such a device, name and shame. They deserve it.
And please, if you work or have worked for a company producing such a device, name and shame. They deserve it.
Sponsored Links
And such companies do exist, no I don't work for one, however I have coded such "mappings" between "proprietary" and "standards".
And its more prevalent then you'd think.
And I didn't say they were not buffoons , just that I am not naming them in a public forum when my livelihood depends on coding.
Just to highlight, to take my example of *EAP, there is obviously the standards but then there are proprietary methods of this Extensible Protocol. Are these manufacturers buffoons?
And its more prevalent then you'd think.
And I didn't say they were not buffoons , just that I am not naming them in a public forum when my livelihood depends on coding.
Just to highlight, to take my example of *EAP, there is obviously the standards but then there are proprietary methods of this Extensible Protocol. Are these manufacturers buffoons?
This is the mobo manual
http://uk.ts.fujitsu.com/rl/service.../Motherboards/asus/P5GD1-FM/asus-P5GD1-FM.pdf
So north bridge and south bridge
Northbridge: Intel® 915P Memory and Controller Hub (MCH) Southbridge: Intel® 82801FB ICH6
Im assuming looking at that then they follow one of the standards?
http://uk.ts.fujitsu.com/rl/service.../Motherboards/asus/P5GD1-FM/asus-P5GD1-FM.pdf
So north bridge and south bridge
Northbridge: Intel® 915P Memory and Controller Hub (MCH) Southbridge: Intel® 82801FB ICH6
Im assuming looking at that then they follow one of the standards?
EAP is not comparable to OHCI. OHCI is a fixed standard. Any additional functionality over OHCI, UHCI, or EHCI should in no way affect normal USB operation.
I still don't think the route of a destructive reinstall that Holmslaw was going down is the right option though, either fix the driver if need be (which it would appear not in this case although I might still run one of my debug codings across the driver to see if it really is a true EHCI in this fujitsu siemens case.
Or. remove the "cached" registry entries as to what Windows thinks that device UUID actually is.
Not sure if this information could be incorrect other than via miscommunication, whats your thoughts ?
Or. remove the "cached" registry entries as to what Windows thinks that device UUID actually is.
Not sure if this information could be incorrect other than via miscommunication, whats your thoughts ?
Actually a AHCI iirc
Uh, no. AHCI is for SATA controllers, and the ICH6 does not support it anyway. The ICH6R and ICH6M do, however.
I agree, a reinstall is not the first choice here. EHCI is, btw, not used unless he has a remarkably fancy mouse.
Cleaning the devices out of the registry is the first thing to try.
Actually a AHCI iirc
Uh, no. AHCI is for SATA controllers, and the ICH6 does not support it anyway. The ICH6R and ICH6M do, however.
Yes I recovered the Intel data sheet PDf on that chipset , hence my later post.
EAP is a framework. EAP-TLS is a standardised method.
You can use EAP with any method you like, standardised or otherwise. Call it EAP-TLS when it's not, and you're lying. Advertise a USB host controller as OHCI and then not be compatible with OHCI, and you're lying. Say you 'support EAP' and use a proprietary, non-standardised method, and you're merely a dodgy git, but the purchaser is at as much fault as the manufacturer for not checking into the method.
Sponsored Links