February 18, 2018 UPDATE

A new interesting problem discovered today. I suddenly noticed that
the SMC WD80x3 ethernet driver is not discovering the card's MAC
hardware address correctly. It was only reporting the first three
bytes correctly--the last three were always zeroes.

This was discovered when I was trying to bring up a second Mach386
machine as a testbed for new kernel and other software builds.

I first suspected a hardware problem, and swapped cards. The same
thing was occurring. Worse yet, I checked the main development
machine... and it was occurring there as well.

The problem is only noticed now because trying to use two Mach386
machines on the same network caused a MAC conflict between them.
They both were using the MAC ID of 00:00:c0:00:00:00. tcpdump(1)
verified that the incorrect MAC ID was being used on ethernet

I couldn't be sure that I had actually seen the MAC addresses
correctly determined under Mach386. My recollection was that I
only ever paid attention to the MAC was when utilizing the
SMC EZsetup software and sending out test packets from the DIAGNOSE

So I booted up DRDOS and checked out the DIAGNOSE utility. I saw
the correct MAC id being sent onto the network. This verifies that
the network cards are not at fault.

I turned my attention to the Mach386 kernel. I began booting
older kernels that I've built, presuming that I had made an errant
change. All showed the same MAC problem.

Then I tried the last custom-built kernel from 1993, which I built
from updates from Mt Xinu. This one failed as well.

I then reverted to the latest Mt Xinu floppy distribution kernel.
I must take care when running this kernel, as it has differences
in the disk drivers and disk labeling software. It can be destructive
to try to fsck(8) a large filesystem with it. I avoided letting fsck(8)
get run.

This Mt Xinu kernel probed the MAC address correctly.

OK, back to the kernel sources then. Obviously something happened
to the if_ns8390.c driver code for the SMC 80x3 cards.

Long story short, I found the following code in the driver:

if (((u_char) inb(hdwbase+IFWD_LAR_0) == (u_char) WD_NODE_ADDR_0) &&
         ((u_char) inb(hdwbase+IFWD_LAR_1) == (u_char) WD_NODE_ADDR_1) &&
         ((u_char) inb(hdwbase+IFWD_LAR_2) == (u_char) WD_NODE_ADDR_2)) {
     ns8390info[unit] = dev;
     sp->card = wd8003_card;
     ev->name = wd8003_card;
     sp->nic = hdwbase + OFF_8390;
     /* enable mem access to board */
     sp->board_id = wd80xxget_board_id(dev);

     *(sp->address) = inb(hdwbase+IFWD_LAR_0);
     *(sp->address + 1) = inb(hdwbase+IFWD_LAR_1);
     *(sp->address + 2) = inb(hdwbase+IFWD_LAR_2);
     *(sp->address + 3) = inb(hdwbase+IFWD_LAR_3);
     *(sp->address + 4) = inb(hdwbase+IFWD_LAR_4);
     *(sp->address + 5) = inb(hdwbase+IFWD_LAR_5);
     return TRUE;
} /* checks the address of the board to verify that it is a WD */

And keeping the story short... That call to wd80xxget_board_id(dev) is
where the trouble occurs. Once that function returns, the inb(...) calls
to obtain bytes from the card are returning a value of zero.

I haven't investigated the fault further. But I've worked around the
problem for now.

I've moved that board_id function call to *AFTER* assigning the MAC address bytes
with the inb() functions.

I will spend time at a later date to fully determine the problem and resolution.
It may be an issue of CPU speed/timing; Back in the early 90's, I likely ran
a 486DX2 50 or 100mhz machine for Mach386. Today, I'm running it on a Pentium
III 800mhz and a Celeron 500mhz machines.