HDTenEightyP/NetNews huggingface dataset:
From: dsroberts@beckman.com
Newsgroups: vmsnet.internals
Subject: Re: ALPHA MB instruction
Date: 14 Apr 92 18:23:50 GMT
Organization: Beckman Instruments

In article <1992Apr13.133417.859@beckman.com>, dsroberts@beckman.com writes:
> I've been reading the Preliminary Alpha Architecture Handbook.  One thing has
> struck me as curious, and I was wondering.  Alpha has implemented a command
> called "MB", which is memory barrier.  It looks to me a lot like a spinlock
> (the memory portion).  Has anyone absorbed enough of the info on ALPHA to say 
> difinitively what the similarities and differences are between these two 
> commands/concepts?

Well, since no one responded to my original question, I thought I'd elaborate
on this a bit.  In the AAH sections 5.5.3 to 5.5.4 where it is discussing some
of the concepts of data sharing, an example is given using a
"spin loop".  Within that loop there is a pair of MB commands which the example
lists as the "critical section".  After further fleshing this out, it goes on
to section 5.5.4 were it discusses the outline of the sequence of events for
writing to the shared data structure.

This strikes me as very similar to the actions that occur in a spin lock, for
example taking out the SCHED lock keeping other processors from changing
portions of the JIB until the lock is released.

What this sounds like to me is that the MB command (and associated spin loop)
gives you is the same type of control as a VAX spinlock but for shared data
regions of your own creation, and without the annoyance of going into kernel
mode. 

I was hoping some of the internals guru's who have reviewed ALPHA might
elaborate on how this concept is similar or different from the VAX spinlock.

-- 
   Don Roberts                   Internet:  don@beckman.com
   Beckman Instruments, Inc.     Phone:     714/961-3029
   2500 Harbor Bl. Mailstop X-12 FAX:       714/961-3351
   Fullerton, CA  92634          Disclaimer:  Blame me, not Beckman.
   Sometimes I feel like I'm the only one born without an instruction manual.
           - Ron Tye
