+- iPXE discussion forum (https://forum.ipxe.org)
+-- Forum: iPXE user forums (/forumdisplay.php?fid=1)
+--- Forum: General (/forumdisplay.php?fid=2)
+--- Thread: Intel i350 Windows 7 BSOD 0x74 (/showthread.php?tid=7119)
Intel i350 Windows 7 BSOD 0x74 - bleckers - 2013-11-22 12:16
Hi,
I have 20x Supermicro X9SRG-F boards that I am trying to iSCSI boot Windows 7 Pro SP1 x64 on with iPXE. Unfortunately I get an "Autochk program not found - Skipping Autocheck" message flash on the screen and then get a BAD_SYSTEM_CONFIG_INFO (0x74,0x00000074) BSOD after the first reboot when installing Windows. These machines work fine with various flavours of Linux with iSCSI/NFS booting with iPXE and they boot when installing Windows to an SSD/HDD.
Here is the windbg output: http://pastebin.com/sRu4g5C6
I have exhausted all options with regard to this and I come to the forums for help. I have tried the following:
Memtest overnight.
Different machines.
Removing all hardware except for CPU/RAM (one stick).
Tried ipxe.pxe and undionly.kpxe.
Slipstreaming intel chipset (inf) drivers.
Different Intel NIC driver versions.
Updated bios.
Updated ipmi firmware.
Installing from sata cdrom.
Numerous bios settings: usb, chipset etc.
Different iscsi targets - zfs(iscsitadm)/ietadm.
Different networking architectures/switches.
Bcdedit checks (make sure that it's drive c: that it's trying to load).
Mount iscsi target on another Windows machine. This works fine.
Check registry hives once mounted. They seem fine.
I am using the ipxe-2b86978 (https://git.ipxe.org/ipxe.git/commit/2b86978) checkout of iPXE (this build works for all of our other machines). Looking through the later commits didn't show anything that might be worth the upgrade. I had also tried a December 2012 build but it yielded the same error.
Does anyone else have any other suggestions, I am at my wit's end.
RE: Intel i350 BSOD 0x74 - bleckers - 2013-11-28 04:09
I manged to solve this by using another NIC in the machine. We have the Intel 520 DA2 in these machines as well which works fine for this. It definitely seems like it's hardware/driver related in this case.
Using the ipxe.pxe kernel driver version of iPXE, the x520 enumerates as eth0. So enabling PXE boot on the 1G interface (i350) allows you to pull the ipxe image down and the machine will continue to sanboot from the x520 after this (if this enumeration doesn't happen in this order you could write a script to do this, rather than having to flash the x520s).
Just a note. During an initial test, we tried to install with the option routers option set in both "if" statements (for the 1G and 10G card) but Windows would return the error "Cannot install Windows to this disk". Placing it only in the 10G option removes this confusion and allows Windows to install.
The following is configured in our DHCP conf (the 10G and 1G are on separate VLANs in this case which is why Windows got confused, change as appropriate):
Code:
option space ipxe;
option ipxe.keep-san code 8 = unsigned integer 8;
option ipxe-encap-opts code 175 = encapsulate ipxe;
option ipxe.bus-id code 177 = string;
option iscsi-initiator-iqn code 203 = string;
option ipxe.skip-san-boot code 9 = unsigned integer 8;
group { # id="10G"
option routers X.X.X.X; #Router IP
next-server X.X.X.X; #TFTP Server
host machineXX {
#option ipxe.skip-san-boot 1; #Uncomment this when installing.
option ipxe.keep-san 1;
fixed-address machineXX;
hardware ethernet XX:XX:XX:XX:XX:XX;
option host-name "machineXX";
option root-path "iscsi:X.X.X.X::::iqn.2013-11.blah.blah:machineXX.boot";
if exists user-class and option user-class = "iPXE" {
filename "";
option routers X.X.X.X; #IP of iSCSI Target
} else {
filename = "ipxe.pxe";
}
}
group { # id="Netboot-1G"
next-server X.X.X.X; #TFTP Server
option routers X.X.X.X; #Router IP
host machineXX-netboot {
fixed-address machineXX;
option host-name "machineXX-netboot";
hardware ethernet XX:XX:XX:XX:XX:XX;
if exists user-class and option user-class = "iPXE" {
filename "";
} else {
filename = "ipxe.pxe";
}
}I would like to try at a later stage when time permits to debug iPXE.
RE: Intel i350 BSOD 0x74 - robinsmidsrod - 2013-11-28 09:32
If you believe there is a problem with the driver, you should try to go through the tests mentioned on http://ipxe.org/dev/driver and report your findings. I would suggest you send your report to the mailing-list, as the core developers read that more often than the forum.
RE: Intel i350 BSOD 0x74 - bleckers - 2013-11-28 10:27
(2013-11-28 09:32)robinsmidsrod Wrote: If you believe there is a problem with the driver, you should try to go through the tests mentioned on http://ipxe.org/dev/driver and report your findings. I would suggest you send your report to the mailing-list, as the core developers read that more often than the forum.
Thank you. I shall definitely be looking into that in about two weeks time. I'll also try to log the debug output when booting as well.
The i350 is very common so I'm sure there must be something more to it. Mind you I flashed one of the machines with the latest BIOS update from Supermicro and that update actually turned out to be bad, but the revision previous to that was fine. I verified this with our distributor 2 weeks ago and they said it bricked one of their machines too. Supermicro still hasn't taken that update down, so it's probably some bad design/QA going on.