Details

=======================
February 3, 2018 UPDATE
=======================

I have found my last root dump and usr tar archives from 1996 which includes the
latest updates I was able to sup(8) from Mt Xinu in 1993. I will be assembling
additional distribution additions with the updated binaries and files. Included
in these updates from Mt Xinu are working SCSI support, additional userland and
GNU utilities and the Mt Xinu MSD 2.6 rebuildable/reconfigurable kernel.

I have also located the January 21, 1991 distribution floppies. However, there
are a number of unreadable floppy sectors in various locations of this set which
renders the entire distribution useless. Since the distribution sets are
effectively sequential chunks of compress(1)'d data, the loss of a block of
data in any of the floppy sets renders that set incomplete and a working
installation from it is impossible.

Details

=======================
February 8, 2018 UPDATE
=======================

I've gotten networking working now. I'd been having great difficulty
with Mach386 in getting a working setup with the supported networking
cards. The only supported cards are the Western Digital/SMC 80x3 and
3Com 3c502 and 3c503 (EtherLink II) cards, all of which are ISA-bus
cards.

Despite the documentation showing supported IRQ/PIC configurations
with IRQ 2 (actually IRQ 9 in more modern hardware) and IRQ 5, it turns
out that the source for autoconf.c has all configuration options
hardcoded to IRQ 2/9. As it turns out, the motherboards I have
will not work setting these networking cards to IRQ 2/9.

The cards would successfully transmit packets, and the on-board
LEDs would indicate receipt of a packet, but the Mach386 kernel would
never see an interrupt and thus would never be able to load the
packet from the card.

After obtaining and failing to get a number of WD8003 and WD8013
cards working, and ultimately discovering this issue, I hand-edited
the vmunix kernel file. Having located the autoconf storage for the
configurations, I changed the IRQ configuration options for these
cards to IRQ 3, booted that modified vmunix, and I have ethernet
connectivity now.

There are some additional issues I'm working out with NFS, but I expect
these to be resolved in short order.

I will be pursuing SCSI functionality very soon now as well once I
receive working Adaptec AHA1542B cards I've ordered.

Additionally, I'm well underway in writing a sysload(8) replication
program that runs on modern UNIX. This replacement will be the basis
for a utility to generate new distribution media to facilitate updating
binary systems and generating a new release with the latest binaries
I have availab.e

