QNX 6.4, no network with E1000 => Fixed in SVN

Which network card did you select for the guest? Does it make any difference if you use E1000 instead of PCNet? Did this ever for with an older version of VirtualBox?

Replying to frank:

Which network card did you select for the guest? Does it make any difference if you use E1000 instead of PCNet? Did this ever for with an older version of VirtualBox?

First the default card (default configuration) and later the other available cards. For all cases the network don't work

I like to add some additional information to this case, since I'm facing the same.

Host OS: Mac OSX 10.5.8 Guest: QNX 6.4.1

VBox: 3.0.6 r52128

All three Intel/PRO ethernet devices stop the VM from starting at all with this error:

PDM: Failed to construct 'pcnet'/0! VERR_CFGM_VALUE_NOT_FOUND (-2103) - Value not found.
ERROR [COM]: aRC=NS_ERROR_FAILURE (0x80004005) aIID={0a51994b-cbc6-4686-94eb-d4e4023280e2} 
aComponent={Console} aText={Configuration error: Failed to get the "MAC" value (VERR_CFGM_VALUE_NOT_FOUND).
Unknown error creating VM (VERR_CFGM_VALUE_NOT_FOUND)} aWarning=false, preserve=false
Power up failed (vrc=VERR_CFGM_VALUE_NOT_FOUND, rc=NS_ERROR_FAILURE (0X80004005))

Both lance versions causes a flooding of the VBox.log file with *400* entries of this per second:

...
00:04:10.225 PCNet#0: BAD RMD ENTRIES AT 0x1a02001e (i=1)
00:04:10.227 PCNet#0: BAD RMD ENTRIES AT 0x1a02001e (i=1)
00:04:10.229 PCNet#0: BAD RMD ENTRIES AT 0x1a02001e (i=1)
00:04:10.231 PCNet#0: BAD RMD ENTRIES AT 0x1a02001e (i=1)
...

which is from pcnetRdtePoll(PCNetState *pThis, bool fSkipCurrent=false) in

src/VBox/Devices/Network/DevPCNet.cpp:

  1724              {
  1725                  STAM_PROFILE_ADV_STOP(&pThis->CTXSUFF(StatRdtePoll), a);
  1726                  /* This is not problematic since we don't own the descriptor
  1727                   * We actually do own it, otherwise pcnetRmdLoad would have returned false.
  1728                   * Don't flood the release log with errors.
  1729                   */
  1730                  if (++pThis->uCntBadRMD < 50)
  1731                      LogRel(("PCNet#%d: BAD RMD ENTRIES AT %#010x (i=%d)\n",
  1732                              PCNET_INST_NR, addr, i));
  1733                  return;
  1734              }

Disabling the QNX automatic device enumeration in /etc/system/enum/devices/net for PCI dev id 2000 causes the flooding to stop, but nevertheless the emulation doesn't work. The emulation inits:

00:04:51.638 PCNet#0: Init: ss32=0 GCRDRA=0x19000000[1] GCTDRA=0x1900f000[1]

but doesn't reply neither ARP who-has, nor DHCP discover packets.

schmidtm, please could you attach your VBox.log files, one for the E1000 case and one for the PCNet case?

VBox.log files for all five network emulations, all intel/Pro's prevent startup of vbox

I've attached the logs for all five emulations. Only the PCnet II (Am79C970A) floods the log.

HTH - Matthias

Well, the VMs don't start when you select an E1000 network card because you didn't adjust the rules for port forwarding. There are still port forwarding rules for the first pcnet device in place. Remove these rules and you will be able to boot your guest with E1000.

The problem with the pcnet device emulation needs to be investigated.

I'm able to boot QNX 6.4.1 with the e1000 device selected and networking appears to work for a bit but will stop working very soon after I start producing network traffic (the host appears to stop responding).

If I ping a host-only network, the first 10 or so requests from the guest will get replies from the host, but then the host stops responding to the incoming requests (which I observed were still making it through to the host with Wireshark).

VBox.log file for the e1000 that successfully boots but network stops working

Fixed the PCNet device emulation. The problem was that on S_RESET, the BSR_BCBC was resetted despite the fact that the PCNet manual clearly states that no BCR register must be resetted during S_RESET. I could reproduce the problem with the E1000 emulation, have to investigate whats wrong there (different problem).

The fix will be contained in the release which comes after 3.0.8.

I hereby verify, that Frank's fix make pcnet work on QNX.

There were two issues in E1000 implementation:

1) ICR register was not cleared upon reading if the interrupts were disabled via IMC (which was an optimization for windows guest actually); 2) RX checksum offloading did not set IPCS and TCPCS flags properly which caused ARP replies being sent by the guest to be discarded by its e1000 driver.

The E1000 fix will be part of the next major update.