VirtualBox

Ticket #3206 (closed defect: fixed)

Opened 5 years ago

Last modified 4 years ago

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

Reported by: jean-jacques Owned by:
Priority: major Component: network
Version: VirtualBox 3.0.6 Keywords: QNX network
Cc: Guest type: other
Host type: Linux

Description

With QNX 6.4, the network interface is apparently recognized and can be configured but there is no connection to the network (NAT / Hostinterface).

Attachments

vbox-306-logs.tar.gz Download (67.3 KB) - added by schmidtm 5 years ago.
VBox.log files for all five network emulations, all intel/Pro's prevent startup of vbox
vbox-306-log-e1000.tar.gz Download (9.7 KB) - added by benbiron 5 years ago.
VBox.log file for the e1000 that successfully boots but network stops working

Change History

comment:1 follow-up: ↓ 2 Changed 5 years ago by 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?

comment:2 in reply to: ↑ 1 Changed 5 years ago by jean-jacques

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

comment:3 Changed 5 years ago by schmidtm

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.

comment:4 Changed 5 years ago by frank

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

comment:5 Changed 5 years ago by frank

  • Version changed from VirtualBox 2.1.2 to VirtualBox 3.0.6

Changed 5 years ago by schmidtm

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

comment:6 Changed 5 years ago by schmidtm

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

HTH - Matthias

comment:7 Changed 5 years ago by frank

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.

comment:8 Changed 5 years ago by benbiron

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).

Changed 5 years ago by benbiron

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

comment:9 Changed 5 years ago by frank

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.

comment:10 Changed 5 years ago by frank

  • Summary changed from QNX 6.4, nor network to QNX 6.4, nor network => Fixed in SVN

comment:11 Changed 5 years ago by schmidtm

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

comment:12 Changed 5 years ago by frank

  • Priority changed from critical to major
  • Summary changed from QNX 6.4, nor network => Fixed in SVN to QNX 6.4, no network with E1000

comment:13 Changed 5 years ago by aleksey

  • Summary changed from QNX 6.4, no network with E1000 to QNX 6.4, no network with E1000 => Fixed in SVN

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.

comment:14 Changed 4 years ago by frank

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

comment:15 Changed 4 years ago by frank

Please check if VirtualBox 3.1.0 Beta 2 fixes this problem for you.

comment:16 Changed 4 years ago by frank

  • Status changed from new to closed
  • Resolution set to fixed
Note: See TracTickets for help on using tickets.

www.oracle.com
ContactPrivacy policyTerms of Use