<QUOTE> Could latent devices installed from other motherboards really do this if not active? It truly could be any number of problems that the fresh install solved besides "driver hell" but just wondered if anyone else had this experience. </QUOTE>
The key phrase is "if not active." If the driver is truly not active, the answer is no... it cannot affect the running system. Typical PnP-enabled drivers are only loaded when a device for which they claim support is discovered. If there's no hardware involved, there are no interrupts. And if there are no interrupts (and no timers) then there can be no DPCs. But, even with no DPCs, a driver could STILL contribute to DPC latency. However, having lots of "unused" drivers hanging around in an installation CAN complicate matters and affect overall system performance. Most drivers provide a long list of devices they support and many end their list with a claim that they support a wide variety of generic hardware for compatibility reasons. So the driver starts out listing their support for a SPECIFIC vendor id and device id, a specific vendor system and subsystem, and a specific revision, and ends the list by saying "oh, and in a pinch, I'll support any type of xyz device." When multiple drivers claim that they can support the same device, Windows determine which driver to select for a device using a complicated algorithm that is defined by business policy, not best technical match of driver to device. Many vendor-specific drivers are implemented as "filter drivers" which modify the function of a basic Microsoft-supplied driver. Such drivers might load over an entire class of device -- ready to support a vendor-specific model of that device should one be plugged-in (good examples here range from keyboards and mice to DVD drives). There are also drivers that are implemented as hybrids: Sort of PnP, sort of filter, and installed and activated by default. Finally, there are often drivers for lots of "system" resources that really, really want to be matched properly to the motherboard in use. These include drivers for BIOS-related devices (Do you have a "volume up" button on your keyboard? Ever wonder how it manages to (a) change the volume on your audio device, and (b) display a volume slider on your monitor? It's partly done in the BIOS -- that's a trivial example, but an easy one to understand). And there's a ton of BIOS-related stuff that can't be disabled without secret monkey magic known only to the mainboard vendor (for example, one mainboard I'm familiar with disables certain extensive BIOS extensions when there's no RAM placed in a specific slot on the mainboard). And we haven't even BEGUN to discuss weird things like dynamic BIOS patches (with stuff loaded via the registry), or other drivers that fall into the category of "there's a bug but we can fix it in the driver." Getting the right set of drivers on your system for the best (or even correct) performance can be a major task. That why I don't even TRY to build my own system. I just order a machine from Dell or HP. OEMs control their BIOS and tend to do a reasonable job of systems integration. While any system you buy directly from an OEM will be plagued with lots of EXTRA goo, removing stuff is waaaay easier than trying to find all the right stuff in the first place. For computers designed to run PowerSDR, Neal provides this system integration service which is custom tailored to our needs and environment. It's all pretty complex stuff... and the more powerful the support chipsets (like the ICH) become the more tightly intertwined with the BIOS things become and the more critical and complicated system integration gets. Fun! Peter K1PGV _______________________________________________ FlexRadio Systems Mailing List [email protected] http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz Archives: http://www.mail-archive.com/flexradio%40flex-radio.biz/ Knowledge Base: http://kc.flex-radio.com/ Homepage: http://www.flex-radio.com/
