On 9/26/20 5:22 AM, Grant Taylor via cctalk wrote:
On 9/25/20 10:38 AM, Glen Slick via cctalk wrote:
If the Adaptec 2940 BIOS seems to detect the disk I wonder what would
happen if DOS was set up on the system and ASPI8DOS.SYS was loaded.
Would the Adaptec 2940 and ASPI driver respect the BIOS parity
setting and interact with the ACB4000 bridge well enough for a fairly
simple DOS program to be able to use the ASPI interface to send READ
CDBs to read the sectors from the device? If I had such a device
myself to experiment with I'd probably give that a try to see if it
works.
If it would work, I wonder if you could then use something like Ghost
to copy the drive to an image or another more standard drive that
could then more easily be worked with
Using DOS might be another option, I seem to hit a roadblock with every
Unix version I try...
After quite a bit experimenting it seems that older Linux kernels (down
to 2.2, I´m not sure if earlier kernels would support the Pentium 4 I
have here) don´t seem to make a difference, Linux doesn´t talk to the
disk via the Adaptec 2940 and complains about parity errors.
So I tried another idea from this thread - using a SunOS 4 machine. I
set up a Sparcstation LX for netbooting SunOS 4.1.4 and it discovers the
disk (typed in from the screen, I didn´t think of setting up a serial
console):
sd3: non-CCS device found at target 0 lun 0 on esp0
sd3: at esp0 target 0 lun 0
sd3: corrupt label - wrong magic number
sd3: Vendor ´ADAPTEC*´, product ´ACB4000*********´, 181520 512 byte blocks
The corrupt label is expected and the vendor and product name as well as
the disk size seem to be discovered correctly. However, when I try to
dump the disk, I get the following error message:
# dd if=/dev/sd3c of=/root/foo bs=512
(same for /dev/rsd3c) SunOS complains:
dd: open: /dev/sd3c: No such device or address
The disk is jumpered to address 0, it shows as address 3 due to the
strange SCSI address renumbering of SunOS 4. Partition c should be the
"whole disk" device. When I rejumper the ACB4000 to address 3, it shows
as sd0 as expected - but I still get the same error message (with the
other disk device name shown, of course).
/dev/sd3c has major device ID 7, minor 26 (sd0c is 7/2), both were
generated with the SunOS 4 MAKEDEV script in the NFS root directory, so
they should be correct.
I can also read the internal disk just fine with dd when I connect it.
So it seems that this is a problem of a missing disk label that confuses
the SunOS SCSI driver (I seem to remember having similar problems in the
´90s with our Suns)? Maybe I have to start reading SunOS kernel code...
Btw., NetBSD (I tried 1.3.3 and 1.6.2) on the Sparc LX complains about
SCSI phase errors if the ACB4000 is attached, so that´s also probably
not an option.
-- Michael