Xref: sparky vmsnet.internals:732 comp.os.vms:8441
From: yates@wctdpv.gd.com (Jeff Yates (619)547-4726)
Newsgroups: vmsnet.internals,comp.os.vms
Subject: RE: Help - Device allocated/mounted to non-existant process
Date: 16 Apr 92 19:18:00 GMT
Reply-To: yates@gdwest.gd.com
Organization: San Diego State University Computing Services


   Actually, I did receive and install CSCPAT_0245 - IO_ROUT.EXE last
   november while I was running VMS 5.4-2.  That got me thinking that
   maybe my subsequent upgrade to VMS 5.5 (Feb'92) replaced "DISMNTSHR.EXE"
   with a new (and still bugged) version.  Such is not the case.  I verified
   that I am using the patch version.

   Thanks for the suggestion anyhow...

                                Jeff Yates
                       Computer Sciences Corporation
                       Technology Management Division
From: gjc@mitech.com (George J. Carrette)
Newsgroups: vmsnet.internals
Subject: device driver hackery
Date: 9 Apr 92 17:13:41 GMT
Organization: Mitech Corporation, Concord MA

The kernel_mode(); user_mode(); calls are neat, but how about something
truly different?

I've seen VMS device drivers written in C, even though that isn't
a highly-recommended thing to do, by the use of some macro code to
call into the C code entry points.

Taking that one step further, make the C code call into the code
provided on VMSNET.SOURCES as SIOD version 2.7, and then you would
have the ability to write VMS device drivers in interpreted lisp!

-gjc
From: "CCF::GPE%hermes.mod.uk"@relay.MOD.UK
Newsgroups: vmsnet.internals
Subject: VCRP
Date: Tue, 14 Apr 92  13:24 GMT
Organization: Macro32<==>Vmsnet.Internals Gateway
X-Gateway-Source-Info: Mailing List

Can anyone tell me what a VCRP is? IDS has not helped!

More to the point, what does one do when one's LRP list is full of them and
they are growing through non-paged pool?!

I have been in with SDA and examined and formatted some, but have not really
got anywhere. I can give more details if someone tells me what details are
relevant (I have a VERY large log file from SDA).

MI cluster. This is happening on a CI node (6320) running 5.4-3 (has also
happened on 5.4-2).

An incident may last an hour or two. LRP usage climbs. LRP list expands to
LRPCOUNTV, then non-paged pool starts growing. If we reach NPAGEVIR - curtains!
Usually stops before then - ends very quickly.

Thanks

Graham Evans
GPE%hermes.mod.uk@relay.mod.uk or GPE@hermes.mod.uk (INTERNET)
GPE@uk.mod.hermes (JANET)
Newsgroups: vmsnet.internals
Subject: Re: ALPHA MB instruction
From: don@zl2tnm.gen.nz
Date: 15 Apr 92 20:22:04 +1200
Organization: The Wolery

In article <1992Apr14.112350.860@beckman.com>, dsroberts@beckman.com writes:
> What this sounds like to me is that the MB command (and associated spin loop)
> gives you is the same type of control as a VAX spinlock but for shared data
> regions of your own creation, and without the annoyance of going into kernel
> mode. 

MB is a primitive that makes spinlocks work in multiprocessor Alphas.  It
also has applications when talking to device registers etc.  Basically,
without MB, the operations (my Alpha book has been borrowed, so I can't
quote the assembler mnemonics): 

        move a to x
        move b to y

might get re-ordered by the hardware to do the b->y write *before* the 
a->x write.  If x and y are device registers, this would be a Bad Thing.  
If x were a spinlock and y some shared data, that would also be a Bad 
Thing.  On the other hand, if the x & y were in different memory banks 
and the bank which contained x was still being written to, writing to y 
while x was busy might just help performance a little.

So, you change the sequence to:

        move a to x
        MB
        move b to y

and everybody's happy, since we now know that the a->x move will happen 
before the b->y move.

> I was hoping some of the internals guru's who have reviewed ALPHA might
> elaborate on how this concept is similar or different from the VAX spinlock.

Spinlocks are a higher level construct to what the MB instruction deals 
with.  You can use it to implement spinlocks, but the issues about who 
can create one where and when are going to be just as OS dependent as 
they are with the VAX.


Don Stokes, ZL2TNM (DS555)                       don@zl2tnm.gen.nz (home)
Network Manager, Computing Services Centre           don@vuw.ac.nz (work)
Victoria University of Wellington, New Zealand             +64-4-495-5052
Newsgroups: vmsnet.internals
Subject: Help getting image dumps?
From: jeh@cmkrnl.com
Date: 6 Apr 92 21:47:48 PDT
Organization: Kernel Mode Consulting, San Diego CA

Hi, folks,

Do any of you have some good experience with SET PROCESS/DUMP ?

I am trying to get this to work reliably so that I can have people send me 
dumps when the extended-packet version of uucico accvio's... since, naturally,
I can't duplicate the problem here.  

However, I can't get it to work reliably on my copies of uucico.  Works fine 
on simple test images.  

What conditions will inhibit an image dump?  I know that it won't do an image
dump if the image is installed with privileges that aren't in the process's
current privilege mask (as read by JPI$_PROCPRIV), (and either CMKRNL or 
SETPRV in _PROCPRIV overrides this check), but that isn't the problem here. 
What else could it be?  

	--- Jamie Hanrahan, Kernel Mode Consulting, San Diego CA
uucp 'g' protool guru, VMSnet (DECUS uucp) Working Group, and
Chair, VMS Programming and Internals Working Group, U.S. DECUS VAX Systems SIG 
Internet:  jeh@cmkrnl.com, hanrahan@eisner.decus.org, or jeh@crash.cts.com
Uucp:  ...{crash,eisner,uunet}!cmkrnl!jeh

"There's no security... where's the challenge?!?"  -- Bruce Ellis on Unix
From: gkn@ucsd.edu (Gerard K. Newman)
Newsgroups: vmsnet.internals
Subject: Re: device driver hackery
Date: 13 Apr 1992 10:12:23 -0700
Organization: San Diego Supercomputer Center
NNTP-Posting-Host: ucsd.edu

In article <1992Apr11.171251.417@cmkrnl.com> jeh@cmkrnl.com writes:
>
>There's a lot more going on in WFIKPCH than just the self-relative pointer 
>to the timeout routine (a brain-dead design if ever I saw one; why can't the
>DDT simply contain an entry for the timeout routine?).

Amen to that!


-- 
gkn	Gerard K. Newman		gkn@sdsc.edu		619.534.5076
	San Diego Supercomputer Center	gkn@sdsc.bitnet		619.534.5152 FAX
	PO Box 85608			sdsc::gkn (27.1/span)
	San Diego, CA  92186-9784	ucsd!gkn
From: flowers@admin1.memst.edu (Harry Flowers)
Newsgroups: vmsnet.internals
Subject: Re: ALPHA MB instruction
Date: 16 Apr 92 12:45:25 -0600
Organization: Memphis State University

In article <6CF679200D9F400789@BABSON.BITNET>,
 John Shea <SHEA@BABSON.BITNET> writes:
>         It appears that many of you have much more Alpha info than I do so
> far.  Does anyone have enough info to explain the difference between MB and
> IMB?

The IMB is an Instruction-stream Memory Block.  Since instructions may have
been cached or buffered, and the I-stream is not required to be consistent
with memory (see 5.4, points 7 & 8), you need something that tells the
processor that you expect to execute the code which should currently be in
those memory locations.  The IMB is always required before transferring
execution to code written to memory.  Page faulting is probably the biggest
user... self-modifying code could be another (if you do such nasty stuff).
--
Harry Flowers                           Internet: FLOWERS@MEMSTVX1.MEMST.EDU
Memphis State University                & Bitnet: FLOWERS@MEMSTVX1
From: MILLER@TGV.COM
Newsgroups: vmsnet.internals
Subject: RE: System service calls & access modes
Date: 9 Apr 92 16:54:24 GMT
Organization: Macro32<==>Vmsnet.Internals Gateway
X-Gateway-Source-Info: Mailing List


>The caveat here is of course that this is GCC.  VAXC, other languages or
>even different versions of GCC may generate different code.

Here's the VAXC version:

BLAH+2:  MOVAB   W^0F7F8(SP),SP
BLAH+7:  CALLS   #00,L^KERNEL_MODE
BLAH+0E:  CVTBL   #00,W^0FFF8(FP)
BLAH+14:  CALLS   #00,L^USER_MODE
BLAH+1B:  RET

(essentially)


So, yeah, it works for VAXC.  And preliminary tests have shown that it
works with MACRO32 as well.

-bruce

----------------------------------------------------------------------------
Bruce R'. Miller, MILLER@TGV.COM        (408) 427-4366  in Santa Cruz CA
        "And through the wire, we can talk..." - PG
From: gkn@ucsd.edu (Gerard K. Newman)
Newsgroups: vmsnet.internals
Subject: Re: device driver hackery
Keywords: WFIKPCH
Date: 10 Apr 92 01:16:58 GMT
Organization: San Diego Supercomputer Center
NNTP-Posting-Host: ucsd.edu

In article <1039@mitech.com> gjc@mitech.com (George J. Carrette) writes:
>
>I've seen VMS device drivers written in C, even though that isn't
>a highly-recommended thing to do, by the use of some macro code to
>call into the C code entry points.

How does one do the self-relative pointer to the timeout routine
generated by the WFIKPCH (or WFIRLCH, for that matter) macro in
C?

Just curious.


-- 
gkn	Gerard K. Newman		gkn@sdsc.edu		619.534.5076
	San Diego Supercomputer Center	gkn@sdsc.bitnet		619.534.5152 FAX
	PO Box 85608			sdsc::gkn (27.1/span)
	San Diego, CA  92186-9784	ucsd!gkn
From: jeh@cmkrnl.com
Newsgroups: vmsnet.internals
Subject: Re: VAX C #pragma
Date: 15 Apr 92 16:52:09 GMT
Organization: Kernel Mode Consulting, San Diego CA

In article <9204141716.AA18695@eec.umr.edu>, <barnes@eec.umr.edu> writes:
>         Jamie,
> 
>         Share, what is the (undocumented) VAX C #pragma that declares a
>         C routine to be accessed via a JSB?
> 
> 
>         Jym Barnes (BARNES@UMRGEC.EEC.UMR.EDU)

Sorry, I don't have it handy.  Someone else mentioned it in NEWS awhile back,
and I saved the info, but I wasn't all that interested (since it's undoc'd and
won't necessarily stay around forever) and I can't find where I saved it right
now.  

In any case it turns out not to be useful for calling system routines; it
works only for routines internal to the module. 

	--- Jamie Hanrahan, Kernel Mode Consulting, San Diego CA
uucp 'g' protocol guru, VMSnet (DECUS uucp) Working Group, and
Chair, VMS Programming and Internals Working Group, U.S. DECUS VAX Systems SIG 
Internet:  jeh@cmkrnl.com, hanrahan@eisner.decus.org, or jeh@crash.cts.com
Uucp:  ...{crash,eisner,uunet}!cmkrnl!jeh
From: John Shea <SHEA@BABSON.BITNET>
Newsgroups: vmsnet.internals
Subject: Re: ALPHA MB instruction
Date: Thu, 16 Apr 92 12:27 EST
Organization: Macro32<==>Vmsnet.Internals Gateway
X-Gateway-Source-Info: Mailing List

        It appears that many of you have much more Alpha info than I do so
far.  Does anyone have enough info to explain the difference between MB and
IMB?

                        John

John Shea
Systems Manager
Babson College
Shea@Babson.Bitnet
From: dsroberts@beckman.com
Newsgroups: vmsnet.internals
Subject: Re: ALPHA MB instruction
Date: 16 Apr 92 15:01:02 PDT
Organization: Beckman Instruments

In article <1992Apr16.124525.1866@admin1.memst.edu>, flowers@admin1.memst.edu (Harry Flowers) writes:
> In article <6CF679200D9F400789@BABSON.BITNET>,
>  John Shea <SHEA@BABSON.BITNET> writes:
>>         It appears that many of you have much more Alpha info than I do so
>> far.  Does anyone have enough info to explain the difference between MB and
>> IMB?
> 
> The IMB is an Instruction-stream Memory Block.  Since instructions may have
> been cached or buffered, and the I-stream is not required to be consistent
> with memory (see 5.4, points 7 & 8), you need something that tells the
> processor that you expect to execute the code which should currently be in
> those memory locations.  The IMB is always required before transferring
> execution to code written to memory.  Page faulting is probably the biggest
> user... self-modifying code could be another (if you do such nasty stuff).

Let's flesh this out a bit, from the AAH, I glean the following, and would
appreciate anyone correcting me where I'm wrong.  The IMB is PALcode, the MB 
is not.  The IMB only applys to I-streams that are being executed on the 
same processor that the IMB is being executed on (implied by section 
5.6.4.4), while an MB would be used on an I-stream that is to be
executed on a seperate processor - presumably this means that such an I-stream
is just ordinary memory to the first processor (?).

See, Bruce, I'm trying to avoid those 79 character lines you dislike :-).
-- 
   Don Roberts                   Internet:  don@beckman.com
   Beckman Instruments, Inc.     Phone:     714/961-3029
   2500 Harbor Bl. Mailstop X-12 FAX:       714/961-3351
   Fullerton, CA  92634          Disclaimer:  Blame me, not Beckman.
   Sometimes I feel like I'm the only one born without an instruction manual.
           - Ron Tye
From: DNW@NLR.NL
Newsgroups: vmsnet.internals
Subject: Re: What's the use of SETPRV privilege?
Date: Fri, 10 Apr 92 08:52 MET
Organization: Macro32<==>Vmsnet.Internals Gateway
X-Gateway-Source-Info: Mailing List

>>Then if Carlo modified his kernel mode routine to change his authorized
>>privileges (instead of the current privileges) he'd get what he's after.
>>
>>I experimented with doing /DEFPRIV=SETPRV from AUTHORIZE to a non-privileged
>>user and he couldn't turn on any privileges: SETPRV has to be in your
>>authorized privilege mask for it to work.
>
>Yes, Dan.  I just didn't want to post the details.  I did this quite
>some time ago, and I didn't find it hard to do.
>
>Note that $SETPRV will not set the bits in question.  You'll have to
>write the code yourself.  -- Think of it as an excercise for the reader.  :)

