[TUHS] PDP-11/70 SPL

[TUHS] PDP-11/70 SPL

[Johnny Billquist]

On 2016-03-27 23:49, jnc at mercury.lcs.mit.edu  (Noel Chiappa) wrote:
>
>      > From: Johnny Billquist
>
>      > It would also be interesting if anyone can come up with a good reason
>      > why SPL should work that way.
>
> So that when doing:
>
> 	SPL	0
> 	WAIT
>
> you don't lose by having the interrupt happen between the SPL and the WAIT?

Hmm. A good point. If you depend on WAIT waking you up at an interrupt, 
then you need SPL to block here. But this also means that you must be at 
SPL 7 before any of this, otherwise you are still exposed to this 
problem (nothing says that the interrupt won't happen before the SPL as 
well).

In general, I would say that this is not the way I would write code, but 
checking in RSX and 2.11BSD I can tell that RSX do not use this pattern, 
and does a WAIT without any SPL, while 2.11BSD do an SPL 0 followed by 
WAIT. And the routine in 2.11BSD is also called at SPL 7.

So obviously, both ways have been done, and 2.11BSD will work 
potentially with a slight degration if the SPL do not block interrupts. 
It will still work fine, as you will, at a minimum, get an interrupt at 
the next clock tick, which will wake it up. But it might possibly be 
sitting in a WAIT slightly longer than required.

RSX in fact just loops after the WAIT. If an interrupt should cause the 
system to be able to do something more productive, it will not return to 
the idle loop. So yes, it also detects in the interrupt exit processing, 
that it was/is in the idle loop.

I still haven't had time to investigate properly. But at least processor 
and chip manuals do not say that SPL will block interrupts. But that is 
no guarantee that it don't in reality.

	Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol

[TUHS] PDP-11/70 SPL

[Dave Horsfall]

On Mon, 28 Mar 2016, Johnny Billquist wrote:

> > 	SPL	0
> > 	WAIT
> > 
> > you don't lose by having the interrupt happen between the SPL and the 
> > WAIT?
> 
> Hmm. A good point. If you depend on WAIT waking you up at an interrupt, 
> then you need SPL to block here. But this also means that you must be at 
> SPL 7 before any of this, otherwise you are still exposed to this 
> problem (nothing says that the interrupt won't happen before the SPL as 
> well).

SPL 7 was only used by the clock interrupt, and levels 1-3 were never used 
in Unix.  spl4() was slow devices, spl5() was fast devices, but I can't 
remember how spl6() was used (blame my fading memory).

In other words, spl7() was diable all interrupts, spl0() was enable all 
interrupts, and spl4()-spl6() meant "you'd better be doing something more 
important than what I'm doing" (per The Book).

And that was the beauty; even the clock couldn't interrupt, so bye-bye all 
scheduling...  And the HALT key, being implemented as an interrupt, 
as well...

I'm just starting to think that this "bug" was left undocumented on 
porpoise, so perhaps someone read the engineering drawings?

> In general, I would say that this is not the way I would write code, but 
> checking in RSX and 2.11BSD I can tell that RSX do not use this pattern, 
> and does a WAIT without any SPL, while 2.11BSD do an SPL 0 followed by 
> WAIT. And the routine in 2.11BSD is also called at SPL 7.

See above comment; perhaps they believed the handbook?  Heck, even the 
published Unibus spec was known to be wrong, in order to keep 3rd-party 
kit out of it (it was something subtle to do with buss timing, so 
sometimes the card worked, and sometimes it didn't, doing wonders for 
your reputation).

> So obviously, both ways have been done, and 2.11BSD will work 
> potentially with a slight degration if the SPL do not block interrupts. 
> It will still work fine, as you will, at a minimum, get an interrupt at 
> the next clock tick, which will wake it up. But it might possibly be 
> sitting in a WAIT slightly longer than required.

