Disabling SCSI parity checking to dump disk on ACB4000 MFM-SCSI adapter?

Michael Engel 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 
>> 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 

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

More information about the cctech mailing list