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

Reply via email to