Hm...
So there are two privilege masks for a process, AUTHORIZED and SET.

Consider the example I gave, having a subprocess with privs
CMKRNL and TMPMBX and then set the SETPRV privilege.

So CMKRNL and TMPMBX are both authorized and set.
SETPRV is only set but not authorized.

Now execute another SPAWN command.
And then it's also possible to set any privilege with set proc/priv.
So a subprocess inherits both its authorized and its set
privileges from its parent's set privileges ??

/Carlo Mekenkamp <DNW@NLR.NL>
From: don@zl2tnm.gen.nz
Newsgroups: vmsnet.internals
Subject: RE: System service calls & access modes
Date: 9 Apr 92 22:48:30 +1200
Organization: The Wolery

In article <702761102.594528.MILLER@TGV.COM>, MILLER@TGV.COM writes:
> blah() {
>         int i;
> 
>         kernel_mode();
>         { 
>                 int matrix[512];
>                 bzero(matriz,512*sizeof(int));
>         }
>         user_mode();
> }
> 
> Will the space for matrix be allocated off the user stack before or after
> the call to kernel_mode()?  If not, the bzero() call fill screw up our
> call frames.

Well, for starters, it won't compile.  8-)

Change "matriz" to "matrix", and GCC compiles it to:

                .entry blah, ^M<>
                movab -2048(SP), SP
                calls #0, kernel_mode
                movzwl #2048, -(SP)
                pushab -2048(FP)
                calls #2, g^bzero
                calls #0, user_mode
                ret

