Disabling SCSI parity checking to dump disk on ACB4000 MFM-SCSI adapter?
engel at multicores.org
Sat Sep 26 10:32:53 CDT 2020
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
> 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
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.
More information about the cctech