[Invalid] Bug: Misdetection of Intel SCU F6 Drivers

[RootWyrm]

This one's got me scratching my head. The only explanation I can come up with is that WTK is not properly integrating the F6 driver due to incorrect detection. Either way, the incorrect detection is a fairly serious problem in and of itself.

 

You'll want to grab Intel SCU F6 drivers, version 3.8.0.1108 (latest as of this writing.)

 

In WTK the drivers detect as follows:

iaAHCI.INF	SCSIADAPTER	x64	7, 8	        9/3/2013	3.8.0.1108iaAHCIB.inf	SCSIADAPTER	x64	7, 8	        9/3/2013	3.8.0.1108iaStorS.inf	SCSIADAPTER	x64	Win 8	        9/3/2013	3.8.0.1108 <-- Whoops!iaStorA.inf	SCSIADAPTER	x64	7, 8	        9/3/2013	3.8.0.1108iaStorB.inf	SCSIADAPTER	x64	7, 8	        9/3/2013	3.8.0.1108

Well, one, iaStorS.inf is definitely the Windows 7 version. Manual load confirms it. Secondly, the set doesn't seem to be working as a whole. It should be noted, these are the REPLACEMENT set for RSTe and exclusively for the C600 chipset. And yes, you actually need ALL of them. In roughly that order. (I'm not clear on whether iaAHCI can go after iaAHCIB+iaStorS. But iaStorS has to go first if you want to boot off SAS, even though Windows says it can't. It can.)

 

Instead, when I boot from an image using that load, I get zero disks until I manually load the F6 drivers off another USB drive. Which of course, completely breaks my autounattend.xml - and yes, the load order of the drivers is EXTREMELY critical with this board. Otherwise, you WILL end up with the SATA before the SAS - reverse disk order - which breaks booting.

 

It's very hard to overstate the extreme severity of this problem for C600-series boards. No load, you're dead in the water.

 

EDIT: Because I obviously derped and forgot to mention - I did check the boot.wim file with DISM - none of these are getting loaded in there. Manually adding them to the WIM with DISM of course, fixes it. (Ignoring other major faults with the broken BIOS.)

Edited November 6, 2013 by RootWyrm

[RicaNeaga]