Slightly longer?  I think it was Lions himself who used to teach us that a 
lost interrupt is nasty :-(

> RSX in fact just loops after the WAIT. If an interrupt should cause the 
> system to be able to do something more productive, it will not return to 
> the idle loop. So yes, it also detects in the interrupt exit processing, 
> that it was/is in the idle loop.

Also keep in mind that the company who wrote RSX-11 also designed the 
hardware, and thus had a vested interest.  Anyone here remember overlapped 
seeks on the RK-11 failing under Unix, but not under RSX, so therefore it 
must be Unix's problem?  I hammered those buggers until they supplied some 
new diag routines that pretty much demonstrated the bug...  RSX of course 
never used overlapped seeks on the RK-11, so MAINDEC never tested for it.

This has nothing to do with how "SPL 0; WAIT" etc was implemented in Unix; 
we are talking hardware here.

> I still haven't had time to investigate properly. But at least processor 
> and chip manuals do not say that SPL will block interrupts. But that is 
> no guarantee that it don't in reality.

Sigh; again, there are far too many witnesses that showed that it did; not 
wishing to be offensive or anything, but did you work for DEC back then?

Ah; John Dodson: are you here?  Did you try that little program on your 
11/70?

Ian Johnson, are you here, when I "accidentally" crashed your machine, and 
after I fessed up to it, you referred to me as a vulgar term for the 
female genitalia, then promptly hung up?

I think that Kev Hill can attest to this, and I know that Kevin Dawson (I 
think) tried it on my /40 as well; then again, his "outside" group were 
always trying to hack into us, and my job was to keep the barbarians away 
from the gate (which is how I got my first job at UNSW: it was better to 
have me inside than outside...).

What about you, MarioE, ChrisT, and RonDeJ?  (And UNSW actually employed 
most of 'em.)  It's quite likely that ChrisM, GregR, and PeterI knew about 
it as well, along with possibly anyone on the old AUUG list, where the 
exploit was published, IIRC.

Christ, but this is starting to sound like some religion or other.

Yes, Warren, I need to know that should I write that history, that we 
won't both get sued; how long is the Statute of Limitations anyway?

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] PDP-11/70 SPL

[John Cowan]

Dave Horsfall scripsit:

> Ian Johnson, are you here, when I "accidentally" crashed your machine, and 
> after I fessed up to it, you referred to me as a vulgar term for the 
> female genitalia, then promptly hung up?

If he was a Brit or Ozite, he was merely calling you a jerk or idiot;
the word has a different connotation there, and is most often applied
to men rather than women.  (This is probably calqued from French _con_,
which has shifted meaning completely.)

> Christ, but this is starting to sound like some religion or other.

<http://untroubled.org/articles/gospel-of-tux.txt>

> Yes, Warren, I need to know that should I write that history, that we 
> won't both get sued; how long is the Statute of Limitations anyway?

Tell the truth and shame the Devil, and fear no libel.  Who's left to
sue you anyway?

-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
Income tax, if I may be pardoned for saying so, is a tax on income.
                --Lord Macnaghten (1901)

[TUHS] PDP-11/70 SPL

[Milo Velimirović]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1810 bytes --]


> On Mar 28, 2016, at 11:37 AM, Johnny Billquist <bqt at update.uu.se> wrote:
> 
> Thanks for some additional information.
> 
> On 2016-03-28 18:16, Milo Velimirović wrote:
>> 
>>> On Mar 28, 2016, at 9:44 AM, Johnny Billquist <bqt at update.uu.se> wrote:
>>> 
>>> On 2016-03-28 16:18, Noel Chiappa wrote:
>>>>     > From: Dave Horsfall <dave at horsfall.org>
>>>> 
>> 
>> [ Wait & RK discussion snipped.]
>> 
>>> 
>>> 
>>>>     > I know that Kevin Dawson (I think) tried it on my /40 as well
>>>> 
>>>> The 11/40 does not have the SPL instruction; see the '75-'76 PDP-11 Processor
>>>> Handbook, pg. 4-5. (Again, sorry, just want to be accurate.)
>>> 
>>> This is also a pretty important point. But one which also begs the question how the splxxx() functions in Unix worked back then. Or did Unix not use this pattern and these functions back when the 11/40 was relevant?
>> 
>> These functions existed in V6 and can be found in the file, m40.s, that was assembled with the rest of the kernel to generate a unix that would run on a /40 class machine.
> 
> Aha. Great. Thanks. Yes, BIS and BIC on the PSW obviously works, but this would definitely not block interrupts for the next instruction. So at least in that case, a WAIT could result in the kernel sitting around waiting for the next interrupt. I don't really think DEC intend WAIT to be used in the way Unix uses it, and it don't really have the properties that would be ideas for Unix. Also somewhat indicated by the fact that DEC did not use WAIT this way themselves.

