Re: VAXstation 4000/90 SCSI weirdness on 10 RC5

Im running a 4K90 right now. Installed RC4 (I think it was) a couple of 
weeks ago, including new boot, but didn't touch the boot block.
Now building RC5 (or are we at RC6 now?).

I've not seen any issues. But I'm sortof suspecting those disks you 
have. Do they have some power saving mode they get in to?

   Johnny

On 2024-03-22 16:57, Hans Rosenfeld wrote:
> I wanted to create a backup of my VS 4k90 root disk, and I ran into a
> whole lot of SCSI weirdness like I've never seen before. I got three IBM
> DNES-318350 disks out of storage in th hope that at least one would
> work, but that seems not to be the case.
> 
> The issues start with SCSI timeouts before the disks are even attached:
> 
> [     3.539508] (asc0:2:0): selection failed; 11 left in FIFO [intr 18, stat 93, step 3]
> [    13.539441] probe(asc0:0:2:0): asc0: timed out [ecb 0x87ec1fa8 (flags 0x1, dleft 10, stat 0)], <state 2, nexus 0x87ec1fa8, phase(l 13, c 3, p 3), resid 0, msg(q 20,o 80) >
> [    15.549440] probe(asc0:0:2:0): asc0: timed out [ecb 0x87ec1fa8 (flags 0x41, dleft 10, stat 0)], <state 2, nexus 0x87ec1fa8, phase(l 13, c 3, p 3), resid 0, msg(q 20,o 80) > AGAIN
> [    15.579450] (asc0:2:0): selection failed; 11 left in FIFO [intr 18, stat 93, step 3]
> [    16.579446] probe(asc0:0:2:0): asc0: timed out [ecb 0x87ec1fa8 (flags 0x1, dleft 4000, stat 0)], <state 2, nexus 0x87ec1fa8, phase(l 13, c 3, p 3), resid 0, msg(q 20,o 80) >
> [    18.589440] probe(asc0:0:2:0): asc0: timed out [ecb 0x87ec1fa8 (flags 0x41, dleft 4000, stat 0)], <state 2, nexus 0x87ec1fa8, phase(l 13, c 3, p 3), resid 0, msg(q 20,o 80) > AGAIN
> [    18.605122] probe(asc0:0:2:0): async, 8-bit transfers
> 
> But eventually, the disk attaches:
> 
> [    18.612879] sd1 at scsibus0 target 2 lun 0: <IBM, DNES-318350, SA30> disk fixed
> [    19.499438] sd1: 17501 MB, 11474 cyl, 10 head, 312 sec, 512 bytes/sect x 35843670 sectors
> [    19.519502] sd1: sync (160.00ns offset 15), 8-bit (6.250MB/s) transfers, tagged queueing
> 
>  From then on, I can label it, newfs it, and transfer the contents of my
> old disks by running "dump | restore". Here the oddity continues, after
> transferring /usr (approx. 10GB), the system still works, but if left
> sitting like this for a few hours it'll grind to a halt. It can still be
> pinged, but it otherwise it appears dead. Continuing transferring data
> from other filesystems sees transfer rates dropping continuously until
> it all grinds to a halt, too.
> 
> I restart the system, and everything seems to work. I can compare the
> transferred data and see everything that copied was copied correctly.
> 
> Then I install boot blocks:
> 
> # installboot /dev/rsd1c /usr/mdec/sdboot
> 
> but booting the system from the new disk, I get only this:
> 
> ?06 HLT INST
>    PC= 00002AD6 PSL= 041F0000
> 
> I'm not sure this is related to the SCSI issues I'm seeing. Has anyone
> tried doing a fresh install NetBSD/vax on a SCSI VAX recently? Is it
> possible our bootblocks suffer from bitrot?
> 
> 
> I've seen the same and some more weirdness in my 2nd 4k90 a few months
> ago, but I figured it might be an issue with the system board. Now I
> think it's more likely an issue with the IBM disks, but then it's 3 of
> them behaving oddly in exactly the same ways.  Note that I never noticed
> any SCSI related problems with the disk that's been in this box for the
> past two decades (a Seagate ST318418N).
> 
> 
> Does anyone else have a VS 4k90 (or a different model VS 4k), seeing
> similar issues?
> 
> 
> Thanks,
> 
> Hans
> 
> 
> 

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: [email protected]             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol