Due to a failed upgrade of Joomla (the content-management software for Retrosys), a re-installation of the software and a database restoration has occurred.  There has been no loss of public or private content.

 

========================
  September 24, 2018 UPDATE
========================

I've been sent a 3Com EtherLink II (3c503) ethernet adapter to check out with the working Mach386 distribution.

I've successfully installed the hardware and, after setting the card jumpers and reconfiguring the BIOS to accommodate this legacy ISA card, it has proven to work well.

The configuration quirks of the 3c503 and Mach386 currently allow for one of the following card configurations to be utilized:

  1. Address 0x2e0, IRQ 5, BNC Connector
  2. Address 0x2a0, IRQ 2, AUI Connector
  3. Address 0x280, IRQ 2, BNC Connector
  4. Address 0x300, IRQ 2, AUI Connector

The memory must be set for 0xDC000 or 0xD8000.  The selection will be detected automatically.

As with the WD/SMD 80x3 ethernet cards, the motherboard BIOS settings may need to be changed.   The changes required would be to reserve the IRC to Legacy ISA assignment, and to reserve the memory block to prevent it from being used for RAM addressing.

The address, IRQ and Connector settings are hardcoded, and could be changed by modifying the driver and rebuilding the kernel.

I discovered on the 26th that if you attempt to unmount an ISOFS
filesystem while it's busy, the kernel will panic.

This afternoon, I tracked the problem down to "flush" code
in the isofs driver:

*** isofs_node.c.ORIG Wed Feb 28 18:59:56 2018
--- isofs_node.c Wed Feb 28 18:50:12 2018
***************
*** 201,232 ****
--- 201,234 ----

   /*
   * stupid fs-specific flush routine
   */
   isoflush(vfsp, vp)
           struct vfs * vfsp;
           struct vnode * vp;
   {
           union iso_ihead *ih;
           struct iso_node *ip, *iq;

         iq = VTOISO(vp);
   loop:
         for (ih = iso_ihead; ih != &(iso_ihead[INOHSZ]); ih++) {
                 for (ip = ih->ih_chain[0];
                          ip != (struct iso_node *)ih;
                          ip = VTOISO(ip->iso_forw)) {
                          if (ip->iso_fs != vfsp)
                                   continue;
                          if (iq != (struct iso_node *) 0 && ip != iq)
                                   continue;
                          if (ip->iso_count != 0) {
+ #ifdef CAUSES_PANIC_WHEN_BUSY
                                   dnlc_purge_vp(ISOTOV(vp));
                                   binvalfree(ISOTOV(ip));
+ #endif CAUSES_PANIC_WHEN_BUSY
                                   if (ip->iso_count != 0)
                                            return (EBUSY);
                                   goto loop;
                          }
                 }
         }
         return (0);
   }

I don't understand why, despite the vnode being "busy," there was
an attempt to force that purge and free of the node. There won't
be any pending write data to flush, since ISOFS mounts are read-only.
I've #ifdef'd out those two lines and unmounting an ISOFS while
the vnode is in use now errors with EBUSY as expected. Mach 2.6
doesn't have umount "force" capability, so it wouldn't be useful
to attempt a rude unmount.

The ISOFS driver code is incomplete, based on comments in the code
itself. This may just be a problem characteristic of this new
ISOFS functionality having just been introduced into 2.6MSD when
it was released by Mt Xinu.

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