You are not logged in. Please login or register.
DriverPacks.net Forum » Posts by Jaak
yes, I will do a new EXPERIMENTAL with CC_010x tagged HW ids.
I look at the screens while the machine powers up, and hit pause.
(you most likely have to change a BIOS setting so that the screens show.)
I believe there is a tool to read BIOS version, but do not remember the topic.
zit er ook in, ergens in Mei.
OOPS.
I tried it on a machine with some silicon image chip, and 7096 halted during setup.
testfile 7096 and the experimental (which was based on 7096) will be pulled.
testfile 7094 is back online
here was a bad experimental pack for silicon image.
it got reworked, and link is in a later post.
-----------------------------------------------------------
the TXTmode sections for silicon Image, (ONLY in the in the INI) have HWIDs tagged with &CC_0101 or &CC_0104
If this works, it means we do not have to edit the driver's INF files to tag the &CC_010x to the HWIDs.
If it doesn't, it doesn't.
I am not going to volunteer to change all those INF files each time there is an update.
BUT, if this does work, it could mean that we have a solution for the overlap in those PATA/SATA and RAID drivers.
@ stiertje,
The driver for bios 4.x.83 has been made to NOT load HWIDs which are supported in an older driver, because there is reason to believe the driver intended for an older BIOS works on a newer BIOS.
The driver for a newer BIOS was reported to NOT work on an older BIOS.
GROANS.... setup error on my second testrig (which has silicon chip inside).
Virtual PC and a socket 478 with extreme CPU machine showed nothing extrordinary, but silicon failed just the same.
back to the drawing board.
Hi,
strange, but possible.
I vaguely remember old discussions about upper/lower case issues.
This should not be an issue, but I do believe you none the less.
Hi Sereby.
the testpack got updated (link above is updated)
Yesterday JakeLD and I had a chat session about the Broadcom driver, and I sent him a broadcom zip.
I also posted a long text with notes on nVidia LAN drivers in testing forum.
I'll look at this latest testpack, and compare with my notes.
I know it has been included in the RVM update pack.
I don't know if one can think of it as a driver update.
(I don't think so, but do not know. I have not downloaded the hotfix because my CPU are not core 2 dual.)
Hi Muiz,
you are probably also aware there is a hotfix for a particular range of intel CPU floating around.
check mass storage forum, there is a new test file in the public.
lsi_sas was adressed.
well, log ends just before other logs we see mention the creation of temp folder?
I cannot reproduce it on my system, and wondered about free space.
(I might run it in a USB stick with insufficient room to try reproduce it)
7095 test version is available.
hi,
welcome to DriverPacks.
the others will love to hear I've been looking for duplicate names all afternoon, and tryng to fix each duplicate so it can work for disc installs as well as sysprep.
Having unique tagnames was good enought for disc installs, but now that a few "sysprepper" guys joined the team we are working toward a best of both worlds solution.
I'll have a couple more hours work on this, after wich I will run a disc install trial.
If that works, I'll let you guys test it.
Well, far as I know, the driver is for server 2000, and for server 2003.
At the moment, the driver is set to be skipped for XP.
ms_1_exc_skipIfOS="wxp"
; ms_1_exc_replaceIfOS="w2k3" (the line is inactive, it is a comment, and can be deleted.)
I looked at windows 2000 source CD to see what it natively supports, and it does not need to be set to "replace".
I have to still look at non-DriverPacks-slipped server edition, but will do that shortly.
if you want to test this without skip line...
[D-2]
ms_count=1
ms_1_deviceName="Dell SAS 5x (Windows Server 2003 32-bit)"
ms_1_tag="lsi_sas"
ms_1_sysFile="lsi_sas.sys"
ms_1_hwids="PCI\ bla bla hwids F091028"
ms_1_isBusExtender=false
(use 7zip to unpack, delete both skip and replace line in the INI section, and then use 7zip to 7zip the INI file plus D folder. It will want to use same name for the archive, so you should give the last number a higher number.).
Then copy the new mass storage archive to DriverPacks folder and test it.
I'll update the online tute on pandora, and mention this in there.
hi,
at the moment, the Bart-PE addon creation module will ONLY process Mass Storage DriverPacks, and txtmode.
hi,
are you using mass storage DriverPacks version 7.09.1 ?
edit> sorry, I just read you used yesterday's DriverPacks, so you are.
I will have to make me a windows 2000 install disc, and try find the cause.
It's not too much work, and I must make this disc anyway, because I want to build a database with the natively supported files in it. 
hi,
how much free room is there on D: drive?
JakeLD?
there is a REQuest about the GX470, which is found in 3rd party packs.
did this get into sound B?
Hi
well, the intel INF won't do duplicate HWIDs (they are edited out), and the files have unique names.
Somebody once suggested to also make the service names in the INF unique for each driver.
(in the latest Mass storage testpack, Silicon Image drivers were edited similarly. The files got UNIQUE names, the HWIDs have no overlap in the INFs, and the latest driver will only support the few HWIDs it has exclusive to itself.
There is reason to believe the OLDer driver (for older silicon BIOS) will run in silicon's newer BIOS, but we know for sure that the newest driver will NOT run in an older silicon BIOS.
Since they used same names, (and had massive overlap) I have built this "somewhat experimental" testpack on silicon image.
If it works, we all gain.
The approach should cause less pain for sysprep users.
We need you guys.
I test disc installs, and sysprep users have to do their 'thing".
I don't understand why they want to drop support for older HWIDs when they publish a new version.
You know, if I had all the intel hardware to test on, I"d be making an experimental pack where the newer gets the "dropped" HWIDS injected right back into the driver.
As is, I cannot and I think I cannot ask members they try an experimental like this.
Oh, that whatsitcalled "Hi Def Media Interface or something"? I believe we have had DriverPacks versions where they were not included.
Hi
DEV_24C6&SUBSYS_3084103C and DEV_24C6&SUBSYS_3080103C are unique for your conexant, and there were no generic left for DEV_24C6.
If this is still true with modempack 7.09.22, then the misdetection is probably unfixable.
hi Erik
there was an update request for i865G driver, and I worked on this one as well.
After duplicate filtering and version checks, I found I had to add a folder 7 for the 865G 
edit, put them in DATE/version order.
(these are notes I use to keep track of supported HWIDs, since I want to help sysprep users avoid crashes )
folder 1, has 08/24/2007,6.14.10.4864
%iLPGD0% = i945G0, PCI\VEN_8086&DEV_2772
%iLPGD1% = i945G1, PCI\VEN_8086&DEV_2776
%iCLGD0% = i945GM0, PCI\VEN_8086&DEV_27A2
%iCLGD1% = i945GM1, PCI\VEN_8086&DEV_27A6
%iCLGE0% = i945GM0, PCI\VEN_8086&DEV_27AE
%iBWGX0% = iBWG0, PCI\VEN_8086&DEV_2982
%iBWGX1% = iBWG1, PCI\VEN_8086&DEV_2983
%iBWGQ0% = iBWG0, PCI\VEN_8086&DEV_2992
%iBWGQ1% = iBWG1, PCI\VEN_8086&DEV_2993
%iBWGC0% = iBWG0, PCI\VEN_8086&DEV_29A2
%iBWGC1% = iBWG1, PCI\VEN_8086&DEV_29A3
%iBWGZ0% = iBWG0, PCI\VEN_8086&DEV_2972
%iBWGZ1% = iBWG1, PCI\VEN_8086&DEV_2973
%iCRGD0% = iCRG0, PCI\VEN_8086&DEV_2A02
%iCRGD1% = iCRG1, PCI\VEN_8086&DEV_2A03
%iCRGE0% = iCRG0, PCI\VEN_8086&DEV_2A12
%iCRGE1% = iCRG1, PCI\VEN_8086&DEV_2A13
%iBLBG0% = iBLB0, PCI\VEN_8086&DEV_29C2
%iBLBG1% = iBLB1, PCI\VEN_8086&DEV_29C3
%iBLBQ0% = iBLB0, PCI\VEN_8086&DEV_29B2
%iBLBQ1% = iBLB1, PCI\VEN_8086&DEV_29B3
%iBLBQC0% = iBLB0, PCI\VEN_8086&DEV_29D2
%iBLBQC1% = iBLB1, PCI\VEN_8086&DEV_29D3
folder 3 has 01/13/2007,6.14.10.4764
%iGDGD0% = i915G0, PCI\VEN_8086&DEV_2582
%iGDGD1% = i915G1, PCI\VEN_8086&DEV_2782
%iALVD0% = i915GM0, PCI\VEN_8086&DEV_2592
%iALVD1% = i915GM1, PCI\VEN_8086&DEV_2792
folder two has 02/07/2006,6.14.10.4497
%iMGM% = i852GM, PCI\VEN_8086&DEV_3582
folder 7 has 09/20/2005,6.14.10.4396
%iSDG% = i865G, PCI\VEN_8086&DEV_2572
folder 4 has 06/21/2005,6.14.10.4342
%iBKDG% = i845G, PCI\VEN_8086&DEV_2562
folder 5 has 08/20/2004,6.14.10.3889
%i830M% = i830M, PCI\VEN_8086&DEV_3577
folder 6 has 07/23/2002,6.13.01.3196
Intel(R) 82810 Graphics Controller = i81x, PCI\VEN_8086&DEV_7121
Intel(R) 82810-DC100 Graphics Controller = i81x, PCI\VEN_8086&DEV_7123
Intel(R) 82810E Graphics Controller = i81x, PCI\VEN_8086&DEV_7125
Intel(R) 82815 Graphics Controller = i81x, PCI\VEN_8086&DEV_1132
ad\6 updated to 01/22/2007,7.00.00.06
That's fine, I believed my post http://forum.driverpacks.net/viewtopic.php?id=1944 already forgotten by the experts;-)
ad\6\c deleted (HWID edited into ad\6)
I'm not sure if this is the best solution since it invalidates the driver's signature. I would write a second *.inf-file (which is copy of the existing one except the HWIDs and strings) so that only the signature of the Compaq brand of this controller is invalid what happens anyway since the *.sys is newer then the Compaq *.cat.
And as a last point I would ask to cleanup ad\6 a little bit:
- txtsetup.oem not needed in driverpacks (it's function is ported to DriverPack_MassStorage_wnt5_x86-32.ini)
- the disklabel U320DSK1 is not needed
- MAXIO64K is not referenced in *.inf nor txtsetup.oem so its also not needed (for any unattended setup)Thanks
ad\6 post was not forgotten. (it triggered the update)
But, you made me reread it, and I saw the two missing HWIDs were still missing.
I liked your suggestion about making an edited "copy" for that single compaq HWID.
(the other HWIDs this old driver had are still covered by the newest adaptec.)
I called it COMPQ320.INF.
-------------
Stiertje, can you post the HWIDS of that silicon chip you have?
And... what BIOS does it have?
DriverPacks.net Forum » Posts by Jaak
Powered by PunBB, supported by Informer Technologies, Inc.
Currently installed 3 official extensions. Copyright © 2003–2009 PunBB.
[ Generated in 0.096 seconds, 5 queries executed ]