State of VAX port - MicroVAX 3100-40

[Darren Clark-2]

I've been running OpenBSD 5.0 on simh 3.8-1 without a problem, but can't
get it to boot on my MicroVAX 3100-40. NetBSD 5.1 does fine on the
actual hardware, so I'm convinced the hardware is fine (VMS 7.3 runs
too). I've gone through the message list, but it looks like nothing but
spam for the last few years.

Is anybody running on actual hardware anymore?
What is the state of the VAX port these days?

Darren Clark

East of East Lansing, Michigan, USA

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

[Miod Vallat]

> I've been running OpenBSD 5.0 on simh 3.8-1 without a problem, but can't
> get it to boot on my MicroVAX 3100-40.

Support for this particular model (KA45 series) was accidentally broken
a few releases ago, and was fixed shortly after 5.0 was completed.

You may want to install 5.1 when it gets released, or a current
snapshot, and these will run on your machine fine.

Miod

[Darren Clark-2]

Hello,
     Trying to install the OpenBSD 5.1 snapshot (2012.02.14) and when
the install script tries to mound the cd-rom I get the following errors:
asc0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 2000
asc0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 2000
asc0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 2000

I see this was a problem in the mips port in NetBSD a while ago.





Available disks are: sd0 sd1 sd2 sd3 sd4.
Which one is the root disk? (or 'done') [sd0]
Use DUIDs rather than device names in fstab? [yes]
The auto-allocated layout for sd0 is:
#                size           offset  fstype [fsize bsize  cpg]
   a:           902.8M               16  4.2BSD   2048 16384    1 # /
   b:           256.0M          1848928    swap
   c:          4091.8M                0  unused
   d:          2503.5M          2373216  4.2BSD   2048 16384    1 # /usr
   e:           429.5M          7500448  4.2BSD   2048 16384    1 # /home
Use (A)uto layout, (E)dit auto layout, or create (C)ustom layout? [a]
/dev/rsd0a: 902.8MB in 1848912 sectors of 512 bytes
5 cylinder groups of 202.47MB, 12958 blocks, 25984 inodes each
/dev/rsd0e: 429.5MB in 879616 sectors of 512 bytes
4 cylinder groups of 107.38MB, 6872 blocks, 13824 inodes each
/dev/rsd0d: 2503.5MB in 5127232 sectors of 512 bytes
13 cylinder groups of 202.47MB, 12958 blocks, 25984 inodes each
Available disks are: sd1 sd2 sd3 sd4.
Which one do you wish to initialize? (or 'done') [done]
/dev/sd0a on /mnt type ffs (rw, asynchronous, local)
/dev/sd0e on /mnt/home type ffs (rw, asynchronous, local, nodev, nosuid)
/dev/sd0d on /mnt/usr type ffs (rw, asynchronous, local, nodev)

Let's install the sets!
Location of sets? (cd disk ftp http nfs tape or 'done') [cd]
Available CD-ROMs are: cd0.
Which one contains the install media? (or 'done') [cd0]
asc0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 2000
asc0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 2000
asc0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 2000
mount_ffs: /dev/cd0a on /mnt2: Invalid argument
Location of sets? (cd disk ftp http nfs tape or 'done') [cd] ^C

#

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

[Miod Vallat]

> Hello,
>      Trying to install the OpenBSD 5.1 snapshot (2012.02.14) and when
> the install script tries to mound the cd-rom I get the following errors:
> asc0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 2000
> asc0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 2000
> asc0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 2000

It's been a _VERY_ long time since I last saw those messages (as in,
more than ten years). I'll try to hook up a cdrom drive to my 3100-30
soon and see if I can reproduce this, and investigate.

In the meantime I'd suggest getting the sets from the network as a
workaround.

Miod

