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]