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

Camiel Vanderhoeven camiel at vaxbarn.com
Thu Sep 24 11:25:22 CDT 2020


> On Sep 24, 2020, at 6:21 PM, Camiel Vanderhoeven via cctalk <cctalk at classiccmp.org> wrote:
> 
> 
> 
> 
> 
>> On Sep 24, 2020, at 5:23 PM, Grant Taylor via cctalk <cctalk at classiccmp.org> wrote:
>> 
>> On 9/24/20 1:12 AM, Camiel Vanderhoeven via cctalk wrote:
>>> I used an Ancot Ultra2080/Lite SCSI-bus Analyzer. This is a device that connects to a SCSI bus and has a serial port. Over the serial port, you can monitor the signals on the SCSI bus, and use it as a SCSI protocol analyzer. There’s also the possibility to construct and send a SCSI command. Rather than connect a serial terminal to the serial port, I connected a PC, then wrote a C program to control the Ancot. I had the Ancot send commands to the disk to read a sector at a time, and recorded the data sent in response to a file to create a disk image. Slow as hell (each byte on the disk requires sending two hex characters and a space over a slow serial line), but it works. I had to make several passes over the disk, because occasionally the data received from the disk turned out to be data from a different sector than the one I was trying to read. By reading the disk multiple times, I could get rid of these mis-read sectors.
>> 
>> Very NICE hack Camiel.  I like it!
>> 
>> I am a little surprised by getting different data for the same sectors. I find that mildly concerning.  Did you do something like read each byte multiple times to find a majority sample?  2/3, 3/5, 4/6, etc?  Do you think the different data was an artifact of the old drive?  Or was it a tickle of a bug elsewhere in the chain?
> 
> 
> The drive was what seems to be a pre-production Fujitsu model (with a serial number of 37), 17MB in size; I’m pretty sure the disk itself had issues. On the first pass of reading the disk, about 8% of all sectors wouldn’t read, returning an “Unrecoverable Read Error”; when I did a second pass reading just these failed sectors, I found that I could read about 2/3rds of them. I repeated this 20 times or so, and then I had almost everything. There were 43 sectors near the end of the disk that I never managed to read, but these were beyond the filesystems on the disk. That gave me a disk that would boot, but I has some corrupt files and a corrupt directory. Looking at these, I found that the corrupt bits were sector-sized, and were identical copies of sectors elsewhere on the disk.
> 
> In the end, what I ended up doing was read the entire disk 2 more times (so two more times the 20 iterations of reading the missing sectors until I had a complete image), and compared the resulting three disk images sector-by-sector. For some 99% of the sectors, all three copies were in agreement; where they were not, there were always two images in agreement, so I knew which one to pick.
> 
> I’ve documented some of this here:
> 
> https://www.vaxbarn.com/index.php/42-repair/577-convex-c1-xp-power-on <https://www.vaxbarn.com/index.php/42-repair/577-convex-c1-xp-power-on> <https://www.vaxbarn.com/index.php/42-repair/577-convex-c1-xp-power-on <https://www.vaxbarn.com/index.php/42-repair/577-convex-c1-xp-power-on>>
> 
> https://www.vaxbarn.com/index.php/42-repair/579-getting-a-convex-c1-to-pass-all-diagnostics <https://www.vaxbarn.com/index.php/42-repair/579-getting-a-convex-c1-to-pass-all-diagnostics> <https://www.vaxbarn.com/index.php/42-repair/579-getting-a-convex-c1-to-pass-all-diagnostics%5C <https://www.vaxbarn.com/index.php/42-repair/579-getting-a-convex-c1-to-pass-all-diagnostics%5C>>

Oh, I was lucky when I spotted it; the first corrupt file I encountered was part of the microcode to be loaded onto the vector processor. Those files have checksums, and the microcode loader complained. I wrote a small utility to extract the files from the disk image (it uses a variant of the UFS file system), and had a look at the corrupt file; one of the blocks in the file looked like part of a directory, which was easy to spot, and that led me to the conclusion that it was valid data, but read from the wrong place.

Camiel



More information about the cctech mailing list