[..I'd rather be coding ASM!]

G'day Darren & Miod,

I've had something similar recently off a nbsd/pmax machine with parity
enabled. Swapped drives, went away. Mostly seemed to be the scsi dvd out
of an old sun 280R that was giving it gas. Seems exceptionally happy
though on a 4000-m90 running VMS though.

My other suspicion was that it wasn't spinning up in time and there was
some kind of time-out. Given that the drive is the equiv of a 38x spin.

Worth dropping to db> and dropping the registers off the ncr 53c94 next
time it's grumpy? Do other devices function as advertised on the tin on
the same chain?

Al.

--
  --
  Al Boyanich
  adb -w -P "world> " -k /dev/meta/galaxy/ksyms /dev/god/brain


On Mon, 12 Mar 2012, Miod Vallat wrote:

>> Hello,
>>      Trying to install the OpenBSD 5.1 snapshot (2012.02.14) and when
>> the install script tries to mound the cd-rom I get the following errors:
>> asc0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 2000
>> asc0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 2000
>> asc0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 2000
>
> It's been a _VERY_ long time since I last saw those messages (as in,
> more than ten years). I'll try to hook up a cdrom drive to my 3100-30
> soon and see if I can reproduce this, and investigate.
>
> In the meantime I'd suggest getting the sets from the network as a
> workaround.
>
> Miod

[Darren Clark-2]

Hello Miod and Al,
      I have OpenBSD 5.1 Snapshot running on it now (via network load).
I still have the same error when mounting the CD-ROM. The CD-ROM is from
a HP B180 workstation, it works fine with VMS6.2 and 7.3 so I know it is
a 512 byte block drive and parity is enabled (or else it will not work
at all).
     The VAX does boot the OpenBSD install off the drive, so I'm
assuming the BIOS driver is reading it and moving the installer stuff to
memory just fine.

      I tried some other CD-ROM drives I have floating around, but they
are all too modern to work on the VAX.




KA45-A V1.4-38D-V4.2
08-00-2B-BB-98-22
32MB

   VMS/VMB      ADDR      DEVTYPE    NUMBYTES     RM/FX    WP    
DEVNAM      REV
   -------      ----      -------    --------     -----    --    
------      ---
   ESA0         08-00-2B-BB-98-22
   DKA0         A/0/0     RODISK     297.37MB      RM      WP    
CD-ROM      3605
   MKA100       A/1/0     TAPE                     RM            
TZ30        010F
   DKA200       A/2/0     DISK         4.29GB      FX            
RZ1CF-C     1614
   DKA300       A/3/0     DISK         4.29GB      FX            
RZ1CF-C     1614
   DKA400       A/4/0     DISK       786.84MB      FX            
ST31468     HPS4
   DKA500       A/5/0     DISK       786.84MB      FX            
ST31468     HPS4
   DKA600       A/6/0     DISK       786.84MB      FX            
MAP3147     HPF6
  ..HostID..    A/7       INITR



DEVNBR    DEVNAM           INFO
------    --------    --------------------------
      1         NVR    OK
      3          DZ    OK
      4       CACHE    OK
      5         MEM    OK
                       32MB = SY=8MB, S0/1=8MB, S2/3=8MB, S4/5=8MB
      6         FPU    OK
      7          IT    OK
      8         SYS    OK
      9          NI    ?? 001 0172
     10        SCSI    OK
                       0-L0-CD-ROM  1-L0-TZ30    2-L0-RZ1CF-C 3-L0-RZ1CF-C
                       4-L0-ST31468 5-L0-ST31468 6-L0-MAP3147 7-INITR
     14       ASYNC    OK
                       DHW41/2 V1.6


         MEM_TOP = 02000000
         MEM_BOT = 00000000

           MEM_NOT_AVAIL
         -----------------
         01FC0400:01FFFFFF


 >>> b

   -DKA200


 >> OpenBSD/vax boot [1.16] <<
 >> Press enter to autoboot now, or any other key to abort:  543210
 > boot bsd

changing bootrpb.unit from 200 to 2
[ using 284815 bytes of bsd a.out symbol table ]
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California.  All rights reserved.
Copyright (c) 1995-2012 OpenBSD. All rights reserved.  
http://www.OpenBSD.org

OpenBSD 5.1 (GENERIC) #46: Tue Feb 14 12:17:31 MST 2012

     [hidden email]:/usr/src/sys/arch/vax/compile/GENERIC

