Carrier Sense Lost on TX

Quick Question,

I have a QNX machine with 2 NIC cards in it.

I configured one card to have a static IP of 192.168.0.2. I attach a cable and plug into a Windows box configured as 192.168.0.1.

I attempt to ping and nothing happens. The prompt just sits there until I hit CTRL-C to abort.

Doing a nicinfo -r en1

I see that the transmission rate for this card is set to 0 instead of 100 MBit. I also see that Carrier Sense Lost on TX is increasing by 1 for every attempted ping packet.

So I do a quick re-configure to make the other card have the static IP of 192.168.0.2 and plug the cable into it. Voila, it pings and communicates with the Windows box perfectly.

So the cable and Windows box aren’t the problem.

Is it likely the NIC itself is dead or could something else sharing a PCI interrupt with the problem NIC card be causing the Carrier Sense Lost on TX to occur?

When I did pci -v I found the following device sharing the interrupt with the problem NIC card:

Class - Processor
Vendor - Texas Instruments
Device ID - PCI 2040 PCI-DSP Bridge Controller
… snipped the rest

One more thing, these 2 cards are not removable so I can’t swap them in their PCI slots to see if there is a shared interrupt issue.

Thanks,

Tim

It could be the network driver has issues with dual NIC. You can try to start two instances of io-net each specifying the ioport/irq for each NIC.

On the other hand, since you can get it work with the first NIC, why not just stick with it. Or are you planning to use both of them?

Noc,

I didn’t mention this in the original post but we have a pile of these exact same card cage boards (everything built onto the board which is why I can’t replace the NIC) in other machines and both NIC cards work on all the others just fine.

And yes, I do plan to use the other NIC card in the future so it’s not something I want to let go.

Since all our other card cage boards with QNX on them work just fine it seems to me that something is amiss and I’d like to track down the problem. That’s why I posted about whether it was likely to be a defective NIC card or something causing interrupt issues.

Right now hardware engineers are swapping some of the other boards in the card cage in an attempt to see if the problem goes away due to another board somehow affecting the one with QNX on it.

Tim

Just in case; en1 is actually the second card. The first card being en0