[ipxe-devel] Two problems/bugs in iPXE related to multiple NICs

[Andrew Bobulsky]

Hello Robin, Kevin

On Feb 14, 2013, at 5:03 AM, "Robin Smidsrød" <robin at smidsrod.no> wrote:
> On 13.02.2013 16:46, kevin at fantaplay.com wrote:
>> Indeed, it appears from my testing that Windows won't initialize the 2nd
>> NIC port if it's not given in the iBFT.  This was on an HP ProLiant
>> DL145 G3, which has an integrated Broadcom NetXtreme 5715, which is a
>> dual-ported gigabit Ethernet controller.  I was using the UNDI-only
>> gPXE, but I don't think this would matter to Windows, as it has its own
>> protected mode NIC drivers.
>>
>> I agree that this is surprising behaviour, and it doesn't make any sense
>> to me, but it seems to be the case.  I think you're correct about the
>> permanent static route on the boot NIC, but it is apparently not safe to
>> assume that the OS will allow unlisted NICs to operate as usual.
>
> What if you install a Realtek or Intel NIC in one of the PCI(e) slots of
> the machine, will that NIC be available for Windows to use? Could it be
> a problem with NICs using the same driver as the iscsi boot NIC?

I'm finding myself thoroughly confused here, because I'm booting
Windows 8 from iSCSI on an Intel NIC.... I haven't had any of the
problems you're referring to, Kevin.  I'm chain loading iPXE.pxe from
the onboard Realtek ROM PXE.  I know Windows 8 isn't Server 2012, but
I'd expect similar behavior on this issue.

Could you share your installation procedure, Kevin?  I can try to
duplicate your problem, if you like.

>> I tested this behaviour by modifying gPXE source code to introduce a
>> second NIC section in the iBFT.  At each test I double-checked what was
>> going into the iBFT by reconfiguring the iSCSI target server to expose a
>> different image on the same LUN, and on that alternate image I had in
>> the boot sector a small assembler program I wrote to display a hex dump
>> of the raw iBFT contents and then halt.  I can send that program if it
>> helps.  Once I verified the iBFT was set as I had intended, I would
>> switch the image back and reboot to Windows.
>
> I'm sure someone on the mailing-list would find that useful.
>
>> As mentioned on SF, Windows not only refused to initialize the second
>> NIC port if it wasn't in the iBFT, but it was also very picky about how
>> the iBFT was structured and which NIC the SAN was on.  I almost gave up
>> due to how many changes I had to make to the setup and iBFT before
>> finally discovering what worked.
>>
>> I've posted a question on Technet:
>> http://social.technet.microsoft.com/Forums/en-US/winserver8gen/thread/4754a750-044d-49d2-a2c2-645e543efb45
>
> I noticed a guy named Tim from Cisco responded and said that was the
> responsibility of the NIC vendor. I'd like to hear his response on what
> should happen if you have multiple NICs from multiple vendors in one
> machine. Obviously one vendors firmware can't include other NICs then
> what their own firmware understands, right? And I still don't understand
> why NICs that were NOT used in iscsi booting shouldn't operate as normal.

I'm curious as to what that "responsibility" actually is.  I speculate
here, but several internal/undocumented things have changed regarding
Server 2012 and Windows 8 boot device drivers; for example, the
CriticalDeviceDatabase is just gone.  Perhaps there's something about
initializing the entire NDIS stack(?) at this early point that some...
older drivers just don't like?  In addition, while you could normally
restart many portions of Windows networking to initialize a driver...
I don't think that it will let you do that when the system volume is
behind it.  Perhaps that's the source of device manager's woes :P

>> May I suggest that if you don't tag stable releases, you get rid of the
>> tags altogether and/or place a message prominently on the page that
>> lists the main branch commits, advising visitors that the whole branch
>> represents stable releases?  This may be better than arbitrarily tagging
>> only some of the stable commits, unless they actually are more stable.
>
> The old tags are from gPXE days (before forking into iPXE). I guess some
> kind of message on the download page could be useful to indicate this
> release behavior.

I heartily concur.  I believe that the download page hosts both an ISO
release and build directions: note the status on the build directions,
and put the commit hash and date next to the ISO, perhaps?  That's
auto updated as part of your build system, Michael?  Right? :)

> I'd urge you to join the mailing-list, it's quite low-volume (usually
> less than 10 messages per week).

Indeed!  It's also routinely fascinating ;)

> I've CC-ed my response to the list so more people can help.

Cheers,
Andrew Bobulsky