I'm also working on getting the reconfigurable kernel generation files
working that will allow easier device configurations (rather than using
a binary editor as I've just done for the networking card configuration).

More to come...

Details

=======================
February 9, 2018 UPDATE
=======================

Receipt today of a working Adaptec AHA1542B controller has provided
me the means to test and utilize SCSI support in Mach386.

Preliminary testing shows that the late-1992 Mach386 vmunix kernel
works well for SCSI disk. SCSI tape seems to have an issue wherein
it is writing an extra tape record when a tape device is closed after
writing.

This first SCSI Disk testing was performed with a Seagate ST15150N
Barracyda 4 drive. This drive is 4,294 Mbytes formatted, This is
exactly the 4GByte disk-size limit of the 32-bit Mach386 kernel.
The BSD UFS filesystem limit is 2GByte. Full testing of this drive
and the 4GB limit will occur in the next few days.

A 2GB (Max, for the BSD UFS architecture) can be created and mounted:

# df /mnt2
Filesystem 1024-blocks Used Available Capacity Mounted on
/dev/sd0h 1969518 2 1772564 0% /mnt2

The SCSI Tape testing was first performed with a Seagate STD2401LW DDS-4
tape drive utilizing a DDS-1 tape. Various DDS tape drives were
actually tested, but I settled on this DDS-4 drive once I realized
that the extra block being written (and read) from the tape was
not specific to a particular drive.

Additional drive testing with a Quantum 4000 (TH5AA-YF) DLT tape
drive indicates the same sort of problems. Additionally, preliminary
testing there shows that at 20480-byte block size, the 20480th
byte of the first block is being written or read back incorrectly
as that byte fails comparison to the original data.

There are definitely problems with the st.c SCSI tape driver.

Today I also successfully mounted an NFSv2 filesystem from a FreeBSD 11.0
server onto Mach386:

# mount mod5:/tiny /nfs
# df /nfs
Filesystem 1024-blocks Used Available Capacity Mounted on
mod5:/tiny -785220319 -1208500253 423279934 154% /nfs

Compare that to the server's reporting of that filesystem:

# df /tiny
Filesystem 1K-blocks Used Avail Capacity Mounted on
zpool1/tiny 12099681569 938983394 11160698174 8% /tiny

It will be interesting to see what issues arise.

Details

=======================
February 11, 2018 UPDATE
=======================

Today I have successfully recovered the relinkable kernel distribution,
built, and booted a new kernel. This is important as it means that the
portions of the kernel provided in source form can be modified and a new
kernel generated. The important source files provided are:
i386at:

  • adaptec.c Adaptec AHA 1540/1542 SCSI controller driver
  • autoconf.c Device configurables: Port, IRC/PIC, Memory
  • com.c Serial port 8650/16450 UART driver
  • conf.c Device driver linkages to the kernel
  • hd.c MFM/IDE/ATA controller (DOS/WD-compatible)
  • if_ns8390.c NS8390 (Western Digital and compats) network driver
  • if_par.c Parallel Network Interface
  • if_pc586.c PC 586 and compatibles network driver
  • lpr.c Parallel port driver
  • sd.c SCSI Disk driver
  • st.c SCSI Tape driver
  • qd.c AST Async Cluster Adapter driver

I've changed the default configuration options for the NS8390/WD80x3
network card as follows:

Detection Order Port IRC/PIC Memory
1 0x280 3 0xd0000
2 0x2a0 5 0xd0000
3 0x2e0 10 0xd0000
4 0x300 10 0xcc000


Options #1 and #4 allow use of the hardware jumpering on the card for
those combinations. The others can be set via the SMW EZSETUP utility
for setting the "soft" jumper configuration.

With the recovered and buildable kernel distribution, I will not be
able to debug and fix the SCSI Tape "last tape block" problems described
previously.

Included in the relinkable kernel distribution are a kernel driver
and mount_isofs command to mount and read ISOFS/CD9660 CDs. The CD
device must be one that is settable for 512-byte block and SCSI-
interfaced. I've tested this code works in a new kernel.

So far no issues with NFS or any other networking facility.

Today I also successfully mounted an NFSv2 filesystem from a FreeBSD 11.0
server onto Mach386:

# mount mod5:/tiny /nfs
# df /nfs
Filesystem 1024-blocks Used Available Capacity Mounted on

Mounting a Mach386 NFS filesystem on FreeBSD 11.x is also working.
The mount_nfs "-o mntudp" option is needed on the FreeBSD side
to allow it to communicate with the older NFS protocol used by
Mach386.

From my recovered dumps from 1996, I've updated my working recovery system
with all the latest Mt Xinu-distributed updates. I will pursue generating
update-floppy images to bring a freshly-installed system, from the distribution
floppies, to these latest-available binaries.


I've ported the 2.11BSD patched date(1) command to allow manually setting
a date beyond Y2K. The kernel is already using a 32-bit time_t, so it is
still restricted to the Y2038 limitation, however I have not discovered any
Y2K bugs other than the date(1) command; the kernel is Y2038-compliant.

With respect to the SCSI tape problems I've encountered:
I been doing testing with the oldest drive I have: Tandberg Data TDC3600
150MB QIC drive using DC6150 tapes. The driver appears to be returning
the last block twice. That is, when EOF is reached, it sends the previous
block one more time before reporting EOF to the calling process on a
subsequent read. I've verified this with a tape recorded on another
operating system. I believe I've ruled out controller, SCSI version
(SCSI-1 vs SCSI-2), and the drive. Three different drives of different
media type and greatly different generations (QIC vs DDS vs DLT) all
exhibit the driver problem. I continue to track down the exact symptom
and conditions (Unix block size Vs. Pysical device block size, etc.)
before I will start debugging the st.c and adaptec.c drivers for this
issue.

Later Note:


OK, here's what's happening. I wrote a tape on this same hardware
with FreeBSD 8.1. I wrote a tarball to disk containing the FreeBSD
kernel:


# ls -l kernel.tar
-rw-r--r-- 1 root 11784704 Feb 11 21:58 kernel.tar


I then used dd(1) to write that to a DLT III tape (via a DEC
TZ87 tape drive this time) using a 10,240 block size. That was
1,150 blocks plus one partial block of 8,704 bytes at the end.
I read the tape back to verify the block count and written data.

I then copied that kernel.tar to USB and moved it over to another
machine for reference.

I booted Mach386 again on this hardware.
Under Mach386, I read the tape with dd(1) using 10,240-byte blocks:

mod43 11 # dd if=/dev/st0 bs=10240 of=DLT.tap
1151+1 records in
1151+1 records out

Note the extra block. It should have read 1150+1 records.
I copied the USB kernel.tar file across the network to Mach386,
named 'kernel.tar'. Notice the differences in sizes:

-rw-r--r-- 1 root 11794944 Feb 11 21:57 DLT.tap
-rw-r--r-- 1 root 11784704 Feb 11 21:58 kernel.tar

That is a difference of 10,240 bytes, the blocksize being read
via dd(1).

To verify what's happening, I performed the following:

1. Read the first 1150 blocks from tape into a file:

mod43 56 # bs=10240 count=1150 of=t1-1150
1150+0 records in
1150+0 records out

2. Read the next ONE block ONLY to see what comes next:

mod43 57 # dd if=/dev/nrst0 bs=10240 count=1 of=t1151
0+1 records in
0+1 records out

There's the expected partial block. The next read
should return EOF.

3. Read the next ONE block ONLY to see what comes next:

mod43 58 # dd if=/dev/nrst0 bs=10240 count=1 of=t1152
1+0 records in
1+0 records out

Instead of EOF, a full 10,240-byte block was returned
by the driver.

4. Try another read to see what happens:

mod43 59 # dd if=/dev/nrst0 bs=10240 count=1 of=t1153
0+0 records in
0+0 records out

THERE's the previously-expected EOF now.

What we have now are the following files:

-rw-r--r-- 1 root 11794944 Feb 11 21:57 DLT.tap
-rw-r--r-- 1 root 11784704 Feb 11 21:58 kernel.tar
-rw-r--r-- 1 root 11776000 Feb 11 22:05 t1-1150
-rw-r--r-- 1 root 8704 Feb 11 22:07 t1151
-rw-r--r-- 1 root 10240 Feb 11 22:07 t1152
-rw-r--r-- 1 root 0 Feb 11 22:07 t1153

Files t1-1150 and t1151 concatenated together compare exactly
to kernel.tar. So blocks returned by the driver up to and
including the second-to-last block are correct. The very last
block returned, when EOF should have been returned, is a full
block of data that the driver sent back when EOF was encountered
on tape. It's not until another subsequent read, from that point,
is an EOF returned.

The problem could be in the adaptec.c base SCSI driver, or in the
st.c SCSI Tape code. Both contain code specific to Tapes. adaptec.c
contains the kernel/Driver BTE and b_resid determinations. The st.c
also contains some data transfer to the device as well.

A few printf's will help debug this issue. Since it occurs, without
fail [pun], on all tested tape drives (both fixed and variable
block devices), it should be easy to determine the fault. My
suspicion is the logic for handling the EOF and/or short-read
tape blocks is where the bug lies. Fortunately, tape drivers
are no stranger to me.

  • You are here:  
  • Home