I've assembled some notes from old manuals and other sources
on the formats used for on-disk file systems through the
Additional notes, comments on style, and whatnot are welcome.
(It may be sensible to send anything in the last two categories
directly to me, rather than to the whole list.)
See the December 2002 discussion threads "V6: 50 bugs tape"
and "Patches to improve 6th Edition" in the archive
While not specifically mentioned in those mails it is part
of the 50 bugs tape -- you'll want to extract usr/sys/v6unix/* from
and you'll see it fixed in usr/sys/v6unix/updat/ken/sig.c
> From: jigsaw <jigsaw(a)gmail.com>
> Subject: [TUHS] UNIX V6 line 3973: Is it really a typo?
> hi all,
> It's stated in Lion's book chapter 13.13 that at line 3973, i.e. the
> function psignal, there is a typo where the p_stat should be p_pri.
> Is there anyone can confirm it?
> If it's really a bug, why it remains p_stat in UNIX V7?
> Thanks in advance
Thanks for pointing out.
I was viewing actually the V6's source while I had thought it's V7.
On 10/17/06, Hellwig Geisse <Hellwig.Geisse(a)mni.fh-giessen.de> wrote:
> Hi Qinglai,
> On Tue, 2006-10-17 at 14:26 +0800, jigsaw wrote:
> > If it's really a bug, why it remains p_stat in UNIX V7?
> it was changed in V7 to p_pri (file sig.c, lines 64/65).
It's stated in Lion's book chapter 13.13 that at line 3973, i.e. the
function psignal, there is a typo where the p_stat should be p_pri.
Is there anyone can confirm it?
If it's really a bug, why it remains p_stat in UNIX V7?
Thanks in advance
The thrust meter project -- was that an analog meter that displayed %
CPU utilization? I remember that Tom Ferrin had one mounted in the
middle of a DEC panel filler on the 11/70 at the Computer Graphics
Lab at UCSF. It was really delightful having this analog meter
bouncing up and down as people worked away.
_| _| _| Brian Knittel
_| _| _| Quarterbyte Systems, Inc.
_| _| _| Tel: 1-510-559-7930
_| _| _| Fax: 1-510-525-6889
_| _| _| Email: brian(a)quarterbyte.com
_| _| _| http://www.quarterbyte.com
> But you'd need kernel mode for that; this is a DoS attack (one of the
> first?) launched by a user.
The userland DoS I remember:
And in fact I tried it once on the 11/45 I had access to. Not pretty.
It can be made less disastrous by judicious addition of a wait(); call.
--Milo, wondering how contemporary UNIX will deal with such
University of Wisconsin - La Crosse
La Crosse, Wisconsin 54601 USA
43 48 48 N 91 13 53 W
There's a reason Dennis Ritchie and Ken Thompson have been awarded
the U.S. National Medal of Technology (1998) and are fellows of the
Computer History Museum Online. Dave Cutler hasn't and isn't.
"You are not expected to understand this."
[ Meant to go to list, but sent to DMR only by mistake. ]
On Wed, 4 Oct 2006 dmr(a)plan9.bell-labs.com wrote:
> > It contains the famous Thrust Meter, a few papers by Yours Truly, and
> > I think it has the short assembly program that would bring a PDP-11/70
> > to its knees (the infamous "SPL" firmware bug).
> Was this the feature (not really a bug; it's in the manual) that SPL
> suppressed interrupts for one instruction after the SPL? I suppose it
> was indeed a bug that this happened even in user mode where SPL was
> intended to be a no-op.
Yep, that's the one. I regard it as a bug because it indeed happened in
> I remember trying this. It depends on completely filling memory with
> SPLs, which I could not figure out how to do using an instruction
> sequence. However, putting a bunch of SPLs into a file and reading it
> in over the program did the job.
There was a clever assembly program that did it; it relied upon the
instruction counter wrapping around (I can't remember in which direction,
or whether it first relocated itself). Anyone, it managed to fill memory
with SPLs, so the next instruction after overwriting its last instruction
was SPL, and for the foreseeable future after that...
If I find the article I'll post it here; I don't think there are too many
11/70s still in public operation.
> It was a bit hard to break out of--the halt switch didn't work. At first
> I thought that power-off was the only solution, but it turned out that
> holding down both reset and halt simultaneously did the job.
I'll remember that, should I ever see an emulator :-) I still remember
Ian Johnstone cursing me...
Dave Horsfall mentioned, about some old editions of AUUGN,
> It contains the famous Thrust Meter, a few papers by Yours Truly, and I
> think it has the short assembly program that would bring a PDP-11/70 to
> its knees (the infamous "SPL" firmware bug).
Was this the feature (not really a bug; it's in the manual)
that SPL suppressed interrupts for one instruction after the SPL?
I suppose it was indeed a bug that this happened even in user mode
where SPL was intended to be a no-op.
I remember trying this. It depends on completely filling
memory with SPLs, which I could not figure out how to
do using an instruction sequence. However, putting
a bunch of SPLs into a file and reading it in over the program
did the job.
It was a bit hard to break out of--the halt switch didn't work.
At first I thought that power-off was the only solution, but it
turned out that holding down both reset and halt simultaneously did
Now I start to understand what's going on.
But do you mean 0744 by 0743?
0743 mov (sp), r0
0744 mov $_u, r0
And 2230 should be 2229, which is:
On 10/3/06, Brantley Coile <brantley(a)coraid.com> wrote:
> Rp->p_addr is the address of the swappable image in core. The process
> image begins with the user segment for that process. Line 0743 maps
> the upage into the current address space (KISA6) and _retu loads
> previously saved sp and r5 from there. Notice that on line 2230
> Ken reloads the other memory mapping registers.
> Read the section `Memory Management' starting on page 2-4 for background
> on this.
> U.u_rsave is just a constant location in memory. Notice that rp->p_addr
> isn't a byte address but a core click address in units of 64 bytes.
> Hope that helps.
> > The final question is about how savu/retu work.
> > savu:
> > line 0729 and line 0730: r5 and sp are saved to (r0) and (r0)+, which
> > are the address of u.u_rsav.
> > retu:
> > 0746 and 0747: sp and r5 are read from (r0) and (r0)+, which is
> > "rp->p_addr" (see line 2228). It looks weird to me. (Okay...I have to
> > confess I look stupid here...) When making call to retu, why bother
> > "retu(rp->p_addr)"? Why not calling with "retu(u.u_rsav)"? Does it
> > mean that rp->p_addr == u.u_rsav?