From mboxrd@z Thu Jan 1 00:00:00 1970 From: RBROADWAY@tbs-ltd.co.uk (Broadway, Rusel) Date: Fri, 15 Oct 1999 09:08:32 +0100 Subject: Help! Message-ID: <9114940C5E0FD31186950008C7B9A6021844C2@coexch.tbs-ltd.co.uk> Hi. I have been given a Bull DSP 2/300 system. The machine is running B.O.S. version 02.00.12. The machine boots and runs fine and I cal login as Root and look around the system. The problem I have is that the B.O.S. operating system is a Unix look-a-like and I can find no-one who actually knows anything about the box. Most Unix commands work but, being a VMS guy, I can't run the machine like my Digital MV 2's. Does anyone know anything about these machines? I particularly want to have a bash at programming the machine. It appears to have C (This should be fun. I've not touched C for 12 years!) Also. I have two Digital Micro Vax 2's. The both have hardware problems in that a) One machine has a system disk which will not come up to speed and b) The other has a corrupted system_primitives.exe on VMS 5.5-H and so I can't run either of them! Anyone know where I can get spares which are pre-loaded? I really would appreciate any help or advice/ pointers etc that anyone can give. Rusel Broadway Senior Systems Analyst DDI: 01206-25-5745 ********************** N O T I C E ********************************* This information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review , retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this error, please contact the sender and delete all copies of the message. This footnote also confirms that this email message has been swept for the presence of computer viruses, however we cannot guarantee that this message is free from such problems. ********************************************************************** Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.3/8.9.3) id FAA17930 for pups-liszt; Sun, 17 Oct 1999 05:02:44 +1000 (EST) Received: from finch-post-12.mail.demon.net (finch-post-12.mail.demon.net [194.217.242.41]) by minnie.cs.adfa.edu.au (8.9.3/8.9.3) with ESMTP id FAA17926 for ; Sun, 17 Oct 1999 05:02:35 +1000 (EST) Received: from simul8.demon.co.uk ([212.228.120.103]) by finch-post-12.mail.demon.net with esmtp (Exim 2.12 #1) id 11cZ66-000Dz5-0C for pups at minnie.cs.adfa.edu.au; Sat, 16 Oct 1999 19:02:30 +0000 Message-ID: <3808CDC7.210BC969 at simul8.demon.co.uk> Date: Sat, 16 Oct 1999 20:11:03 +0100 From: James Lothian X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en,ja MIME-Version: 1.0 To: pups at minnie.cs.adfa.edu.au Subject: Re: vtserver References: <199910141836.LAA21478 at moe.2bsd.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pups at minnie.cs.adfa.edu.au Precedence: bulk Hmm.. I seem to remember, from when I was thinking about rolling my own 11 OS a few years ago, that the /34 differs from most of the other mid-range 11s in automatically restoring the CPU registers on a page fault. I think I picked this up from the differences table in the /04, /34 & /60 CPU handbook. (This was unfortunately no use at all to me, as I've got a /40 not a /34.) Of course, that was a while ago and I might be wrong. James "Steven M. Schultz" wrote: > > Hi - > > > From: Wilko Bulte > > I will be doing some more research on this when I get home from > work tonight. > > > I once had Ultrix-11 3.1 running on a dual RK05 11/34. What I'd call a > > very minimal system ;-) But it ran > > That is because DEC put the extra effort into supporting non-split I/D > machines. The "stock" V7 really wanted a 11/70. In fact there was a > chapter in the back of one of the manuals/books detailing what it took > to get V7 running on an 11/40 (it was a non-trivial project). > > Several things conspire against V7 and later on 11/34 (or 35, 40, 60, > etc). The two most notable ones are the limited address space, > everything (drivers, data structures, general kernel code) must fit > in 56kb instead of 120kb - (8kb reserved for the I/O page) and lack > of instruction restart on MMU faults. > > I'll take a look at the V7 layout later but my memory is that it > wanted an 11/70. > > Steven Schultz Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.3/8.9.3) id FAA18139 for pups-liszt; Sun, 17 Oct 1999 05:47:02 +1000 (EST) Received: from moe.2bsd.com (0 at MOE.2BSD.COM [206.139.202.200]) by minnie.cs.adfa.edu.au (8.9.3/8.9.3) with ESMTP id FAA18135 for ; Sun, 17 Oct 1999 05:46:53 +1000 (EST) Received: (from sms at localhost) by moe.2bsd.com (8.9.0/8.9.0) id MAA18843 for pups at minnie.cs.adfa.edu.au; Sat, 16 Oct 1999 12:42:14 -0700 (PDT) Date: Sat, 16 Oct 1999 12:42:14 -0700 (PDT) From: "Steven M. Schultz" Message-Id: <199910161942.MAA18843 at moe.2bsd.com> To: pups at minnie.cs.adfa.edu.au Subject: Re: vtserver Sender: owner-pups at minnie.cs.adfa.edu.au Precedence: bulk Hi - > From: James Lothian > > Hmm.. I seem to remember, from when I was thinking about rolling my own > 11 OS a few years ago, that the /34 differs from most of the other > mid-range 11s in automatically restoring the CPU registers on a page fault. I It's not the automatically restoring that is the problem - the /34, /40 (/60, etc) lack the MMU registers that record by how much the cpu registers have incremented/decremented at the time an instruction has faulted. SSR1 and SSR2 located at 0177574 and 0177576 respectively. From the module which handles the instruction restart (mch_backup.s): * 11/40 version of backup, for use with no SSR1 and SSR2. Actually SSR1 * usually exists for all processors except the '34 and '40 but always * reads as zero on those without separate I&D ... What is a dozen lines of code if those registers exist turns into over 300 lines and even then there is no guarantee (fortunately the C compiler does not generate the sequences that can not be handled) it will work. What's instruction restart used for? The most common case is growing the stack. The stack for a process starts out small and then kernel will automatically extend it downwards IF an instruction faults when accessing the stack area: sub $N,sp mov $xxx, XX(sp) mov -(r4), X(sp) for dealing with local variables in a function. The other case is when calling a function: mov (r0)+, -(sp) mov $xxx, -(sp) jsr pc, function If the reference to (sp) is made and the instruction faults the kernel will determine if the current stack needs to be extended. It will then restart the faulted instruction - but to do that it needs to know what other registers ('r0', 'r4', etc...) might have been already changed so that it can back out those changes before restarting the instruction. In the case of the 11/44, 70, 73, etc there are MMU registers that will record the fact that "R0" or "r4" or whatever was changed by 2 or not. On the /34 and /40 that capability does not exist and the kernel can not _always_ guarantee things will work. MOST of the time it will but... Interestingly enough there is a difference between the KDJ-11 (11/73) family and the other 11s which have the SSR1, and 2. From the bug report and fix for 2.11BSD (update #150): "The problem is that the KDJ-11 processes the double word store of the 'movfi' differently than the 11/44 or 11/70. On other systems (such as the 11/44) the first word is stored successfully at 0175000 then the program faults when trying to access 0174776 but SP is left at 0174776 with SSR1 (memory management status register 1) indicating that 'sp' was decremented by 4. The kernel adjusts 'sp', grows the stack and restarts the instruction. The 'movfi' then completes successfully. On a KDJ-11 cpu the story is different. The fault is generated as expected BUT 'SP' IS STILL 0175002! The kernel sees that 'sp' is still within the "valid stack region" and DOES NOT grow the stack at all. SSR1 indicates that no registers were modified so the kernel does no adjustment of 'sp'. The instruction is NOT restarted and a SIGSEGV signal is sent to the program. The problem appears to be only when doing FP instructions, fixed point operations do not experience any difficulty. The instruction "cmp -(sp),-(sp)" for example is handled correctly." Steven Schultz sms at moe.2bsd.com Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.3/8.9.3) id GAA18253 for pups-liszt; Sun, 17 Oct 1999 06:08:29 +1000 (EST) Received: from moe.2bsd.com (0 at MOE.2BSD.COM [206.139.202.200]) by minnie.cs.adfa.edu.au (8.9.3/8.9.3) with ESMTP id GAA18248 for ; Sun, 17 Oct 1999 06:08:01 +1000 (EST) Received: (from sms at localhost) by moe.2bsd.com (8.9.0/8.9.0) id NAA19063 for pups at minnie.cs.adfa.edu.au; Sat, 16 Oct 1999 13:07:04 -0700 (PDT) Date: Sat, 16 Oct 1999 13:07:04 -0700 (PDT) From: "Steven M. Schultz" Message-Id: <199910162007.NAA19063 at moe.2bsd.com> To: pups at minnie.cs.adfa.edu.au Subject: Re: vtserver Sender: owner-pups at minnie.cs.adfa.edu.au Precedence: bulk > From: Warren Toomey > > To: Kirk Davis > > Do you know of anyone that has used it on a /34? I've punched in the > > bootstrap and ran it. It loads the boot file from my Linux system. > > It appears to call it but it halts somewhere in the 70000-70040 region. > > Nothing comes up on the console. Looks like the memory is over written > > with the same values over and over again in this area. Any thoughts? > > > Sorry for the delay Kirk. It could be that the V7 bootstrap expects > split I/D, or a different I/O mapping then what's provided on the /34. > > I'll punt this to the PUPS mailing list. I have a suspicion that > you won't be able to install V7, but you should be able to install V6 > or 2.9BSD instead. I _think_ I know what the problem is... While the /34 (and /40, etc) can run a stripped down V7 (the necessary mch.s code exists for example) the kernels that come with the distribution are split I&D kernels. /hptmunix, etc are all split I/D executables. Thus you'll be able to toggle in the bootstrap and get /boot loaded but then fault when loading and/or trying to execute the kernel. As I recall the usual way to get Unix on to a /23, 34,etc was to have a 11/70 around to do the build on, then stage/create the media (usually an RL02 or similar) on the 70 and sneakernet the pack over to the /34. At least that is how it was done when we shoehorned V7 into an 11/23. Of course we "cheated" in that we had a fellow around who made the necessary changes to the assembler/compiler/linker to handle kernel overlays (preceeded the use of them in 2BSD by several years). Thus we could run a larger kernel than a pure/stock V7. It was an "interesting" experience running V7 on an 11/23 (maxed out with 248kb of memory which was fairly expensive at the time). There was just enough memory left after the kernel was loaded for a couple user processes. Thus as the '#' prompt you would run "ls" the shell ('sh') would get swapped out, the 'ls' would run, and then 'sh' would get swapped back in. Uh, slowed things down just a _little_ bit :-) Steven Schultz sms at moe.2bsd.com