So, the stack space is allocated only once.  I don't see any reason to 
want to allocate multiple times.  Just allocate the maximum used by any 
block in the routine, since we know this at compile time.  I can see a 
number of good reasons for doing it this way.

I also compiled a version of the above which accessed &i, si that i was 
not optimised away.  No change, ie all allocated at the start.

So, it appears "safe".

The caveat here is of course that this is GCC.  VAXC, other languages or 
even different versions of GCC may generate different code.

> I showed my kmon() and kmoff() functions to Ken Adelman and Dave Kashtan.
> They said it was very clever and told me not to use it in any MultiNet
> programs....  :)

Gee, some people really are no fun.... 8-)

Mind you, I'd be the first to admit that this is rather a case of the 
proverbial "solution looking for a problem", but it's educational and 
fun.  Mind you, I'm the sort of perverse so-and-so who'd go and use it 
somewhere, just to confuse someone.... 8-)


Don Stokes, ZL2TNM (DS555)                       don@zl2tnm.gen.nz (home)
Network Manager, Computing Services Centre           don@vuw.ac.nz (work)
Victoria University of Wellington, New Zealand             +64-4-495-5052
From: <barnes@eec.umr.edu>
Newsgroups: vmsnet.internals
Subject: VAX C #pragma
Date: Tue, 14 Apr 92 12:16:16 CDT
Organization: Macro32<==>Vmsnet.Internals Gateway
X-Gateway-Source-Info: Mailing List

        Jamie,

        Share, what is the (undocumented) VAX C #pragma that declares a
        C routine to be accessed via a JSB?


        Jym Barnes (BARNES@UMRGEC.EEC.UMR.EDU)