I don’t have access to the RT11 or RSX source to see how DEC used the WAIT instruction, but here’s how UNIX did it on the 11/40. It’s ridiculously simple as there’s no display register to manage.

_idle:
	mov	PS,-(sp)
	bic	$340,PS
	wait
	mov	(sp)+,PS
	rts	pc


 - Milo

[TUHS] PDP-11/70 SPL

[Johnny Billquist]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1674 bytes --]

Thanks for some additional information.

On 2016-03-28 18:16, Milo Velimirović wrote:
>
>> On Mar 28, 2016, at 9:44 AM, Johnny Billquist <bqt at update.uu.se> wrote:
>>
>> On 2016-03-28 16:18, Noel Chiappa wrote:
>>>      > From: Dave Horsfall <dave at horsfall.org>
>>>
>
> [ Wait & RK discussion snipped.]
>
>>
>>
>>>      > I know that Kevin Dawson (I think) tried it on my /40 as well
>>>
>>> The 11/40 does not have the SPL instruction; see the '75-'76 PDP-11 Processor
>>> Handbook, pg. 4-5. (Again, sorry, just want to be accurate.)
>>
>> This is also a pretty important point. But one which also begs the question how the splxxx() functions in Unix worked back then. Or did Unix not use this pattern and these functions back when the 11/40 was relevant?
>
> These functions existed in V6 and can be found in the file, m40.s, that was assembled with the rest of the kernel to generate a unix that would run on a /40 class machine.

Aha. Great. Thanks. Yes, BIS and BIC on the PSW obviously works, but 
this would definitely not block interrupts for the next instruction. So 
at least in that case, a WAIT could result in the kernel sitting around 
waiting for the next interrupt. I don't really think DEC intend WAIT to 
be used in the way Unix uses it, and it don't really have the properties 
that would be ideas for Unix. Also somewhat indicated by the fact that 
DEC did not use WAIT this way themselves.

	Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol

[TUHS] PDP-11/70 SPL

[Johnny Billquist]

On 2016-03-28 16:18, Noel Chiappa wrote:
>      > From: Dave Horsfall <dave at horsfall.org>
>
>      > SPL 7 was only used by the clock interrupt
>
> Err, according to the 1975 Peripherals Handbook, both are BR6. (Sorry, only
> interested in accuracy.)

I don't think anything actually used SPL 7, as far as I can remember.

