nic card with the RT os on a target PC not getting on the network

[PaulSammut]

Hello, I've been working on getting NI's RTOS loaded on a desktop pc. 

I first insatlled Real-Time 2011 on my target PC and got it up and running. I was able to go into MAX, see the target on the network, and install software in the target. Then I learned that I had to downgrade to 2010 because I was using LabVIEW Real Time Module 2010 which was incompatible.

So, this is where my problems started. The ethernet chipset on the target pc was an onboard Intel 82579V. This worked fine with Real Time 2011, but was incompatible with 2010. So I got a PCIe NIC card, the Intel 82574L CT. 

I then installed Real Time 2010. The evaluator said everything passed, and I booted into safe mode. The problem is, I can't seem to get on any network. I always get an ip address that is 169.254.x.x. I have tried hooking it up to a router with DHCP and it never gets the 192.168.x.x address. I also tried a switch but still nothing. 

I feel like I might be doing something silly wrong with the networking. Is that 169.blabla address ok? Should I be changing some settings on the host? Thanks!

[Texas_Diaz]

Ugh, if you've got an 82579V onboard your motherboard, it's likely you're using a system with a BIOS that will likely show a bug that only Sandy-Bridge-based (and newer) systems show; it's a compiler bug that sign-extends values when converting 32-bit values to 64-bit values (the Intel network chip needs a 64-bit value, so the driver converts the 32-bit value to 64-bit) - I'm not sure why, but Sandy-bridge systems always allocate memory in the higher memory areas, which seem to trip on this compiler "bug."  Anyway, there is a work-around for this.

First, make sure your target system is formatted with a LV RT 2011SP1 USB Utilities Thumbdrive - it doesn't matter that you're eventually going to use LV RT 2010, using the 2011SP1 boot loader will guarantee that you have drivers that are compatible (at least I'm pretty sure that's the release where I fixed this bug).  To do this, follow these steps:

1. Download the LV RT 2011SP1 Utilities and Drivers.  
2. Unpack the archive onto your Host PC, plug in a USB Drive into your computer, and run the "USBCreate.exe" program from within the USBCreate directory.  This will create a 2011SP1 utilities drive.
3. Boot your Target PC (the one that will run LVRT) with the newly-created USB Thumbdrive.
4. Choose the Format option in the boot menu, and format your system.  I usually choose to wipe your entire disk and create a new RT partition, and use the FAT32 partition type if the disk is greater than 2GB.  

Okay, once the format is complete you'll have a proper boot loader on the Target PC with drivers that can handle both your 82579V and your 82574L correctly.  Now what we need to do is give you drivers to install on your Host PC so that your installed LabVIEW RT can access those devices correctly too.  Fortunately, the download package contains MSI installers for both of the Intel gigabit drivers you need.  Install the Intel8254x and Intel1000ei drivers on your Host PC.  Now, when you install LV RT 2010 from your Host PC, you will see updated ethernet drivers - the newest drivers will install by default when you install LabVIEW Real-Time onto your Target PC.

Give this a shot - let me know if it works or if I need to provide a more updated set of drivers.

-Danny

[Bob_Schor]

I've never tried to configure RT on a PC, but on a PXI or cRIO, you set the IP from the Host, not the RT Target!  The 169.254.x.x address is the "I don't have an IP so I'm going to try to get someone to give me one" situation.

Try the following:  Boot your RT-PC into "normal" mode.  Go to MAX (on your Host PC) and see if MAX can see the RT-PC.  If so, use MAX to set the IP to 192.168.x.x.

BS

[stefankns]