From: GAVRON@vesta.sunquest.com
Newsgroups: vmsnet.internals
Subject: Re: Help getting image dumps?
Date: 8 Apr 92 14:36:11 GMT
Organization: Macro32<==>Vmsnet.Internals Gateway
X-Gateway-Source-Info: Mailing List

Date sent:  8-APR-1992 07:35:19


>From: jeh@cmkrnl.com
>but I like News more, and the "community" on the vmsnet part of News is
>every bit as "kind and gentle" as that on DECUServe.

        Hey!  Watch what names you throw out there!

        ;-)

        Ehud

--
Ehud Gavron        (EG76)
gavron@vesta.sunquest.com
"The world bores you when you're cool."
From: DWING@UH01.Colorado.EDU (Dan Wing)
Newsgroups: vmsnet.internals
Subject: Re: What's the use of SETPRV privilege?
Date: 9 Apr 92 19:28:26 GMT
Article-I.D.: VAXF.01GIN670AJSI00005J
Organization: Macro32<==>Vmsnet.Internals Gateway
X-Gateway-Source-Info: Mailing List

Derek S. Haining, DEREK@MAX.BITNET, DEREK@MAX.U.WASHINGTON.EDU, wrote:

>Carlo Mekenkamp,
>
>As I recall, what you did used to work -- a long time ago.  Now, however,
>it doesn't.  As I recall, the $SETPRV system service now checks the
>AUTHORIZED privilege mask, but only affects the PROCESS privilege mask.
>Therefore, the attempt to do a "$ SET PROC/PRIV=some-other-priv" fails.

Then if Carlo modified his kernel mode routine to change his authorized
privileges (instead of the current privileges) he'd get what he's after.

I experimented with doing /DEFPRIV=SETPRV from AUTHORIZE to a non-privileged
user and he couldn't turn on any privileges: SETPRV has to be in your
authorized privilege mask for it to work.

-Dan Wing, DWING@UH01.Colorado.EDU  (or WING_D@UCOLMCC.BITNET)
 Systems Programmer, University Hospital, Denver
From: MILLER@TGV.COM
Newsgroups: vmsnet.internals
Subject: RE: System service calls & access modes
Date: 8 Apr 92 19:25:02 GMT
Organization: Macro32<==>Vmsnet.Internals Gateway
X-Gateway-Source-Info: Mailing List


What happens in this case?:

blah()
{
        int i;

        kernel_mode();

        { int matrix[512];

          bzero(matriz,512*sizeof(int));
        }

        user_mode();

}


Will the space for matrix be allocated off the user stack before or after
the call to kernel_mode()?  If not, the bzero() call fill screw up our
call frames.

-bruce

----------------------------------------------------------------------------
Bruce R'. Miller, MILLER@TGV.COM        (408) 427-4366  in Santa Cruz CA
        "And through the wire, we can talk..." - PG
From: DEREK@U.WASHINGTON.EDU
Newsgroups: vmsnet.internals
Subject: Re: What's the use of SETPRV privilege?
Date: 9 Apr 92 19:21:00 GMT
Organization: Macro32<==>Vmsnet.Internals Gateway
X-Gateway-Source-Info: Mailing List

>Then if Carlo modified his kernel mode routine to change his authorized
>privileges (instead of the current privileges) he'd get what he's after.
>
>I experimented with doing /DEFPRIV=SETPRV from AUTHORIZE to a non-privileged
>user and he couldn't turn on any privileges: SETPRV has to be in your
>authorized privilege mask for it to work.

Yes, Dan.  I just didn't want to post the details.  I did this quite
some time ago, and I didn't find it hard to do.

Note that $SETPRV will not set the bits in question.  You'll have to
write the code yourself.  -- Think of it as an excercise for the reader.  :)

-Derek S. Haining
 University Computing Services
 University of Washington
 Seattle, Washington  98195
 (206) 543-5579

 DEREK@MAX.BITNET
 DEREK@MAX.U.WASHINGTON.EDU
From: MILLER@TGV.COM
Newsgroups: vmsnet.internals
Subject: RE: System service calls & access modes
Date: 8 Apr 92 19:27:05 GMT
Organization: Macro32<==>Vmsnet.Internals Gateway
X-Gateway-Source-Info: Mailing List


I showed my kmon() and kmoff() functions to Ken Adelman and Dave Kashtan.
They said it was very clever and told me not to use it in any MultiNet
programs....  :)

-bruce

----------------------------------------------------------------------------
Bruce R'. Miller, MILLER@TGV.COM        (408) 427-4366  in Santa Cruz CA
        "And through the wire, we can talk..." - PG
From: GAVRON@VESTA.SUNQUEST.COM
Newsgroups: vmsnet.internals
Subject: RE: ALPHA MB instruction
Date: 13 Apr 92 22:01:19 GMT
Organization: Macro32<==>Vmsnet.Internals Gateway
X-Gateway-Source-Info: Mailing List

Don Roberts continues his tradition of intellectual insight with yet another
gem of wisdom in the making designed to thrill us all with his mastery of an
eruiditic pursuit of knowledge:

>It looks to me a lot like a spinlock (the memory portion).

        Well, Don, a spinlock is a lock with a busy wait loop on it.
        Do you mean to say that to one of your mental stature, an MB
        looks quite a bit like a lock, or that you don't understand
        spinlocks?

>Has anyone absorbed enough of the info on ALPHA to say
>difinitively [SIC] what the similarities and differences are
>between these two commands/concepts?

        Yes.  Many people have.  Any more questions I can help you with?

>--
>   Don Roberts                   Internet:  don@beckman.com
...
>   Disclaimer:  Blame me, not Beckman.

        BUT OF COURSE!*

        Ehud

--
Ehud Gavron        (EG76)
gavron@vesta.sunquest.com
"The world bores you when you're cool."
* A quote borrowed from any Grey Poupon commercial