Ticket #20514 (new defect)

Opened 19 months ago

Last modified 19 months ago

Networking is not functional under OPENSTEP 4.2/Mach for Intel

Reported by: GNUstepLeadDev Owned by:
Component: network Version: VirtualBox 6.1.26
Keywords: Cc:
Guest type: other Host type: other


Being the lead developer of GNUstep it is sometimes useful to have OPENSTEP on hand. Recently I installed OPENSTEP on virtualbox 6.1.97 (not sure why this is not listed in the versions dropdown). The AMD PCNet 32 adapter which VirtualBox presents is detected, but it is not usable. Oddly, under VMware it is useable but VMware doesn't support VESA display modes so networking works, but little else does on VMware.

The files you will need to install OPENSTEP are here...

I would prefer to keep using VirtualBox as it is open source. Please see if you guys can fix this. I have not tried 6.1.26, but I am certain it is not functioning there either.

Change History

comment:1 in reply to: ↑ description Changed 19 months ago by vushakov

Replying to GNUstepLeadDev:

I have not tried 6.1.26, but I am certain it is not functioning there either.

6.1.26 certainly does work.

comment:2 Changed 19 months ago by michaln

The "problem" is that the development builds of VirtualBox are stricter in that they enforce the PCI device's command register bus master enable bit. For some reason the NeXTSTEP/OpenStep AMDPCnet32 driver disables PCI bus mastering right before starting the chip initialization (which requires bus mastering to function) and then immediately turns it back on.

It's not at all clear what this is meant to accomplish or why it even works on real hardware, and it certainly is the opposite of what the PCnet datasheet says drivers should be doing.

We should be able to work around this bizarre behavior.

comment:3 Changed 19 months ago by GNUstepLeadDev

THANK YOU SO MUCH. This works correctly. Why are the development builds stricter? I am not sure why this works on real hardware, but I am betting that on some motherboards it might not have. Anyway, you can close this as it is working for me now. Next time I will test with the actual release before writing an issue.

comment:4 Changed 19 months ago by michaln

The behavior is stricter because it's a) the right thing to do, and b) required for emulated IOMMU and such.

In the meantime we found out that the strange behavior of the drivers is a workaround for some kind of a silicon bug in the early PCnet-PCI chips. It's unclear how it actually works in real hardware; PCI bus mastering is turned off, then the chip initialization is started, which requires bus mastering, but then PCI bus mastering is immediately enabled again before waiting for the initialization to finish.

We now have a workaround for this oddity and future development snapshots of VirtualBox should work with the OpenStep PCnet32 driver again.

As an aside, newer PCnet drivers, such as the ones in Windows 2000 and XP, recognize that the newer PCnet chips emulated by VirtualBox don't have the silicon bug and the odd driver behavior does not take place. But many older drivers apply the workaround to all PCnet PCI chips, buggy or not.

Note: See TracTickets for help on using tickets.
ContactPrivacy policyTerms of Use