Problems running two or more MSCP controllers in the simulator #439
Comments
|
Why would you expect unit 8 to work? As the output from "show rqb" indicates, the unit numbers assigned to the drive on that controller are 4 through 7. You can change that but it's a bit messy because the MSCP emulation supports lots of drives per controller though it defaults to 4. And those additional drives are assigned unit numbers 4 and up, so if you just try to set the unit number of rqb0 to 8 it complains that rqb8 already has that unit number. The simplest is to go with the unit numbers SIMH assigns, so ra4 and up for the second controller. Some day we need to fix the way unit numbers are set on MSCP controllers so those silly error messages don't appear. |
|
I’m no expert on the 211BSD kernel, but I’m reasonably confident that secondary MSCP controllers show up on Unit 8, not Unit 4. I expected 4. I found 8.,
I understand the hardware contains 4 units, and do not understand why they offset by 8.
I have two RQDX3 in my PDP-11/83, which is what I’m trying to replicate with simH:
- RQDX3 at 17772150, single RA92 drive
- RQDX3 at 17772154, single ST225, dual RX50
On the real machine, I have ra0, ra8, ra9, and ra10. They all work as expected.
On simH, I have ra0, and ra8/ra8/ra10 return IO errors. As far as I can tell, the simulator is set up identical to the real hardware down to the CSR addresses and vectors.
I have been able to find zero examples of people successfully simulating multiple controllers in a way that works with BSD. But the real hardware works, so I suspect an issue.
- Dave
… On Jan 7, 2025, at 9:49 AM, Paul Koning ***@***.***> wrote:
Why would you expect unit 8 to work? As the output from "show rqb" indicates, the unit numbers assigned to the drive on that controller are 4 through 7. You can change that but it's a bit messy because the MSCP emulation supports lots of drives per controller though it defaults to 4. And those additional drives are assigned unit numbers 4 and up, so if you just try to set the unit number of rqb0 to 8 it complains that rqb8 already has that unit number.
The simplest is to go with the unit numbers SIMH assigns, so ra4 and up for the second controller.
Some day we need to fix the way unit numbers are set on MSCP controllers so those silly error messages don't appear.
—
Reply to this email directly, view it on GitHub <#439 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA4HCF62XJISDIODGKX5TLT2JQHSLAVCNFSM6AAAAABUW46WVOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNZVHA4TMMZZGA>.
You are receiving this because you authored the thread.
|
|
To wit, in ra.c:
#define RACON(x) ((minor(x) >> 6) & 03)
#define RAUNIT(x) (dkunit(x) & 07)
#define dkunit(dev) (minor(dev) >> 3)
The unit number looks to be in multiples of 8…
- Dave
… On Jan 7, 2025, at 10:55 AM, Dave Plummer ***@***.***> wrote:
I’m no expert on the 211BSD kernel, but I’m reasonably confident that secondary MSCP controllers show up on Unit 8, not Unit 4. I expected 4. I found 8.,
I understand the hardware contains 4 units, and do not understand why they offset by 8.
I have two RQDX3 in my PDP-11/83, which is what I’m trying to replicate with simH:
- RQDX3 at 17772150, single RA92 drive
- RQDX3 at 17772154, single ST225, dual RX50
On the real machine, I have ra0, ra8, ra9, and ra10. They all work as expected.
On simH, I have ra0, and ra8/ra8/ra10 return IO errors. As far as I can tell, the simulator is set up identical to the real hardware down to the CSR addresses and vectors.
I have been able to find zero examples of people successfully simulating multiple controllers in a way that works with BSD. But the real hardware works, so I suspect an issue.
- Dave
> On Jan 7, 2025, at 9:49 AM, Paul Koning ***@***.***> wrote:
>
>
> Why would you expect unit 8 to work? As the output from "show rqb" indicates, the unit numbers assigned to the drive on that controller are 4 through 7. You can change that but it's a bit messy because the MSCP emulation supports lots of drives per controller though it defaults to 4. And those additional drives are assigned unit numbers 4 and up, so if you just try to set the unit number of rqb0 to 8 it complains that rqb8 already has that unit number.
>
> The simplest is to go with the unit numbers SIMH assigns, so ra4 and up for the second controller.
>
> Some day we need to fix the way unit numbers are set on MSCP controllers so those silly error messages don't appear.
>
> —
> Reply to this email directly, view it on GitHub <#439 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA4HCF62XJISDIODGKX5TLT2JQHSLAVCNFSM6AAAAABUW46WVOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNZVHA4TMMZZGA>.
> You are receiving this because you authored the thread.
>
|
|
One other thing I've observed that might be relevant: in the SHOW DEV and SHOW RQB, you'll notice that is as NO VECTOR set, whereas BSD believes it to be (and confirms finding it at) 254. I would expect that RQB shows 254 just as RQ shows 154, but it does not. |
|
MSCP vectors are programmable; 154 is the conventional first value but the real rule is "pick any free vector". BSD will have to program the vector as part of initializing the device, and until it does, "not set" would be the value I'd expect to see displayed. If BSD wants to assume that the second controller has units 8 and up, you'll have to override that manually in the SIMH device config. As I said, it's a bit of a nuisance because of the invisible additional controller slots. Proceed as follows: Now "show rqb" should tell you that its unit numbers are 8..11 and that should make the OS happier. |
|
Thanks for the info! I did as you instructed, and:
sim> show rqb
RQB address=17760340-17760343*, vector=254, BR5, RQDX3, 4 units
RQB0 1505MB, attached to 211bsd-user.dsk, write enabled
RA92, UNIT=8, noautosize
RAW format
RQB1 409KB, attached to rx50-01.dsk, write enabled
RX50, UNIT=9, noautosize
RAW format
RQB2 409KB, attached to rx50-02.dsk, write enabled
RX50, UNIT=10, noautosize
RAW format
RQB3 159MB, not attached, write enabled
RD54, UNIT=11, autosize
AUTO detect format
During config I see:
ra 0 csr 172150 vector 154 vectorset attached
ra 1 csr 160340 vector 254 vectorset attached
Devices ra8, ra8, ra10 are present, but not responding:
***@***.***:~> disklabel ra8
disklabel: /dev//rra8a: Input/output error
***@***.***:~> Dec 29 10:31:26 simh vmunix: ra1: Ver 3 mod 3
Dec 29 10:31:26 simh vmunix: ra8 st=3 sb=0 fl=0 en=9
***@***.***:~> disklabel ra9
disklabel: /dev//rra9a: Input/output error
Dec 29 10:31:28 simh vmunix: ra9 st=3 sb=0 fl=0 en=9
***@***.***:~> disklabel ra10
disklabel: /dev//rra10a: Input/output error
Dec 29 10:31:29 simh vmunix: ra10 st=3 sb=0 fl=0 en=9
***@***.***:~> disklabel ra11
disklabel: /dev//rra11: No such file or directory
So largely the same behavior as before. Disklabel works on the primary controller at ra0, etc.
- Dave
Here’s /dev/*ra* for what it's worth!
***@***.***:~> ls /dev/*ra*
/dev/ra0a /dev/ra1b /dev/ra8c /dev/rra0c /dev/rra1d /dev/rra8e
/dev/ra0b /dev/ra1c /dev/ra8d /dev/rra0d /dev/rra1e /dev/rra8f
/dev/ra0c /dev/ra1d /dev/ra8e /dev/rra0e /dev/rra1f /dev/rra8g
/dev/ra0d /dev/ra1e /dev/ra8f /dev/rra0f /dev/rra1g /dev/rra8h
/dev/ra0e /dev/ra1f /dev/ra8g /dev/rra0g /dev/rra1h /dev/rra9a
/dev/ra0f /dev/ra1g /dev/ra8h /dev/rra0h /dev/rra2a /dev/rra9b
/dev/ra0g /dev/ra1h /dev/ra9a /dev/rra10a /dev/rra2b /dev/rra9c
/dev/ra0h /dev/ra2a /dev/ra9b /dev/rra10b /dev/rra2c /dev/rra9d
/dev/ra10a /dev/ra2b /dev/ra9c /dev/rra10c /dev/rra2d /dev/rra9e
/dev/ra10b /dev/ra2c /dev/ra9d /dev/rra10d /dev/rra2e /dev/rra9f
/dev/ra10c /dev/ra2d /dev/ra9e /dev/rra10e /dev/rra2f /dev/rra9g
/dev/ra10d /dev/ra2e /dev/ra9f /dev/rra10f /dev/rra2g /dev/rra9h
/dev/ra10e /dev/ra2f /dev/ra9g /dev/rra10g /dev/rra2h /dev/rram
/dev/ra10f /dev/ra2g /dev/ra9h /dev/rra10h /dev/rra8a
/dev/ra10g /dev/ra2h /dev/ram /dev/rra1a /dev/rra8b
/dev/ra10h /dev/ra8a /dev/rra0a /dev/rra1b /dev/rra8c
/dev/ra1a /dev/ra8b /dev/rra0b /dev/rra1c /dev/rra8d
… On Jan 7, 2025, at 11:49 AM, Paul Koning ***@***.***> wrote:
set rqb drives=12
set rqb8 unit=0
set rqb0 unit=8
set rqb9 unit=1
set rqb1 unit-9
set rqb10 unit=2
set rqb2 unit=10
set rqb11 unit=3
set rqb3 unit=11
set rqb drives=4
|
|
Oh wait... I was assuming that "ra8" means the MSCP driver will ask for unit 8 on the controller. That may not be true. I wonder if it's 0. If so, you don't need to do the magic dance I described earlier, just do: That means you have two MSCP controllers with matching unit numbers, but that's fine hardware-wise, it is something not allowed in some OS (like RSTS) but probably fine in others. |
|
Thanks! With that I’m able to see ra8, ra9, and ra10!
I’d likely argue that the default should be whatever it is on the actual hardware, which is to default to UNIT0, at least on the RQDX3. If you want it to start at unit 4 or unit 8, you can jumper it as such, just as you could supply the UNIT number in simh.ini. Out of the box, it’s unit 0 even if it’s at a secondary address.
Probably too late to make a sweeping change to behavior, but it seems to me that the simulator default should be the same as the hardware default, which is UNIT0. I don’t know the KDA50 default behavior.
Thanks very much for the help in sorting this out! I was not aware of the UNIT option on SET RQB!
Cheers,
Dave
… On Jan 7, 2025, at 12:47 PM, Paul Koning ***@***.***> wrote:
Oh wait... I was assuming that "ra8" means the MSCP driver will ask for unit 8 on the controller. That may not be true.
Looking at the definition of RAUNIT, if that is the unit number sent to the controller it obviously is a 3 bit value, so it can't be 8. You might do ls -l /dev/ra8 to see what the minor number is, to see what RAUNIT would be for that device.
I wonder if it's 0. If so, you don't need to do the magic dance I described earlier, just do:
set rqb0 unit=0
set rqb1 unit=1
set rqb2 unit=2
set rqb3 unit=3
That means you have two MSCP controllers with matching unit numbers, but that's fine hardware-wise, it is something not allowed in some OS (like RSTS) but probably fine in others.
—
Reply to this email directly, view it on GitHub <#439 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA4HCF2NFXTOEAKXDA24H6T2JQ4NRAVCNFSM6AAAAABUW46WVOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNZWGE4TAOBYGU>.
You are receiving this because you authored the thread.
|
|
There are several different things going on here.
Beyond the above defaults and setting mechanisms, EACH of the 4 MSCP controllers can have a minimum of 4 drives or a maximum of 254 drives connected. This maximum is set with a "SET RQ(,B,C,D) DRIVES=n" command. You then have drives known via simh commands as RQ(,B,C,D)n where n is from 0 up through the specified number of drives minus 1. |
|
It seems we need some fixes to this machinery.
Are there any MSCP controllers (other than HSC, which I don't think SIMH supports) that support more than 4 drives? If so, which ones and what are their limits? |
Drives from second and third MSCP controller do not work under 211BSD, but do on real hardware
Expect: To be able to mount two MSCP controllers, each with 1-3 drives. I expect those drives to show up as ra0-ra3 for the first controller, and ra8-ra11 for the second controller, and so on. And so they do on my actual hardware, which I'm trying to mirror in the simulator. But in the simulator, only ra0-3 work, and ra8 produces IO errors.
For example, with this INI file, and any BSD image I can find, I notice three things:
(1) BSD autoconfig detects the controller CSRs at 17722150 and 17772154, and vectors of 154 and 254 per the dtab
(2) The KDA50 primary controller works as expect, as does the RL. All those disks are mountable
(3) The RQDX3 drives are present, but when BSD tries to access them, it gets an I/O from the controller
set rq KDA50
set rq enabled address=17772150
set rq0 ra92 noautosize
att rq0 211bsd-root.dsk
set rqb RQDX3
set rqb enabled address=17772154
set rqb1 rx50 noautosize
att rqb1 rx50-01.dsk
set rqb2 rx50 noautosize
att rqb2 rx50-02.dsk
set rl enabled
set rl0 rl02 noautosize
att rl0 rl02-01.dsk
set rl1 rl02 noautosize
att rl1 rl02-02.dsk
... and I see this from dmesg during boot:
ra1: Ver 3 mod 3
ra9 st=3 sb=0 fl=0 en=9
ra1 st=3 sb=1 fl=0 en=9
rl1a is entire disk: no disk label
ra10 st=3 sb=0 fl=0 en=9
rl0a is entire disk: no disk label
ra8 st=3 sb=0 fl=0 en=9
the output of "sim> SHOW VERSION" while running the simulator which is having the issue
sim> show version
PDP-11 simulator Open SIMH V4.1-0 Current
Simulator Framework Capabilities:
32b data
32b addresses
Threaded Ethernet Packet transports:PCAP:VDE:NAT:UDP
Idle/Throttling support is available
Virtual Hard Disk (VHD) support
RAW disk and CD/DVD ROM support
Asynchronous I/O support (Lock free asynchronous event queue)
Asynchronous Clock support
FrontPanel API Version 12
Host Platform:
Compiler: GCC Apple LLVM 16.0.0 (clang-1600.0.26.4)
Simulator Compiled as C (Release Build) on Dec 16 2024 at 11:19:31
Build Tool: simh-makefile
Memory Access: Little Endian
Memory Pointer Size: 64 bits
Large File (>2GB) support
SDL Video support: SDL Version 2.30.10, PNG Version 1.6.44, zlib: (Compiled: 1.3.1, Runtime: 1.2.12)
No RegEx support for EXPECT commands
OS clock resolution: 1ms
Time taken by msleep(1): 1ms
Ethernet packet info: libpcap version 1.10.1
OS: Darwin M2MacPro.local 24.1.0 Darwin Kernel Version 24.1.0: Thu Oct 10 21:03:11 PDT 2024; root:xnu-11215.41.3~2/RELEASE_ARM64_T6020 arm64
Processor Name: Apple M2 Ultra
tar tool: bsdtar 3.5.3 - libarchive 3.5.3 zlib/1.2.12 liblzma/5.4.3 bz2lib/1.0.8
curl tool: curl 8.7.1 (x86_64-apple-darwin24.0) libcurl/8.7.1 (SecureTransport) LibreSSL/3.3.6 zlib/1.2.12 nghttp2/1.62.0
git commit id: 2437b13
git commit time: 2024-09-04T20:10:48-0400
how you built the simulator or that you're using prebuilt binaries
I did not save the make output, but it completed without errors
the simulator configuration file (or commands) which were used when the problem occurred.
set cpu 4m
set tto 7b
set tq enabled
set tq TK50
attach tq0 bsd.tap
set dz lines=8 localhost:2323
#set dz disabled
#set vh enabled
#set vh address=17760500, vector=300, lines=8
#attach vh 5040
RA92: Big friggin disk or iot was in the old days for DEC!
If you want even more emulated space, just "set rq rauser=size_in_megabytes",
but this is the largest DEC disk that existed in real hardware.
set rq KDA50
set rq enabled address=17772150
set rq0 ra92 noautosize
att rq0 211bsd-root.dsk
set rqb RQDX3
set rqb enabled address=17772154
set rqb1 rx50 noautosize
att rqb1 rx50-01.dsk
set rqb2 rx50 noautosize
att rqb2 rx50-02.dsk
set rl enabled
set rl0 rl02 noautosize
att rl0 rl02-01.dsk
set rl1 rl02 noautosize
att rl1 rl02-02.dsk
set xq type=delqa
set xq mac=00-55-56-01-02-26
attach xq en1
boot rq0
the expected behavior and the actual behavior
On the physical hardware with this configuration BSD will respond to "disklabel ra8" with the disk label.
On the simulator, BSD responds as follows:
disklabel ra8
ra8 st=3 sb=0 fl=0 en=9
disklabel: /dev//rra8a: Input/output error
The "st=3 sb=0..." line leads me to believe that BSD is trying to talk to the device, but is failing. But only on the simulator.
During autoconfig you can see the controllers are detected and connected:
ra 0 csr 172150 vector 154 vectorset attached
ra 1 csr 172154 vector 254 vectorset attached
The kernel was compiled for two MSCP controllers and 5 MSCP disks. But I expect this repos with any working 211BSD image, like the one from the PiDP.
Devices info:
RQ address=17772150-17772153, vector=154, BR5, KDA50, 4 units
RQB address=17772154-17772157, vector=254, BR5, RQDX3, 4 units
RQC disabled
RQD disabled
sim> show rq
RQ address=17772150-17772153, vector=154, BR5, KDA50, 4 units
RQ0 1505MB, attached to 211bsd-root.dsk, write enabled
RA92, UNIT=0, noautosize
RAW format
RQ1 159MB, not attached, write enabled
RD54, UNIT=1, autosize
AUTO detect format
RQ2 159MB, not attached, write enabled
RD54, UNIT=2, autosize
AUTO detect format
RQ3 409KB, not attached, write enabled
RX50, UNIT=3, autosize
AUTO detect format
sim> show rqb
RQB address=17772154-17772157, vector=254, BR5, RQDX3, 4 units
RQB0 159MB, not attached, write enabled
RD54, UNIT=4, autosize
AUTO detect format
RQB1 409KB, attached to rx50-01.dsk, write enabled
RX50, UNIT=5, noautosize
RAW format
RQB2 409KB, attached to rx50-02.dsk, write enabled
RX50, UNIT=6, noautosize
RAW format
RQB3 159MB, not attached, write enabled
RD54, UNIT=7, autosize
AUTO detect format
you may also need to provide specific pointers to data files that may be necessary to demonstrate the problem
The text was updated successfully, but these errors were encountered: