> On Sep 24, 2020, at 6:21 PM, Camiel Vanderhoeven via cctalk 
> <cctalk@classiccmp.org> wrote:
> 
> 
> 
> 
> 
>> On Sep 24, 2020, at 5:23 PM, Grant Taylor via cctalk <cctalk@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

Reply via email to