[REQ] NVIDIA Quadro NVS 210S + 430 chipset

If I'm understanding debuggers post... it did add some nVidia 520 chipset items... but not the ones specific for this chipset. I could easily be incorrect since I'm not very good with drivers.

I still rebuilt my UBCD4Win using the DP_Chipset_wnt5_x86-32_7056 and the BSOD I was seeing with the previously tested chipset drivers still exist with this one. This BSOD only happens on this chipset combination on the boards I've tested this on... on a system with the 6100 / 430 chipset combination it works fine without incident.

Certainly, It will be later this evening after I get home to the system I have with that hardware... 8+ hrs. Thx.

Last edited by rdsok (2007-05-10 02:41:12)

rdsok, I haven't this driverpack and I don't know where is it, just I remember my experience. I don't try new DP_Chipset_wnt5_x86-32_7056 witn your mobo because I haven't it now.

I think it important to know what inf file in C\N folder causes BSOD. In DP_Chipset_wnt5_x86-32_704 was updated nForce drivers, I afraid it is cases your BSOD. Post here bsod code and name, and if you can setupapi.log file please.

Last edited by Debugger (2007-05-10 06:06:04)

Debugger,

Ok.. here are some testing results for this issue.

Overflow was able to provide the older DP_Chipset_wnt5_x86-32_612 and this also produces a BSOD... so all of the following tests were done with the latest nightly I had which was the DP_Chipset_wnt5_x86-32_7056.

The BSOD error code...

A typical IRQ_NOT_LESS_OR_EQUAL error that is common with driver issues.

STOP 0x0000000A ( 0xFFFFFFD4, 0x00000002, 0x00000001, 0x8043026D )

I've also got several SETUPAPI.LOG files so you can choose which or all of them that may be of use in this issue... http://www.rdsok.net/chipset/setupapi.7z

I've isolated the chipset folder that causes the issue to show up but I didn't isolate which file may be the cause in that folder. The folder that causes the BSOD to happen is the AU folder. The 7z file contains 3 different log files.

setupapi_AU_only.log  - This one causes the BSOD but only had the AU folder included in build.

setupapi_no_AU.log  - This contains all folders EXCEPT the AU folder and doesn't BSOD.

setupapi_all.log - This contains all folders ( including AU ) and causes a BSOD.

Since I'm not sure how familiar you are with a PE build like I'm doing using UBCD4Win verses a full XP build... let me point out some differences. A PE boot doesn't perform a complete PnP initialization... it only does the basic devices. What I am doing after the boot process is then to force a complete HWPnP detection... this is when I see the BSOD. Because of these differences, it is easy to see why the DP you tested with worked ok for you... yet still produced a BSOD for me... the OS does act and react slightly different than a normal XP build.

Overflow and I were speculating about the cause of the BSOD when I first mentioned it to him. I believe what he said may have a good reason for a cause... that the dev ID's aren't matched exactly so a generic match is made instead causing it. Of course this speculation has yet to be proven... but my test results do appear to help support it.

I had planned to test the AU folder futher, it just got too late for me to do it last night.

I believe the reason that those two LOG files are the same is from what I described about the basic PNP detection that a PE build does. It isn't a full hwpnp scan.. it only does select devices at first. While I didn't compare the LOG files because it was getting late, that is why I included each one that I did, I suspected the two you mentioned would be the same.

TIP... the fastest way to isolate the trouble is not to test one at a time but to divide them into groups. For instance, the AU folder currently has 10 INF files total... test the first 5, then the second 5 and depending on which group BSOD's, then split that group up... say test 2 then 3... until you finally work down to the one INF that causes it.

PS... OverFlow said he was unable to find the hwid's that I posted here... so the request for the drivers to support this board should still stand even though I've isolated the file that causes issues... I agree with him that if the proper hwid isn't matched, that the issue is likely caused by a generic driver getting loaded... at least that makes sense to me.

I looked in the folder and it was among the drivers listed. Should this file NOT be copied, after all it is included in with the files?

You are incorrect that the file isn't listed in an INF but this is probably because I'm working with an alpha build that Overflow is working on to allow integration of the driverpacks into BartPE builds. A BartPE build requires additional INF's that tell it what files are needed to be copied to the build. A BartPE build also requires that the drivers that are added are already in place because these are running from read only ( CD ) media.

Again, this isn't about that file really, even though it is causing an issue and may need to be addressed. The only thing that the BSOD has done was point out that this boards drivers were not supported. I even believe that the issue can probably be avoided if the proper drivers are added in the first place so the generic ones do not get used. The current DP's do not directly support the hwid's that this board has. I can probably create my own third party DP, but that would do nothing to help the community which is what I thought the point of reporting missing drivers was for.

I'm not sure that will matter Jaak, as I stated, the hwid's my hardware has are different that what even the current nightly has...

But thanks for the offer,

Randy

Last edited by rdsok (2007-05-12 13:54:47)

that will help except he has no video then...

mass needs added minimum and lan will remain as a problem till i get a little farther on the support of that

DP BartPE Tutorial   DP_BASE Tutorial   HWID's Tool     Read BEFORE you post    UserBars!

The DriverPacks, the DP_Base program, and Support Forum are FREE!.

@ALL DRIVERPACKS.NET TEAM MEMBERS

Please keep in mind that rdsok is testing BARTPE support, not a normall install.

This changes everything.

I believe that HIDCLASS.SYS is copied by the coinstaller so it wont be in an inf file.
Pebuilder support is still at alpha stage for this pack and is expected to be buggy at best.

For those that don't know, for a standard bartpe to work, all added drivers are expanded to their respective folders at build time, not boot time, this is why pebuilder support is taking so long to complete. Nore info will follow as time allows.

As I stated... I'm now in the middle of beta testing for the next release of UBCD4Win which is critical to get released soon. The UBCD4Win testing must come first even though the drivers are also important also.

I did do some preliminary tests with just the latest chipset drivers ( DP_Chipset_wnt5_x86-32_7051.7z )... but as long as the HIDCLASS.SYS that is included in the AU folder gets parsed into the INF file there will be certain systems that have trouble. This isn't the one that is normally used with XP so certain USB devices will fail as I've reported already.

I'll discuss this with Overflow when I get more time to devote to the drivers. At that time, I"ll also see if the video and other drivers that were not previously supported are working now or not. From the changelog that was posted, it doesn't appear that they were added.