I think I might have a problem which is related to this issue.
I am trying to setup a self build, industry grade desktop realtime target.
The used mainboard is a Perfectron INS8346B with an Intel Q77 Express chipset (http://www.perfectron.com/Q77_Mini_ITX_Ivy%20Bridge_Wide_Temp_INS8346B.html). This means, there is an Ivy Bridge involved and the LAN chipsets are Intel 82579LM and 82574L. According to the compatibility list and the USB Utility everything seems so be fine (intended LV-Version: LV RT 2012SP1). Nevertheless I can not ping the target on its 169.254.x.y. Address (host PCs IP address adjusted accordingly). I tried different versions of the USB Utility (2011SP1, 2012SP12, 2013), without any success.

When disabling the 82579LM chipset in BIOS connecting through the 82574L seems to work fine (using the i8254x driver).

Because I need 2 LAN ports in order to communicate with the target, as well as using the target as an EtherCAT master, I added an Intel Gigabit CT Deskop Adapter (EXPI9301CTBLK -> Intel 82574L) to a free PCIe x1 Slot. In that constellation I get a ping answer, but as soon as MAX is started on the host computer, the ping times out.

Re-activating the 82579LM after a successfull installation via the 82574L leeds to a real mess-up in the LAN config, because the order of the NICs (eth0, eth1) is changed and there seems so be a conflict with the primary adapter setup. I only get timeouts afterwards on all ports.

So sum it up, I could not find any combination of these three LAN options to find a stable setup. Either the target is not even answering to a ping, or the TCP/IP or EtherCAT connection is not stable.

The drivers, the OS is trying to use are:
82579LM: i1000e
82574L (internal): i8254x
82574L (external): i8254x
(drivers from different USB utility verions tested as well as the 5.0.0 versions after setup with 2012SP1 and 2013. MSI-package with i1000e driver update is installed)

Is that driver list right anyway? According to the Intel website both chipsets seem to be from the same family. Or is that because one is a "full" LAN port with an own chipset and the other one a PHY only?

Any help is appreciated! I am running out of ideas.

Best Regards
Stefan

[Texas_Diaz]

Hey Stefan,

That's a unique situation you're in.  Are you using a DHCP-enabled network or are you trying to use the system purely in an AutoIP (Link-Local) configuration?  With 2012SP1 I would not expect those kinds of problems.  Please allow me to ask some specific questions:

1. In Safe Mode (booted through the USB stick) are you able to ping your target via the primary (82579LM) interface?  Remember, you will only be able to ping the target once you select the "Safe Mode" option from the USB Boot Menu and wait for the IP address to show up on the screen.
2. You mention that the controller is no longer pingable when you fire up MAX on the host - are you sure you lose the target when you start MAX, or is it when you attempt to detect remote systems?  When MAX attempts to detect remote systems, MAX sends out communications designed to cause the target to probe itself in ways it likely hasn't done yet - for instance, to determine the amount of available RAM, probe the hard disk, and so on.  It is important to know if the target goes "offline" when you perform this action to actually detect devices - it's possible this more rigorous handling of the system is what's causing problems.
3. The driver list is correct.  Am I correct in assuming you've only tested this system in Safe Mode, and you have not actually been able to install software to the target?
4. When using your primary (82579LM) interface, if you're on a DHCP-enabled network does it get a DHCP address?
5. Would you characterize the broadcast traffic on your network as "heavy"?

-Danny

[stefankns]

Hi Danny,

thanks for the fast response.

1. I checked again: 82579LM activated, 82574L deactivated, extra NIC removed from the system. Booting with USB stick 2012SP1 -> Boot to safe mode. 169.254.100.20. shows up. No answer to a ping. Host is in the correct subnet.

2. You are completely right. It happens as soon as the network detect is indicated by the refresh symbol. Maybe some other hardware component is causing the issue? We have 4GB of RAM installed (2x2GB) and already tested to remove one memory bank last week. No change in the behaviour.The harddisk is an Intel SSD 520 Series, 120GB. Memory is ATP BT MEM SODIMM DDR3. The CPU is a i7-3770. Thats all in that box.

3. No. I succeeded in installing a system once by a very special series of activities: First deactivating one internal NIC (82579LM), installing a base system 2012SP1 with 5.0.0 drivers via the 82574L. Adding the external NIC, deactivating the second internal adapter (this switches the primry adapter in a "hard" way) and turning on the 82574L again, configuring it as EtherCAT. Funny sequence, but the system seemed to be stable for a while... But when applying load to the TCP/IP link or starting the EtherCAT master the system broke down (lost of connectivity). With any other combination of NICs, no ping answer was ever received. The same is valid for the constellation, where only the "external" NIC (82574L via PCIe) is activated and all internal NICs are disabled.Just ping timeouts.

4. I do not use DHCP. It will be an own subnet for a group of test devices. We will also later on use static IP-addresses. I checked it with our company DHCP server and did not receive an IP address.

5. It's host <-> target direct link or host <-> switch <-> target. Tested both, no difference. So to answer your question, no nearly no broadcast at all i would say.

/Stefan

[Texas_Diaz]

Very interesting.

What it seems to me is that you've got a 2-prong issue.  

1. If the 82579LM NIC is not able to get a DHCP address, it means there's a problem with initializing and using that NIC - I can't guarantee the 1000e NIC driver for LVRT will work with every stepping of the 82579LM device nor every MAC that the 82579LM PHY could be paired with.  I will completely admit that I have not been able to test a wide variety of device combinations out there, most of what I've gotten are the Intel reference boards and Intel motherboard designs like that of our PXIe-8135 controller (which contains the 82579LM).  Your motherboard manufacturer that is "using" Intel components may implement something different that I'm not accounting for - like a different FLASH mechanism, different FLASH format/contents, or different MAC device.
2. Is your SSD formatted FAT32?  Have you formatted the system with the USB utility using the format option and selecting, "Erase All Partitions and..."? The most common reason for a controller dropping offline when MAX attempts to detect remote devices is a hard disk partition that isn't in the format we expect - formatting the disk with the USB utility can fix that.  

I'd like to first determine if we can get your system "working" with the 82579LM disabled, and then we can get back to the 82579LM (because there's very little I can do right now without sending you an instrumented driver to see what's actually going on).

Can you try this?

-Danny

[stefankns]

Hi again,

in the meanwhile I tested many different BIOS settings to disable as much hardware as possible (or as much as I understand actually). I also exchanged the SSD by a standard SATA drive. Everything without any change. Still no ping.

2. Yes I always formatted the hard drive with the USB utility. BUT with "Reliance" File System. I did a check on FAT now (only 82574L enabled) and received a ping immediately. I installed 2013 13.0 and changed the IP address to the intended subnet. No ping after several restarts. After "Deep Power Off" (10s from power), everythings was fine. I have a ping and can install more software. The system is up fast and very responsive. Should I try to insert the external NIC now (for the EtherCAT master) ?

I can test the 82579LM issue with a special driver later on, no problem!

/Stefan

[Texas_Diaz]

The reason I wanted you to use FAT is because I know the code there - Reliance is licensed to us mostly as a "binary blob" and so it's harder to debug and we don't have a lot of experience in determining under what "exotic" circumstances it will and will not cause issues.

Go ahead, and try your EtherCAT master.  Just understand that you cannot configure the FIRST device detected in your system as the EtherCAT master - the FIRST device detected in your system (the one listed first in the device list printed to the screen) must be your TCP/IP device for the controller.

-Danny

[stefankns]

Hi!

Ok. I understand the FAT thing now.

I added the PCIe NIC and here is where trouble kicks in. The external NIC is detected as eth0 and I know about the fact that EtherCAT can not be selected on eth0...

I exchanged the primary adapter and it worked! Still a ping, EtherCAT is selectable on eth1. What I can not test here and right now is, if the EtherCAT master is stable. Might there be also some interaction with the file system? With the "NIC juggling procedure" described earlier I managed to end up in exact the same setup last friday (external 82574L on eth0 -> TCP/IP, internal 82574L on eth1 -> EtherCAT), but with an unstable master. BUT I had reliance then.

/Stefan