>      > Slightly longer?  I think it was Lions himself who used to teach us that
>      > a lost interrupt is nasty :-(
>
> The interrupt isn't lost, it's just that the OS does a WAIT when it should
> perhaps return and start up some user process - but that resumption of doing
> user computations is delayed by at most 1 clock tick (some other device may
> interrupt during the WAIT, before the clock does).

Right. A lost interrupt is a potential disaster and is never acceptable.
What we're talking about here is what happens after the interrupt.

>      > Anyone here remember overlapped seeks on the RK-11 failing under Unix
>
> I'd be interested in the details of this. The V6 RK driver didn't use them,
> but the RK11-D does claim to support them (having spent a modest amount of
> time looking at the drawings), so I'd very much like to know what the bug was.

I think I at least played around some with this on PDP-8 systems, and 
seem to remember it working right there. But I have not done so on PDP-11s.

>      > I know that Kevin Dawson (I think) tried it on my /40 as well
>
> The 11/40 does not have the SPL instruction; see the '75-'76 PDP-11 Processor
> Handbook, pg. 4-5. (Again, sorry, just want to be accurate.)

This is also a pretty important point. But one which also begs the 
question how the splxxx() functions in Unix worked back then. Or did 
Unix not use this pattern and these functions back when the 11/40 was 
relevant?

>      > Christ, but this is starting to sound like some religion or other.
>
> I am only interested in correct data.

My interest here is also very much on facts and technical points. I do 
not want this to become some religious argument.

	Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol

[TUHS] PDP-11/70 SPL

[Noel Chiappa]

    > From: Dave Horsfall <dave at horsfall.org>

    > SPL 7 was only used by the clock interrupt

Err, according to the 1975 Peripherals Handbook, both are BR6. (Sorry, only
interested in accuracy.)

    > even the published Unibus spec was known to be wrong, in order to keep
    > 3rd-party kit out of it (it was something subtle to do with buss timing,
    > so sometimes the card worked, and sometimes it didn't, doing wonders for
    > your reputation).

I don't know about that, but we built two UNIBUS DMA networking devices,
relying on the UNIBUS description in the 1975 Peripherals Handbook, and they
both worked fine (one became a product for Proteon).

    > Slightly longer?  I think it was Lions himself who used to teach us that
    > a lost interrupt is nasty :-(

The interrupt isn't lost, it's just that the OS does a WAIT when it should
perhaps return and start up some user process - but that resumption of doing
user computations is delayed by at most 1 clock tick (some other device may
interrupt during the WAIT, before the clock does).

    > Anyone here remember overlapped seeks on the RK-11 failing under Unix

I'd be interested in the details of this. The V6 RK driver didn't use them,
but the RK11-D does claim to support them (having spent a modest amount of
time looking at the drawings), so I'd very much like to know what the bug was.

    > I know that Kevin Dawson (I think) tried it on my /40 as well

The 11/40 does not have the SPL instruction; see the '75-'76 PDP-11 Processor
Handbook, pg. 4-5. (Again, sorry, just want to be accurate.)

    > Christ, but this is starting to sound like some religion or other.

I am only interested in correct data.

	Noel

[TUHS] PDP-11/70 SPL

[Noel Chiappa]

    > From: Johnny Billquist

    > this also means that you must be at SPL 7 before any of this

Yes, I assumed that (since it wouldn't make sense otherwise :-).

    > In general, I would say that this is not the way I would write code, but
    > ... 2.11BSD do an SPL 0 followed by WAIT.

Right; even if one does something like have every interrupt set a flag (which
is cleared while interrupts are disabled), and check that after lowering the
priority, but before doing the WAIT, there's _still_ a window between that
check, and the WAIT (although I guess it's less likely to be hit, since the
interrupt request would have to be posted _in that window_, not be hanging
around waiting to be serviced).

The only way (that I can work out) to atomically lower the priority and wait
is to do an RTI with the PC on the stack pointing to the WAIT instruction, but
I'm not sure even that is guaranteed to work.

I guess it all depends on the CPU implementation: does it check for pending
interrupts before each instruction, or only at the end of each instuction, or
what? If before, and there's an interrupt pending, it will go off before the
WAIT is executed. Although I suppose if it's at the end, it would do the check
at the end of the RTI, and do the interrupt then.

And whether it's at the end, or the beginning, WAIT itself must be special
cased, to check for pending interrupts during the execution (which can take an
indeterminate amount of time).

    > 2.11BSD will work potentially with a slight degration if the SPL do not
    > block interrupts.  It will still work fine, as you will, at a minimum,
    > get an interrupt at the next clock tick, which will wake it up. But it
    > might possibly be sitting in a WAIT slightly longer than required.

Yes, exactly.

    > RSX in fact just loops after the WAIT. If an interrupt should cause the
    > system to be able to do something more productive, it will not return to
    > the idle loop. So yes, it also detects in the interrupt exit processing,
    > that it was/is in the idle loop.

Does it detect if it was _before_ the WAIT instruction? I would assume it does,
but I don't know anything sbout RSX.

    > But at least processor and chip manuals do not say that SPL will block
    > interrupts.

Yes, I looked too, in a variety of places (PDP-11 Architecture, including in
the 'model differences' table, 11/73 Tech Manual, etc). Crickets...

    Noel