========================
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
traffic.
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
utility.
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.