MicroVAX 3100/m{30,40} [14000006 04140001]
cpu: KA45
real mem = 33292288 (31MB)
avail mem = 28729344 (27MB)
mainbus0 at root
vsbus0 at mainbus0
vsbus0: 32K entry DMA SGMAP at PA 0x540000 (VA 0x80540000)
vsbus0: interrupt mask 0
dz0 at vsbus0 csr 0x200a0000 vec 84 ipl 15 maskbit 4: console, 4 lines
asc0 at vsbus0 csr 0x200c0080 vec 508 ipl 15 maskbit 0: NCR53C94, 25MHz
scsibus0 at asc0: 8 targets, initiator 7
cd0 at scsibus0 targ 0 lun 0: <TOSHIBA, CD-ROM XM-5401TA, 3605> SCSI2
5/cdrom removable
st0 at scsibus0 targ 1 lun 0: <, , > SCSI1 1/sequential removable
sd0 at scsibus0 targ 2 lun 0: <DEC, RZ1CF-CF (C) DEC, 1614> SCSI2
0/direct fixed eui.0000000000000000
sd0: 4091MB, 512 bytes/sector, 8380080 sectors
sd1 at scsibus0 targ 3 lun 0: <DEC, RZ1CF-CF (C) DEC, 1614> SCSI2
0/direct fixed eui.0000000000000000
sd1: 4091MB, 512 bytes/sector, 8380080 sectors
sd2 at scsibus0 targ 4 lun 0: <SEAGATE, ST3146807LW, HPS4> SCSI3
0/direct fixed serial.SEAGATE_ST3146807LW_3HY8520C00007442A89E
sd2: 140014MB, 512 bytes/sector, 286749488 sectors
sd3 at scsibus0 targ 5 lun 0: <SEAGATE, ST3146807LW, HPS4> SCSI3
0/direct fixed serial.SEAGATE_ST3146807LW_3HY8289300007442B3AT
sd3: 140014MB, 512 bytes/sector, 286749488 sectors
sd4 at scsibus0 targ 6 lun 0: <FUJITSU, MAP3147NP, HPF6> SCSI3 0/direct
fixed eui.00000e110063cb25
sd4: 140014MB, 512 bytes/sector, 286749488 sectors
le0 at vsbus0 csr 0x200e0000 vec 504 ipl 15 maskbit 1 buf 0x0-0xffff
le0: address 08:00:2b:bb:98:22
le0: 32 receive buffers, 8 transmit buffers
led0 at mainbus0
vscsi0 at root
scsibus1 at vscsi0: 256 targets
softraid0 at root
scsibus2 at softraid0: 256 targets
boot device: sd0
root on sd0a (d5e40a24f724c7bf.a) swap on sd0b dump on sd0b
Automatic boot in progress: starting file system checks.
/dev/sd0a (d5e40a24f724c7bf.a): file system is clean; not checking
/dev/sd0e (d5e40a24f724c7bf.e): file system is clean; not checking
/dev/sd0d (d5e40a24f724c7bf.d): file system is clean; not checking
setting tty flags



On 03.12.2012 5:08 PM, ..I'd rather be coding ASM! wrote:

> G'day Darren & Miod,
>
> I've had something similar recently off a nbsd/pmax machine with
> parity enabled. Swapped drives, went away. Mostly seemed to be the
> scsi dvd out of an old sun 280R that was giving it gas. Seems
> exceptionally happy though on a 4000-m90 running VMS though.
>
> My other suspicion was that it wasn't spinning up in time and there
> was some kind of time-out. Given that the drive is the equiv of a 38x
> spin.
>
> Worth dropping to db> and dropping the registers off the ncr 53c94
> next time it's grumpy? Do other devices function as advertised on the
> tin on the same chain?
>
> Al.
>
> --
>  --
>  Al Boyanich
>  adb -w -P "world> " -k /dev/meta/galaxy/ksyms /dev/god/brain
>
>
> On Mon, 12 Mar 2012, Miod Vallat wrote:
>
>>> Hello,
>>>      Trying to install the OpenBSD 5.1 snapshot (2012.02.14) and when
>>> the install script tries to mound the cd-rom I get the following
>>> errors:
>>> asc0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid
>>> 2000
>>> asc0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid
>>> 2000
>>> asc0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid
>>> 2000
>>
>> It's been a _VERY_ long time since I last saw those messages (as in,
>> more than ten years). I'll try to hook up a cdrom drive to my 3100-30
>> soon and see if I can reproduce this, and investigate.
>>
>> In the meantime I'd suggest getting the sets from the network as a
>> workaround.
>>
>> Miod

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

[..I'd rather be coding ASM!]

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.


--
  --
  Al Boyanich
  adb -w -P "world> " -k /dev/meta/galaxy/ksyms /dev/god/brain

[Darren Clark-2]

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]