Re: MicroVAX 3100-40 -> asc0: !TC on DATA XFER

Darren Clark <[email protected]> Thu, 15 Mar 2012 23:04:20 -0400
Newsgroups gmane.os.openbsd.vax
Message-ID <[email protected]>
Looking into the CHS/LBA issue; the BIOS on the MicroVAX 3100-40 
supports large drives (1997 standard of large) to around 9GB. Anything 
higher doesn't work nice with the BIOS, so they can't be a boot or 
sysdump (in VMS) drive. Once OpenBSD is booted the kernel driver 
properly address the whole drive (48 bit or higher LBA I'm guessing).

I got the same error with the 136GB drives ejected (all the drives are 
in a StorageWorks BA350 enclosure, only the CD-ROM and TZ30 are in the 
MicroVAX).

node2# dd if=/dev/cd0a bs=512 of=/dev/nul
Mar 15 21:34:56 node2 /bsd: asc0: !TC on DATA XFER [intr 10, stat 83, 
step 4] prevphase 1, resid 800
......
Mar 15 21:34:56 node2 /bsd: asc0: !TC on DATA XFER [intr 10, stat 83, 
step 4] prevphase 1, resid 800
Mar 15 21:35:00 node2 /bsd: last message repeated 58 times
^C230+0 records in
230+0 records out
117760 bytes transferred in 4.079 secs (28863 bytes/sec)

This is the same for burned CD's and factory CD's. So it is spinning up 
and getting something.

 >>(again, would like to dump the registers to get the state). VMS 
typically
 >>has pretty long device IO timeouts so it can cope with sillyness like my
 >>RL02's so it's often more tolerant.

Do you have any pointers on how to read the registers on the SCSI chip? 
I haven't traveled this deep into OpenBSD before.
Also, RL02! Lucky you! I've been looking for one for a while for my 
11/23. Also been looking for a 9 track tape drive (working or not).


I'm trying to track down some other SCSI CD-ROM drives and try them out, 
but they're hard to come by these days. The only ones I have are out of 
HP B180's, and I have them in various AlphaServer 1000A's and 
AlphaStation 4/266's


Darren






On 03.13.2012 3:38 AM, ..I'd rather be coding ASM! wrote:
>
>
> Darren,
>
> A couple of qucick observations,
>
> 1) If it's out of a B180 then it definitely does the 512byte sector 
> size (not all SCSI cd drives do). That's good.
>
> 2) You may have some addressing problems with the 146gb cheetah's. 
> Note the NUMBYTES col from SARGE after it's crapped out doing the CHS 
> calculation. This is probably unrelated to this issue though.
>
> 3) I have a xm5401. They're a quad-speed that found it's way into 
> sgi's O2's and a fair few sun boxes. They have trouble reading some 
> home-burnt CD's, especially if burnt at >16x. Perhaps it's just my 
> drive but it really is not reliable if using homeburnt 700mb discs.
>
> I sadly found out the hard way with mine that burning at >16x setting 
> on my drive causes this thing to rarely pick it up. It may be timing 
> out attempting to read the disk and the 53c94 under obsd has the 
> timeout set too short (again, would like to dump the registers to get 
> the state). VMS typically has pretty long device IO timeouts so it can 
> cope with sillyness like my RL02's so it's often more tolerant.
>
> A good test, would be to find a "new" shop pressed CDROM disc, that is 
> no larger than 640mb. Boot OpenBSD and try to dd the raw device and 
> redirect it's output to /dev/null so your not hitting disks repeatedly 
> on this CD.
> See if it has timeouts, and keep an eye on it's behaviour when it is 
> having them (ie is it spinning up/down/etc). Shake-stir-repeat with 
> the install CD that has troubles.
>
> Al.

[demime 1.01d removed an attachment of type APPLICATION/DEFANGED which had a name of BiggRanger.7646DEFANGED-vcf]