Re: [Simh] Tun/Tap in Mint for RSX-11M Plus 4.6 running in SimH PDP11
For my recent VAX installation on windows I used NAT and initially tested using an ethernet connection. I cannot telnet in but most outbound connections work. At least eliminate one area of possible trouble by using a wired connection for initial testing. On Sun, Jun 23, 2019, 9:07 PM Will Senn wrote: > This question may best be asked elsewhere but I'm struggling to make it > work with SimH, so here it is :) > > tldr; How can I get tun/tap working with Mint 19 and SimH RSX-11M Plus > 4.6 so that I can access the internet from the instance and telnet to it > from another machine on the network? > > Here's the background... I am trying to get RSX-11M Plus 4.6 working in > SimH with networking on my Mint 19.1 T430 Thinkpad and it's proving > difficult (both in execution and understanding). I've tried this tap > stuff before and remember being uber frustrated then, too. But now, I > know way more about stuff then I did back then. > > System: T430 ThinkPad w/16GB Ram, SSD's, 1600x screen. > > OS: Linux Mint 19.1 (debian/ubuntu derivative). > > Software: SimH built with: make USE_READER_THREAD=1 USE_TAP_NETWORK=1 > USE_INT64=1 vax vax780 pdp11 pdp8 > > What I'm trying to do: Get my RSX-11M talking to the internet and be > able to telnet into it, preferably from another laptop on the network. > > What I've tried: followed a gist by Upi Temminen for getting it running > on a pi: > > https://gist.github.com/desaster/c49b0f7afa5e061b8f33f159e521b6ee > > After installing parprouted, uml-utilities, tunctl, and simh as > described, did the following: > > /etc/sysctl.conf > net.ipv4.conf.all.proxy_arp=1 > net.ipv4.ip_forward=1 > > sudo vi /etc/network/interfaces.d/tap > auto tap-simh0 > iface tap-simh0 inet manual > pre-up tunctl -t tap-simh0 -u simhuser > up ip link set tap-simh0 up > up /usr/sbin/parprouted wlp3s0 tap-simh0 > up /sbin/ip link set wlp3s0 promisc on > post-down ip link set tap-simh0 down > post-down tunctl -d tap-simh0 > > auto tap-simh1 > iface tap-simh1 inet manual > pre-up tunctl -t tap-simh1 -u simhuser > up ip link set tap-simh1 up > up /usr/sbin/parprouted wlp3s0 tap-simh1 > up /sbin/ip link set wlp3s0 promisc on > post-down ip link set tap-simh1 down > post-down tunctl -d tap-simh1 > > rebooted > > used oscar's boot.ini, but with this section for ethernet: > > ; Ethernet > set xu enable > set xu type=deuna > set xu mac=aa:00:04:00:0c:34 > attach xu tap:tap-simh0 > sho xu > > which resulted in: > > PDP-11 simulator V4.0-0 Currentgit commit id: b3fa1f9f > Disabling XQ > /opt/pidp11/systems/rsx11mplus/boot.ini-16> attach xu tap:tap-simh0 > libpcap version 1.8.1 > Eth: opened OS device tap-simh0 > XUaddress=17774510-17774517, vector=120, BR5, MAC=AA:00:04:00:0C:34 > type=DEUNA, throttle=disabled > attached to tap:tap-simh0 > CPU11/70, FPP, RH70, autoconfiguration enabled, idle disabled > 4088KB > RQ0: 'PiDP11_DU0.dsk' Contains an ODS1 File system > RQ0: Volume Name: RSX11MPBL87 Format: DECFILE11A Sectors In Volume: > 615000 > /opt/pidp11/systems/rsx11mplus/boot.ini-35> attach rq1 PiDP11_DU1.dsk > RQ1: creating new file > /opt/pidp11/systems/rsx11mplus/boot.ini-45> attach dz 10001 > Listening on port 10001 > DZaddress=17760030-17760037*, vector=330-334*, BR5, lines=8 > attached to 10001, 8b, 0 current connections > > RSX-11M-PLUS V4.6 BL87 1920.KW System:"PIDP11" > > ...snip > >; INSTALL TCP/IP > >; > >SET /NAMED > >SET /UIC=[1,2] > >* Load TCP/IP? [Y/N D:Y T:15S]: > >load if:/vec/high > >load ip:/vec/high > >load ud:/vec/high > >load tc:/vec/high > LOA -- Warning - loadable driver larger than 4K > >con onl if0: > >con onl if1: > >con onl ip: > >con onl ud: > >con onl tc: > >ins lb:[ip]ethacp/fmap=yes > >ins lb:[ip]ifconfig > >ins lb:[ip]netstat > >ins lb:[ip]ping > >ins lb:[ip]tracert > >ins lb:[ip]resacp > >dfl "Frodo"=HOSTNAME/GBL > >dfl "LOGICAL,DNS,FILE"=RESOLV$ORDER/GBL > >dfl LB:[1,2]HOSTS.TXT=HOSTS/GBL > >dfl "LOGICAL,FILE"=RESOLV$ORDER > >ifc create 256 > >ifc start > Starting IP. > Starting UD. > Starting TC. > >ifc set if0: dhcp acp ethacp lin UNA-0 > >dfl ",RTR,DNS,DOM"="DHCP$IF0"/gbl > >;.ifins if0 can if0 > >ins lb:[ip]dhcp > >run dhcp > >ifc set if1: add localhost > 09:30:21 TCP/IP - ethernet ACP using DECnet DLX > 09:30:21 Starting resolver V2.2 > >ifc set if1: sta ope > > DHCP - Failed to find any DHCP servers. Giving up... > > which explains why this don't work: > > > >PING GOOGLE.COM > Unknown host: GOOGLE.COM > > ...snip > > if I: > > ip link show > > ... > > 4: tap-simh0: mtu 1500 qdisc fq_codel > state UP mode DEFAULT group default qlen 1000 > link/ether 22:f2:0d:23:2d:63 brd ff:ff:ff:ff:ff:ff > > To my untrained eye, it would appear that tap-simh0 isn't getting an ip > address :). > > Help?! > > Thanks, > > Will > > -- > GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF > >
Re: [Simh] Limits on MSCP controllers
On Sunday, June 23, 2019 at 4:51 PM, Jonathan Welch wrote: > The system that I set up for myself and for my friend (who needs one more > disk than I do) was cloned from a VMS Cluster that has been in continuous > operation in its present form for about 20 years, so the issue is not with > mounting disks too early in the startup sequence. > > Not that this helps much but as we were trying to figure out how long of a > WAIT statement to use we put in a $ SHOW SYSTEM and the CONFIGURE > process' state was HIB. The timing of startup behavior will certainly be very different under today's simulators vs the original hardware on the systems in question. Depending on the speed of original hardware and what host system you're running on there may indeed be different timing behaviors, especially for activities which occur asynchronously. - Mark ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Limits on MSCP controllers
On 23-Jun-19 20:01, Johnny Billquist wrote: > > Timothe Litt clearly knows this better than I do. His mention of the > attention message jogged my memory a bit. There are just notifications > going the other way about available disks. And ports are not really > relevant. In RSX, they are then obviously matched against what you > configured in your SYSGEN. Disks which do not match any configured > device are just going to be ignored. No dynamic adding of disks > possible. And unit numbers can be totally unrelated between one > controller and the next, and have nothing to do with the device > numbering inside RSX. So DU5: can map to unit #42 on the third > controller. RSX will happily do that mapping. > MSCP is basically an evolution of the Massbus protocol, on a different PHY, and informed by the TOPS-10/20 experiences with high-end (large, redundant, on-line serviceable) configurations. The attention messages are analogous to the attention summary register bits on a Massbus. Although intended to be scalable, the design was driven by the initial implementations, which were the HSC50 (with the SDI/STI PHY). Later, we benchmarked configurations with 100s of disks - which required many racks and long SDI cables. TMSCP design lagged MSCP - with the required allowances for tapes - again using the Massbus model at the PHY (one port connecting to a formatter that could have multiple drives. But a lot of the Massbus ugliness is abstracted away from the OS. In VMS (and the TOPS-10/20 CI implementations), attention messages can materialize units on the fly. The IO working group that defined (T)MSCP expected all configuration to work this way. In retrospect, it would have been better for the OS if the controller could provide a bitmap of what units are present on a controller. But SDI/STI (they're the same phy) were designed for hotplug and for sequenced power-on. There is no "drive present" wire - you have to ask a drive to do something in order to determine if something is plugged in. So the controller can't know - unless it were to poll its ports. As Mark pointed out, VMS stand-alone backup does try to enumerate all the devices - which takes forever and a day. Besides the time it takes to spin up a disk to determine its geometry (or time out if a port is empty), there are a limited number of credits (outstanding command buffers) available in the controllers. So sending ~64K "get unit status" commands to each controller is a painfully slow process - and frustrating where there are often only 1-4 units on each controller. For scale, consider that a 4-XMI system using just KDM70s could have 23 KDMs to poll; a CI system could have 31 HSCs, and an LAVC - well, lots. RSX (and IIRC RT) statically configure configure MSCP disks as Johnny describes. This is only practical for the relatively small configurations that they support. I doubt that the unit attention messages are completely ignored; though not used for configuration, they also tell the OS when a disk has spun up (or down) based on an operator pushing the 'online' button. This is especially true for removable media (e.g. RA60), but also applies to RA8x/9x. And the case of an operator switching unit plugs on a drive. (Humans do the strangest things...) After the UDA/KDB50s, U/Q (T)MSCP devices moved away from the SDI/STI interface - but that's transparent to the OS. For the low end, there was no need for the hotplug or distances supported by the SDI/STI interfaces. And of course, much later the HSCs supported SCSI disk and tape. And the HSD/HSZ controllers. I wasn't involved in those, so I don't remember their configuration limits. > And by the way, if the goal of simh was to try and act just like > existing hardware, then you should not be allowed to have more than > one tape drive per tmscp controller, since that was the way of all DEC > tmscp controllers. Be careful about saying "all". The UQ TMSCP-only controllers bundled with the TxK[5,7] are one drive/controller. But that is not the universe of TMSCP controllers. The HSC50/60/70 support multiple drives per controller (and per K.STI) e.g. the TA78/79). The HSC50 predates the T[UQ]K50. The KDM70 on the XMI backplane, previously mentioned, supports up to 2 active STI ports, each of which can have a formatter (subcontroller) with multiple drives. > But tmscp itself also certainly do not have such a limitation, and in > this case simh do deviate from what the real hardware did. One TQK50 > (or TUK50) per TK50, and so on... > SimH has always started with what real hardware does as its design principle. However, it doesn't implement all of the real hardware. People have software that ran on systems that had more hardware than the implemented devices support. So it does bend configuration rules from time to time. This is important in cases where SimH implements low-end models, but people have disk images from large configurations of high-end models. The RAUSER
Re: [Simh] Tun/Tap in Mint for RSX-11M Plus 4.6 running in SimH PDP11
On Sunday, June 23, 2019 at 6:07 PM, Will Senn wrote: > This question may best be asked elsewhere but I'm struggling to make it work > with SimH, so here it is :) > > tldr; How can I get tun/tap working with Mint 19 and SimH RSX-11M Plus > 4.6 so that I can access the internet from the instance and telnet to it from > another machine on the network? Use NAT networking to do this. > Here's the background... I am trying to get RSX-11M Plus 4.6 working in SimH > with networking on my Mint 19.1 T430 Thinkpad and it's proving difficult (both > in execution and understanding). I've tried this tap stuff before and remember > being uber frustrated then, too. But now, I know way more about stuff then I > did back then. > > System: T430 ThinkPad w/16GB Ram, SSD's, 1600x screen. > > OS: Linux Mint 19.1 (debian/ubuntu derivative). > > Software: SimH built with: make USE_READER_THREAD=1 > USE_TAP_NETWORK=1 > USE_INT64=1 vax vax780 pdp11 pdp8 You should not need to pass any extra make arguments to use any particular form of networking. $ make vax vax780 pdp11 pdp8 This will do the right thing to build network capable simulators that can use either tap or NAT networking. > What I'm trying to do: Get my RSX-11M talking to the internet and be able to > telnet into it, preferably from another laptop on the network. > > What I've tried: followed a gist by Upi Temminen for getting it running on a > pi: > > https://gist.github.com/desaster/c49b0f7afa5e061b8f33f159e521b6ee > > After installing parprouted, uml-utilities, tunctl, and simh as described, > did the > following: > > /etc/sysctl.conf > net.ipv4.conf.all.proxy_arp=1 > net.ipv4.ip_forward=1 > > sudo vi /etc/network/interfaces.d/tap > auto tap-simh0 > iface tap-simh0 inet manual > pre-up tunctl -t tap-simh0 -u simhuser > up ip link set tap-simh0 up > up /usr/sbin/parprouted wlp3s0 tap-simh0 > up /sbin/ip link set wlp3s0 promisc on > post-down ip link set tap-simh0 down > post-down tunctl -d tap-simh0 > > auto tap-simh1 > iface tap-simh1 inet manual > pre-up tunctl -t tap-simh1 -u simhuser > up ip link set tap-simh1 up > up /usr/sbin/parprouted wlp3s0 tap-simh1 > up /sbin/ip link set wlp3s0 promisc on > post-down ip link set tap-simh1 down > post-down tunctl -d tap-simh1 I'm not completely familiar with the Pi network devices, but if wlp3s0 is a WiFi interface, you will be extremely challenged and frustrated and likely never get this to work. USE NAT - Mark ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
[Simh] Tun/Tap in Mint for RSX-11M Plus 4.6 running in SimH PDP11
This question may best be asked elsewhere but I'm struggling to make it work with SimH, so here it is :) tldr; How can I get tun/tap working with Mint 19 and SimH RSX-11M Plus 4.6 so that I can access the internet from the instance and telnet to it from another machine on the network? Here's the background... I am trying to get RSX-11M Plus 4.6 working in SimH with networking on my Mint 19.1 T430 Thinkpad and it's proving difficult (both in execution and understanding). I've tried this tap stuff before and remember being uber frustrated then, too. But now, I know way more about stuff then I did back then. System: T430 ThinkPad w/16GB Ram, SSD's, 1600x screen. OS: Linux Mint 19.1 (debian/ubuntu derivative). Software: SimH built with: make USE_READER_THREAD=1 USE_TAP_NETWORK=1 USE_INT64=1 vax vax780 pdp11 pdp8 What I'm trying to do: Get my RSX-11M talking to the internet and be able to telnet into it, preferably from another laptop on the network. What I've tried: followed a gist by Upi Temminen for getting it running on a pi: https://gist.github.com/desaster/c49b0f7afa5e061b8f33f159e521b6ee After installing parprouted, uml-utilities, tunctl, and simh as described, did the following: /etc/sysctl.conf net.ipv4.conf.all.proxy_arp=1 net.ipv4.ip_forward=1 sudo vi /etc/network/interfaces.d/tap auto tap-simh0 iface tap-simh0 inet manual pre-up tunctl -t tap-simh0 -u simhuser up ip link set tap-simh0 up up /usr/sbin/parprouted wlp3s0 tap-simh0 up /sbin/ip link set wlp3s0 promisc on post-down ip link set tap-simh0 down post-down tunctl -d tap-simh0 auto tap-simh1 iface tap-simh1 inet manual pre-up tunctl -t tap-simh1 -u simhuser up ip link set tap-simh1 up up /usr/sbin/parprouted wlp3s0 tap-simh1 up /sbin/ip link set wlp3s0 promisc on post-down ip link set tap-simh1 down post-down tunctl -d tap-simh1 rebooted used oscar's boot.ini, but with this section for ethernet: ; Ethernet set xu enable set xu type=deuna set xu mac=aa:00:04:00:0c:34 attach xu tap:tap-simh0 sho xu which resulted in: PDP-11 simulator V4.0-0 Current git commit id: b3fa1f9f Disabling XQ /opt/pidp11/systems/rsx11mplus/boot.ini-16> attach xu tap:tap-simh0 libpcap version 1.8.1 Eth: opened OS device tap-simh0 XU address=17774510-17774517, vector=120, BR5, MAC=AA:00:04:00:0C:34 type=DEUNA, throttle=disabled attached to tap:tap-simh0 CPU 11/70, FPP, RH70, autoconfiguration enabled, idle disabled 4088KB RQ0: 'PiDP11_DU0.dsk' Contains an ODS1 File system RQ0: Volume Name: RSX11MPBL87 Format: DECFILE11A Sectors In Volume: 615000 /opt/pidp11/systems/rsx11mplus/boot.ini-35> attach rq1 PiDP11_DU1.dsk RQ1: creating new file /opt/pidp11/systems/rsx11mplus/boot.ini-45> attach dz 10001 Listening on port 10001 DZ address=17760030-17760037*, vector=330-334*, BR5, lines=8 attached to 10001, 8b, 0 current connections RSX-11M-PLUS V4.6 BL87 1920.KW System:"PIDP11" ...snip >; INSTALL TCP/IP >; >SET /NAMED >SET /UIC=[1,2] >* Load TCP/IP? [Y/N D:Y T:15S]: >load if:/vec/high >load ip:/vec/high >load ud:/vec/high >load tc:/vec/high LOA -- Warning - loadable driver larger than 4K >con onl if0: >con onl if1: >con onl ip: >con onl ud: >con onl tc: >ins lb:[ip]ethacp/fmap=yes >ins lb:[ip]ifconfig >ins lb:[ip]netstat >ins lb:[ip]ping >ins lb:[ip]tracert >ins lb:[ip]resacp >dfl "Frodo"=HOSTNAME/GBL >dfl "LOGICAL,DNS,FILE"=RESOLV$ORDER/GBL >dfl LB:[1,2]HOSTS.TXT=HOSTS/GBL >dfl "LOGICAL,FILE"=RESOLV$ORDER >ifc create 256 >ifc start Starting IP. Starting UD. Starting TC. >ifc set if0: dhcp acp ethacp lin UNA-0 >dfl ",RTR,DNS,DOM"="DHCP$IF0"/gbl >;.ifins if0 can if0 >ins lb:[ip]dhcp >run dhcp >ifc set if1: add localhost 09:30:21 TCP/IP - ethernet ACP using DECnet DLX 09:30:21 Starting resolver V2.2 >ifc set if1: sta ope DHCP - Failed to find any DHCP servers. Giving up... which explains why this don't work: > >PING GOOGLE.COM Unknown host: GOOGLE.COM ...snip if I: ip link show ... 4: tap-simh0: mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000 link/ether 22:f2:0d:23:2d:63 brd ff:ff:ff:ff:ff:ff To my untrained eye, it would appear that tap-simh0 isn't getting an ip address :). Help?! Thanks, Will -- GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Limits on MSCP controllers
> The KFQSA, M7769. > Bob P.S. If anybody has a rack mount DSSI enclosure they'd like to part with, let me know. All I have is the R400x, which wastes valuable floor space and doesn't go with the rack mounted uVAX... ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Limits on MSCP controllers
> Johnny Billquist wrote: >What about the DSSI controller which talks MSCP on the Qbus? > I can't remember the name of it. But I'm not > sure if that one was limited to just four disks. The KFQSA, M7769. Supports up to seven DSSI drives. I have one in a MicroVAX-III system. It's a pain to configure, but it otherwise works fine with VMS. Bob ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Limits on MSCP controllers
On 2019-06-24 01:37, Johnny Billquist wrote: On 2019-06-23 19:30, Bob Supnik wrote: If you want to extend the current RQ simulator to include third party boards (either SMD-based emulators or SCSI-based emulators), feel free to add an appropriate mode switch. I don't know what controller ID these third party boards returned, though, nor do I know how VMS determined the number of ports per controller. Those 3rd party controllers usually identifies themselves as UDA50 or KDA50, if I remember right. I can check in a day or three, when I bring my 11/93 back up running, since it has a CMD controller. Those controllers also usually lie about disk types, commonly saying that disks are RA81 or similar, no matter what capacity they have. And since software should actually query about size, and not make any assumptions based on the id a disk returns, that should also be fine. As for how to determine the number of ports, I don't know how VMS does things in general. In RSX, you tell which disks are expected to be found at which controllers when you do a SYSGEN, and you just define as many disks you want on a controller. At boot, the OS just tries to locate the disk on the controller without trying to do anything specific about which port it might be sitting on. I can go digging into more detail if you want me to. Timothe Litt clearly knows this better than I do. His mention of the attention message jogged my memory a bit. There are just notifications going the other way about available disks. And ports are not really relevant. In RSX, they are then obviously matched against what you configured in your SYSGEN. Disks which do not match any configured device are just going to be ignored. No dynamic adding of disks possible. And unit numbers can be totally unrelated between one controller and the next, and have nothing to do with the device numbering inside RSX. So DU5: can map to unit #42 on the third controller. RSX will happily do that mapping. And by the way, if the goal of simh was to try and act just like existing hardware, then you should not be allowed to have more than one tape drive per tmscp controller, since that was the way of all DEC tmscp controllers. But tmscp itself also certainly do not have such a limitation, and in this case simh do deviate from what the real hardware did. One TQK50 (or TUK50) per TK50, and so on... Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: b...@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Limits on MSCP controllers
The system that I set up for myself and for my friend (who needs one more disk than I do) was cloned from a VMS Cluster that has been in continuous operation in its present form for about 20 years, so the issue is not with mounting disks too early in the startup sequence. Not that this helps much but as we were trying to figure out how long of a WAIT statement to use we put in a $ SHOW SYSTEM and the CONFIGURE process' state was HIB. As a fun aside, this VMS installation will have its 40th birthday on July 1st and then be shut down. I wonder if there are there other sites that have been running for longer in the same location and without any major hiatus. > Agreed that it would be interesting to understand what the problem is > with VAX or VMS here, since I certainly do not observe anything similar > with a PDP-11 and RSX. ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Limits on MSCP controllers
On 2019-06-23 19:30, Bob Supnik wrote: The four ports is not arbitrary. SimH simulates actual hardware. DEC never built a backplane MSCP controller with more than four ports. I'm not entirely sure about that. What about the DSSI controller which talks MSCP on the Qbus? I can't remember the name of it. But I'm not sure if that one was limited to just four disks. Anyway, the only reason for the 4 disk limit was really just because the physical hardware only have 4 ports. If you want to extend the current RQ simulator to include third party boards (either SMD-based emulators or SCSI-based emulators), feel free to add an appropriate mode switch. I don't know what controller ID these third party boards returned, though, nor do I know how VMS determined the number of ports per controller. Those 3rd party controllers usually identifies themselves as UDA50 or KDA50, if I remember right. I can check in a day or three, when I bring my 11/93 back up running, since it has a CMD controller. Those controllers also usually lie about disk types, commonly saying that disks are RA81 or similar, no matter what capacity they have. And since software should actually query about size, and not make any assumptions based on the id a disk returns, that should also be fine. As for how to determine the number of ports, I don't know how VMS does things in general. In RSX, you tell which disks are expected to be found at which controllers when you do a SYSGEN, and you just define as many disks you want on a controller. At boot, the OS just tries to locate the disk on the controller without trying to do anything specific about which port it might be sitting on. I can go digging into more detail if you want me to. I think it would be better to understand why VMS is waiting to mount additional discs. Alternately, just create bigger discs and have fewer of them. Agreed that it would be interesting to understand what the problem is with VAX or VMS here, since I certainly do not observe anything similar with a PDP-11 and RSX. Larger disks is also always a good option. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: b...@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] VAX emulator slow to configure extra disks
On Sunday, June 23, 2019 at 6:53 AM, Johnny Billquist wrote: > I can't remember having any such issues, but then again I also can't > remember if I ever tried it with VAX. With PDP-11 it works without any > issues. > > This is, though, another slight silliness in simh. The limit to 4 disks > per controller is very artificial. The UDA50, KDA50, and maybe some > other controllers only have four actual, physical ports, which limited > them to only have four disks per controller. However, MSCP itself do not > have such a limitation, and common SCSI controllers for these machines > which use MSCP allows more than four disks on a controller, and most > software (at least RSX and VMS) also do not limit themselves to only > configure max four disks on a controller. I wish simh didn't put such > arbitrary limitations in. simh also decides on unit numbers by itself, > which could also have been nice to be able to choose. As Bob said, simh is modeling hardware that existed. It does model the bus and controller interface. As Tim mentioned, some of the hardware that is modeled did indeed allow arbitrary unit numbers (via plugs on the drive). Some 14 months ago support was added to provide per drive Unit plug values to be set. This is set via: sim> SET RQn UNIT=plug plug can be any value from 0 thru 65534. Default unit plug for each RQn is n. A few subtle changes were needed to pdp11_rq and pdp11_tq to properly allow VMS and the KA655 boot ROM to stop their scan for units when all units have been found. > On 2019-06-23 15:37, Jonathan Welch wrote: > > A vax emulator I was configuring for a friend (MicroVAX 3900 simulator > > V4.0-0 Current git commit id: ab3e07a4) needs to mount more than four > > disks. > > > > The .INI file has > > set rqb enabled > > > > and an associated attach command. > > > > In my VMS startup disks are mounted very close to the beginning of the > > boot sequence. > > > > I discovered that when the emulator starts it is necessary to put a > > $ WAIT 00:00:06 > > before mounting DUB0; the wait is necessary for the disk to appear. > > > > Is this something that is expected behavior and should be documented > > or a bug that can be fixed? As Tim mentioned, the VMS drivers are loaded in a DEC provided procedure with a "sysgen autoconfigure all" command. Once the drivers are loaded they asynchronously interact with each controller probing for available units. This is how things always have worked. If you attempt to reference a unit before it has been found, the failure you are seeing will happen. If you attempt to boot VMS standalone backup, you will see that there is a very long pause before a device list is presented and you are ultimately prompted with: Enter "YES" when all needed devices are available: This is to make sure that all devices have had time to be identified before you proceed with the backup. - Mark ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Limits on MSCP controllers
On 23-Jun-19 13:30, Bob Supnik wrote: > The four ports is not arbitrary. SimH simulates actual hardware. > DEC never built a backplane MSCP controller with more than four ports. > I think that's true for the U/Qbuses. However, the KDM70 (XMI, last I knew not emulated by SimH) has eight universal ports - any mix of SDI/STI (disk/tape) that you can plug in. Officially, max of 2 STI, 8 SDI. Note that what plugs into STI is a formatter - each of which might have 4 drives behind it. Unit numbers are assigned by the drive - IIRC 12 bits for disk, 4 decimal digits for tape (due to bcd encoding of the unit select switches). This is slightly simplified - SSDs have different rules, and some tapes formatters support less than 4 drives. Those are KDM70 architectural limits - MSCP might be up to 16 bits, but I don't have a spec handy. There might be some flag bits in the field. (I was somewhat involved in the KDM70 development.) > If you want to extend the current RQ simulator to include third party > boards (either SMD-based emulators or SCSI-based emulators), feel free > to add an appropriate mode switch. I don't know what controller ID > these third party boards returned, though, nor do I know how VMS > determined the number of ports per controller. > (T)MSCP doesn't deal with ports; it deals with (logical) units.[1] I don't remember an efficient mechanism to enumerate the units; IIRC, you simply wait for an attention message with "Unit Available". You could also try a "get unit status" for each possible LUN - but that's a very large number, especially in a large configuration -- e.g. a CI with lots of HSC controllers, or even lots of NI workstations with MSCP-served disks. STAR had over 200 NI satellites at one point. As noted, the LUNs are arbitrary - for the larger disks, set by a plug on the drive. No requirement for starting at zero, or sequential numbers. (Of course, you can't use the same LUN on the same controller more than once.) VMS enumerates controllers to assign a letter, and uses the LUN from the attention message to build the UDB[2] and record the unit number. (Allocation classes, used to link dual-ported drives) would be a prefix). So, if the 4th controller has a single RA81 with a unit plug of 251, the device name would be _DUD251:. If in allocation class 18, _$18$DUD251:. Units can come/go/morph if, for example, the unit plug is removed or swapped, which is why "mount verification" exists. I don't remember whether VMS will try to set a unit on-line if it hasn't received a unit available first. But I believe that it won't try anything if it hasn't found the controller. The controllers (except for the boot device) are found by running sysgen autoconfig all in one of the DEC-supplied startup scripts. This is towards the middle of the process - it takes quite a while in large configs, so the startup initiates a bunch of other stuff that can overlap it first. There are several callouts in the startup scripts - it's important that disk mounts be after sysgen is run. sylogicals(-v5).com would be too soon. > I think it would be better to understand why VMS is waiting to mount > additional discs. Alternately, just create bigger discs and have fewer > of them. > One thing to check is that the unit available (attention) messages are sent at the right times. The other is where in the startup the mounts are placed. The site-specific startup - systartup(_v5).com, or something called by it should be OK. [the _v5 suffix was introduced with VMS V5 because things like device naming changed, it was removed many releases later]. [1] This caused some pain with devices that shared a resource across units - e.g. the RC25 that shared one motor/spindle between a fixed platter and a removable cartridge... "Clever" hardware design that ignored the software architecture... [2] Unit Data Block - VMS's drive context. They materialize when a unit is discovered. > /Bob > > ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Limits on MSCP controllers
The four ports is not arbitrary. SimH simulates actual hardware. DEC never built a backplane MSCP controller with more than four ports. If you want to extend the current RQ simulator to include third party boards (either SMD-based emulators or SCSI-based emulators), feel free to add an appropriate mode switch. I don't know what controller ID these third party boards returned, though, nor do I know how VMS determined the number of ports per controller. I think it would be better to understand why VMS is waiting to mount additional discs. Alternately, just create bigger discs and have fewer of them. /Bob On 6/23/2019 12:00 PM, simh-requ...@trailing-edge.com wrote: This is, though, another slight silliness in simh. The limit to 4 disks per controller is very artificial. The UDA50, KDA50, and maybe some other controllers only have four actual, physical ports, which limited them to only have four disks per controller. However, MSCP itself do not have such a limitation, and common SCSI controllers for these machines which use MSCP allows more than four disks on a controller, and most software (at least RSX and VMS) also do not limit themselves to only configure max four disks on a controller. I wish simh didn't put such arbitrary limitations in. simh also decides on unit numbers by itself, which could also have been nice to be able to choose. ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] VAX emulator slow to configure extra disks
I can't remember having any such issues, but then again I also can't remember if I ever tried it with VAX. With PDP-11 it works without any issues. This is, though, another slight silliness in simh. The limit to 4 disks per controller is very artificial. The UDA50, KDA50, and maybe some other controllers only have four actual, physical ports, which limited them to only have four disks per controller. However, MSCP itself do not have such a limitation, and common SCSI controllers for these machines which use MSCP allows more than four disks on a controller, and most software (at least RSX and VMS) also do not limit themselves to only configure max four disks on a controller. I wish simh didn't put such arbitrary limitations in. simh also decides on unit numbers by itself, which could also have been nice to be able to choose. Johnny On 2019-06-23 15:37, Jonathan Welch wrote: A vax emulator I was configuring for a friend (MicroVAX 3900 simulator V4.0-0 Current git commit id: ab3e07a4) needs to mount more than four disks. The .INI file has set rqb enabled and an associated attach command. In my VMS startup disks are mounted very close to the beginning of the boot sequence. I discovered that when the emulator starts it is necessary to put a $ WAIT 00:00:06 before mounting DUB0; the wait is necessary for the disk to appear. Is this something that is expected behavior and should be documented or a bug that can be fixed? ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: b...@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
[Simh] VAX emulator slow to configure extra disks
A vax emulator I was configuring for a friend (MicroVAX 3900 simulator V4.0-0 Current git commit id: ab3e07a4) needs to mount more than four disks. The .INI file has set rqb enabled and an associated attach command. In my VMS startup disks are mounted very close to the beginning of the boot sequence. I discovered that when the emulator starts it is necessary to put a $ WAIT 00:00:06 before mounting DUB0; the wait is necessary for the disk to appear. Is this something that is expected behavior and should be documented or a bug that can be fixed? ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