It may be a inf error (intel's fault). For starters, try the latest versions for your mass storage drivere. Look here.

[RootWyrm]

No, it is not an INF error. I checked the INFs. The INF in fact, does not specify any drivers for Windows 8.

 

Relevant bits:

[Version]  Signature = "$Windows NT$"  Class=SCSIAdapter  ClassGUID={4D36E97B-E325-11CE-BFC1-08002BE10318}  Provider=%INTEL%  CatalogFile=iaStorS.cat  DriverVer=09/03/2013,3.8.0.1108;  [PackageInfo]  Name=SCU

[SourceDisksFiles.amd64]  iaStorS.sys = 1,,,  iaStorF.sys = 1,,,  ;  [INTEL.NTamd64.6.2]     ;windows_8_64-bit    ;      [INTEL.NTamd64.5.2]     ;server_2003_enterprise_x64   %Intel_SAS_RAID.Desc% = Intel_SCU_iaStorS_Inst,PCI\VEN_8086&DEV_1D60  %Intel_SATA_RAID.Desc% = Intel_SCU_iaStorS_Inst,PCI\VEN_8086&DEV_1D61  %Intel_SAS_RAID.Desc% = Intel_SCU_iaStorS_Inst,PCI\VEN_8086&DEV_1D62  %Intel_SAS_RAID.Desc% = Intel_SCU_iaStorS_Inst,PCI\VEN_8086&DEV_1D63  %Intel_SAS_RAID.Desc% = Intel_SCU_iaStorS_Inst,PCI\VEN_8086&DEV_1D64  %Intel_SAS_RAID.Desc% = Intel_SCU_iaStorS_Inst,PCI\VEN_8086&DEV_1D65  %Intel_SAS_RAID.Desc% = Intel_SCU_iaStorS_Inst,PCI\VEN_8086&DEV_1D66  %Intel_SAS_RAID.Desc% = Intel_SCU_iaStorS_Inst,PCI\VEN_8086&DEV_1D67  %Intel_SAS_RAID.Desc% = Intel_SCU_iaStorS_Inst,PCI\VEN_8086&DEV_1D68  %Intel_SAS_RAID.Desc% = Intel_SCU_iaStorS_Inst,PCI\VEN_8086&DEV_1D69  %Intel_SATA_RAID.Desc% = Intel_SCU_iaStorS_Inst,PCI\VEN_8086&DEV_1D6A  %Intel_SATA_RAID.Desc% = Intel_SCU_iaStorS_Inst,PCI\VEN_8086&DEV_1D6B

So, as I said, it's a detection bug in that it's keying off the INTEL.NTamd64.6.2 and ignoring the INTEL.NTamd64.5.2.

[RicaNeaga]

Maybe Win Toolkit detects the server word when 5.2 is present, don't know. Looked into myself and you were right.

 

However the solution is simple - just edit the .inf and replace 5.2 with 6.1 everywhere. You can do it for any version you want or you can download the latest modded by me version from here.

 

Verified afterwards in Win Toolkit and everything is now ok - it's a ''windows 7,8'' driver everywhere

[RicaNeaga]

btw, what motherboard do you have?

 

Normally, in the (latest version of) BIOS, there's an option to switch between the enterprise and the normal version of ''Rapid Storage'' (mass storage) driver. So normally you can use the regular one, even with the SAS port, if I remember correctly

[RootWyrm]

btw, what motherboard do you have?

 

Normally, in the (latest version of) BIOS, there's an option to switch between the enterprise and the normal version of ''Rapid Storage'' (mass storage) driver. So normally you can use the regular one, even with the SAS port, if I remember correctly

 

This is false.

 

You are confusing IRST (Intel Rapid Storage / Rapid Response crap) with the SCU driver. These are not the same. They are not related. RSTe has nothing to do with SCU. If you attempt to equate SCU with RSTe, you're just plain wrong, even though the C606's SCU identify as RSTe. It is fundamentally and completely incompatible. IRST absolutely does not work with the SCU; enabling IRST either disables the ports completely (-D config) or forces to AHCI SAS (some -T configs) with no boot capability.

 

This bug will immediately impact any and all C600 boards, worst being C606's (e.g. Gigabyte GA-X79S-UP5-WIFI and Supermicro X9SRi-3F.) The C606 can operate in two modes off a single SKU, too - D and T modes. D enables the SCU as a SAS controller, T enables the SCU as a SATA controller, both in a 2x4 arrangement. (2 SCU bundles of 4 ports using a common PCIe BAR.) In a T+SCU-SATA RAID config, you must use F6 SCU and all drivers must load in the correct order. If you load iaStorS after iaStorF, it can't establish communication with the SCU.

 

More to the point, it is in fact, a bug that will need addressed as more Windows 8 drivers are released. The simple fact is that it's indicative of probable misinterpretation of the INF. And that's the 'best practices' way to deal with a driver which is common between 7/8, according to what I've been told. So basically, more drivers are going to have that sort of INF layout.

 

Thankfully, the fix is relatively simple. Half-baked pseudocode example:

if "[INTEL.NTamd64.6.2]" ->    // Check for specific driver assignment.    check_string [*sys, *cat]    if check_string = 1 {    // Not found, but found Windows 8 support.    if "[INTEL.NTamd64.5.2]"        check_string [*sys, *cat]        if check_string = 1 { // Not found, so no Windows support            bailout;    // Can't use it.        } else {            support_add (Windows_8, Windows_7)        }    fi    fifi

[RicaNeaga]

Maybe I'm confusing smth, I don't exclude it, but I really remember that both versions of the mass storage Intel driver (enterprise and normal) are usable for a X79 motherboard, all you had to do is choose an option in the BIOS.

 

For example, both versions of iaAHCIC.inf (found in the latest ''normal'' 12.8.6.1000 version and also the latest ''enterprise'' 3.8.1.1009 version) include this line:

 

 

PCI\VEN_8086&DEV_1D02&CC_0106

that's responsible for the X79 C600 mass storage device.

 

 

I offered you a simple solution to modify the .infs so they are integratable with Win Toolkit; if you have another, that's great. But don't expect Legolash to update his app soon, and do this by default (detect those drivers as also windows 7 compatible without other changes), as he's gone for a very long time now.

[RootWyrm]

Maybe I'm confusing smth, I don't exclude it, but I really remember that both versions of the mass storage Intel driver (enterprise and normal) are usable for a X79 motherboard, all you had to do is choose an option in the BIOS.

 

For example, both versions of iaAHCIC.inf (found in the latest ''normal'' 12.8.6.1000 version and also the latest ''enterprise'' 3.8.1.1009 version) include this line:

 

 

PCI\VEN_8086&DEV_1D02&CC_0106

that's responsible for the X79 C600 mass storage device.

 

 

I offered you a simple solution to modify the .infs so they are integratable with Win Toolkit; if you have another, that's great. But don't expect Legolash to update his app soon, and do this by default (detect those drivers as also windows 7 compatible without other changes), as he's gone for a very long time now.

 

This is incorrect. While X79 / C600 is Patsburg, there are not two drivers - there are four.

 

X79 is IRST, RSTe. C600 is SCU+RSTe or SCU, depending on PCH Strap 16. (C606 can also operate as RSTe if the SCU ports are configured as SATA and not SAS.) This all comes from the fact that the X79 and C600 are not the same chipset. Remember that the X79 was supposed to ship with quad SAS/SATA-III ports in addition to the base six, but that got nixed due to silicon defects. It's still nixed, in fact.

 

So on an X79 your controller layout is this: X79 PCH -> SATA (IDE, AHCI, IRST, RSTe)

On a C606 your controller layout is THIS: C606 PCH -> SATA A, PCH Config -> SCU A+B (two units, 4 ports each, common BAR) -> SCU Mode

So your information is absolutely incorrect: a properly configured C606 has (all VEN_ID 8086) any one of 1D00-1D06, two instances 1D40 or 1D41, one or two instances 1D54 or 1D55 or 1D58, two to four 1D22, etc. You get the idea. It is not and never has been a single device on C600 and C600 is not equivalent or equal to X79.

 

It'd probably take me an hour to draw out all the permutations of C606 configuration. Suffice to say, the SCU setup complicates things substantially and there's not a lot of folks out there who have access to or can test multiple C600 boards. Plus because the SCUs are configured by PCH Soft Strap, the C606 has a single SKU for over a dozen operational modes including SATA passthrough, limited RSTe and ROMB keyed RAID. And depending how smart or stupid your motherboard manufacturer is, it may or may not be sensitive to load order. For maximum "WTF" factor you can put two Supermicro C606 boards side-by-side and observe as one uses RSTe 12.x (SATA Passthrough) while the other uses SCU 3.7+. Even more WTF: combine Shrike Gen6 (SCU 3.8 UEFI) with the same physical board (RSTe 12.x UEFI + SCU 3.7 Legacy) - just from BIOS.

 

I do appreciate the fix and did put it into play, but my greater concern is that as time goes on, we're going to see more drivers and INFs taking this route, hence why it's flagged up as a bug. This is unlikely to be the last occurrence, and the SCU INF is relatively straightforward. Other ones, substantially less so, to put it mildly.

So hopefully Legolash will be able to get a fix in at some point in the future. There's obviously no huge rush, but it's definitely something that people need to be aware of and is going to require some longer term considerations.

[RicaNeaga]

Another ''bug'' regardin Intel drivers misdetection. Latest Intel Rapid Storage Technology enterprise (RSTe) (download from here) are from the infs windows 8 or up only, although they're also made for windows 7.

 

Please Lego, make Win Toolkit detect 6.2 and 5.2 (as they're mentioned in the infs) also compatible with windows 7 (5.1 / 6.1)

[oguz]

Was this important problem solved? :g:

[RicaNeaga]

Yes Lego, please solve this one soon

[RicaNeaga]

bump

[Legolash2o]

This doesn't actually affect the integration process at all. Win Toolkit doesn't use if it's for XP, Win7, 8, etc... at all, it just for display purposes.