Claude Shannon passed away on this day in 2001.
Regarded as the Father of Information Theory, I doubt whether you'll go
through a day without bumping into him: computers, electronics, file
compression, audio sampling, you name it and he was probably behind it.
Please take a moment to remember him.
--
Dave Horsfall DTM (VK2KFU) "Bliss is a MacBook with a FreeBSD server."
http://www.horsfall.org/spam.html (and check the home page whilst you're there)
> From: Mark Longridge
> There's no reason for it to be mode 777 is there?
Not that I know of. Once UNIX has booted, it has no use for 'unix' (or
whatever file it booted from), and the boot loader doesn't even read the mode.
I think I habitually set mine to 644. (The 'execute' bits are, of course,
pointless...)
Noel
I just had it brought to my attention that the unix kernel is mode 777
in Unix v5 and v6:
ls -l /unix
-rwxrwx 1 root 27066 Mar 23 1975 /unix
There's no reason for it to be mode 777 is there? It seems rather dangerous.
In Unix v7 it defaults to mode 775 and in 32v it is 755. I figure it
setting it to mode 755 will work and so far it seems fine in v5.
Mark
> From: Dave Horsfall <dave(a)horsfall.org>
>> Once UNIX has booted, it has no use for 'unix' (or whatever file it
>> booted from)
> Didn't "ps" try and read its symbol table?
Sorry, meant 'UNIX the monolithic kernel'; yes, ps and siblings (e.g. iostat)
need to get the running system's symbol table.
> I had fun days when I booted, say, "/unix.new", and "ps" wouldn't
> sodding work...
Know that feeling! I added the following to one of the kernel data files:
char *endsys &end;
and then in programs which grab the system's symbol table, I have an nlist()
entry:
"_endsys",
with the follwing code:
/* Check that the namelist applies to the current system.
*/
checknms(symfile)
char *symfile;
{ char *chkloc, *chkval;
if (nl[0].type == 0)
cerror("No namelist\n");
chkloc = nl[ENDSYS].value;
chkval = rdloc(chkloc);
if (chkval != nl[END].value) {
cerror("Symbol table in %s doesn't match running system\n",
symfile);
}
}
on the theory that pretty much any change at all is going to result in a
change in the system's size (and thus the address of 'end').
Although in a split I/D system, this may not be true (you could change the
code, and have the data+BSS remain the same size); I should probably check
the location of 'etext' as well...
Anyway, a rebuilt system may result in the address of 'endsys' changing, and
thus the rdloc() won't return the contents of the running system's 'endsys',
but the chances of an essentially-random fetch being the same as the value of
'end' in /unix are pretty slim, I would say...
Noel
> From: Jacob Ritorto
> found a copy here, i think..
Ah, thanks.
You might want to look around in the parent directory; apparently there are
two differences between the 11/34 and 11/40, other than the clock and switch
register: the stack limit register, and different handling of
segmentation-violation aborted instructions (which affects instruction
restart on stack extension).
I don't know about 2.9, maybe it knows about these. For V6, the SLR won't be
an issue; the SLR is an option on the 11/40, so not all machines had it, and
m40.s in V6 doesn't use it. The instruction restart thing sounds like it will
be an issue with running V6 on a /34.
Noel
Would anyone know if it's still possible to just replace the platters and
clean the heads?
If the heads are really crashed, the only safe course is
to replace both the damaged heads and the damaged disk pack.
Anything else admits a substantial risk of carrying the
crash forward.
Cleaning the heads probably isn't an option; when they
crash, they don't just pick up material from the disk
platter, they may themselves be damaged enough that sharp
bits of the heads themselves are sticking out.
Norman Wilson
Toronto ON
> From: Noel Chiappa
> apparently there are two differences between the 11/34 and 11/40, other
> than the clock and switch register
Too early in the morning here, clearly... I was thinking of the 11/23 and the
11/40 here in the clock/SR comment, not the /34 and the /40.
_Iff_ the 11/34 is using the standard DL11-W console interface board (which
includes an LTC), there's no difference that I know of between the 11/34 and
the 11/40 on the LTC front (although the LTC is an option in the /40, so a /40
might not have one, in which case the V6 will panic on trying to boot unless
it has a KW11-P).
As for the switch register... I guess that on machines with a KY11-A, there
is no switch register? (Too lazy/busy to go read the manual(s) to confirm...)
Noel
> From: Jacob Ritorto
> I think it's something to do with the fact that he compiled it to run on
> an 11/23. Maybe it lacks unibus support.
No, the UNIBUS and QBUS appear (from the programming level) to be identical.
There are subtle differences (the /23 and its devices can address more than
256KB of memory, and some devices have minor differences between the QBUS and
UBIBUS - e.g. the QBUS DZ has only 4 lines, not 8), but in general, they
should be interchangeable.
> Maybe something to do with clock differences.
Again, if it boots at all, that's not it. (The vanilla /23 doesn't have a
software-controllable clock, and when booting Unix on one, one has to leave
the clock switched off till UNIX is running - at least, for the early versions
of UNIX.)
> I fired 2.9MSCP up in simh emulating an 11/23 and it works fine. Just to
> corroborate my hardware experience of it on the '34, I switch the cpu
> emulation to 11/34 and got a mostly identical crash sequence as with my
> real hardware.
Ah. Now we're getting somewhere! If the simulator crashes in the same way, it's
not flaky hardware (my first guess as to the cause).
What are the symptoms (in as much detail as you can give us)? What, if anything,
is printed before it dies?
> I changed ...
> UNIBUS_MAP = 0
> to
> UNIBUS_MAP = 1
The /34 doesn't have a UNIBUS map.
Noel
> From: Jacob Ritorto
> I jiggled the memory board and the seqfault went away.
Ugh. A flaky. I hate those....
> So now the real box is behaving more like the simh and just hanging,
> not panicing anymore.
Does it _always_ hang at the same point in time? If so, what are the
circumstances, - have you just tried to start multi-user operation, or what?
> How can I find this startup() you mention?
It's in machdep.c in sys/sys.
Noel
