TUHS

tuhs@tuhs.org

33 participants
6541 discussions

by Michael Kerpan

Caldera changed very drastically as a company at the time it changed its name to SCO). Ancient Unix was opened up in January of 2002. In June of that year, the CEO of Caldera was forcibly replaced with an M$-backed anti-open source crusader. It was at that point that Caldera stopped selling its Linux distro, changed its name to SCO and started suing any company involved with Linux. On 11/28/06, Robert Tillyard <rob(a)vetsystems.com> wrote: > > On 28 Nov 2006, at 13:17, Michael Kerpan wrote: > > > That would never happen as it's SCO, not Novell, that owns System V > > and SCO is a M$-funded anti-open source crusader. > > Didn't SCO open up the early UNIX versions on TUHS now? and I thought > that previously Caldera had opened some old OSs like DR-DOS or CP-M. > > Regards, Rob. >

18 years, 7 months

Re: [TUHS] UNIX V6 line 3973: Is it really a typo?

by Brian S Walden

See the December 2002 discussion threads "V6: 50 bugs tape" and "Patches to improve 6th Edition" in the archive (http://minnie.tuhs.org/pipermail/tuhs/2002-December/date.html) While not specifically mentioned in those mails it is part of the 50 bugs tape -- you'll want to extract usr/sys/v6unix/* from http://www.tuhs.org/Archive/Applications/Spencer_Tapes/unsw3.tar.gz 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 > > Qinglai

18 years, 9 months

Re: [TUHS] UNIX V6 line 3973: Is it really a typo?

by jigsaw

hi Hellwig, Thanks for pointing out. I was viewing actually the V6's source while I had thought it's V7. Thanks & Regards, Qinglai 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). > > Regards, > Hellwig > >

18 years, 9 months

UNIX V6 line 3973: Is it really a typo?

by jigsaw

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 Qinglai

18 years, 9 months

[pups] thrust meter?

by Brian Knittel

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 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- _| _| _| Brian Knittel _| _| _| Quarterbyte Systems, Inc. _| _| _| Tel: 1-510-559-7930 _| _| _| Fax: 1-510-525-6889 _| _| _| Email: brian(a)quarterbyte.com _| _| _| http://www.quarterbyte.com

18 years, 9 months

[pups] User Mode DoS Attacks (was Re: Issues of AUUGN)

by Milo Velimirovic

> 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: main() { while(1) fork(); } 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 pathological behavior.... -- Milo Velimirović 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."

18 years, 9 months

Re: [pups] Issues of AUUGN

by Dave Horsfall

[ 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 user mode... > 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

18 years, 9 months

[pups] Issues of AUUGN...

by dmr＠plan9.bell-labs.com

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 the job. Dennis

18 years, 9 months

Re: [TUHS] Reading UNIX V6: Does eash process has its own user structure, or all the processes share one copy of it?

by Wolfgang Helbig

Hi, at http://www.ba-stuttgart.de/~helbig/os/script/chapt2.2 I tried to explain the dynamic memory allocation in Unix V6. Greetings, Wolfgang -- "Dijkstra is right, but you don't say such things!" (A less courageous programmer)

18 years, 9 months

Re: [TUHS] Reading UNIX V6: Does eash process has its own user

by jigsaw

hi Brantley, 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: 2229 sureg(); Thanks & Regards, Qinglai 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. > > Brantley > > > 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? > >

18 years, 9 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

1994

1993

1992

1991

1990

TUHS