I've assembled some notes from old manuals and other sources
on the formats used for on-disk file systems through the
Seventh Edition:
http://www.cita.utoronto.ca/~norman/old-unix/old-fs.html
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.)
In article by Robertdkeys(a)aol.com:
> Warren... is there a non-broken 4.3BSD-Tahoe set somewhere?
> Bob
As in a bootable 4.3BSD-Tahoe kit? As far as I know, no. The Unix Archive
has a broken copy in 4BSD/Distributions/4.3BSD-Tahoe, indicating that
both usr.tar and src.tar are broken.
It might/should be possible to merge files from the CRSG CD set from Kirk
to recreate these tar files.
Anybody out there have an unbroken Tahoe release?
Warren
Hi -
> From: Jochen Kunz <jkunz(a)unixag-kl.fh-kl.de>
> As already mentioned: If I add comments at the end of the lines it
> cn 1 176540 344 5 cnrint cnxint # kl/dl-11 (on mvx11-aa)
> cn 2 176550 354 5 cnrint cnxint # kl/dl-11 (on mvx11-aa)
> cn 3 176560 364 5 cnrint cnxint # kl/dl-11 (on mvx11-aa)
> cn 1 csr 176540 vector 344 attached
> cn 2 csr 176550 vector 354 attached
> cn 3 csr 176560 vector 364 attached
> Sounds like a funny bug?
Yes, it does. A bug in the parsing. Why it does not affect all
the lines is unknown. Perhaps some trailing whitespace caused the
parser to exhibit the bug.
> But if I try to use /dev/ttyl1 I get a message about a unknown interrupt
> and the output of /dev/ttyl1 hangs after the first character.
What is the exact message? I did a "strings /unix" and could not
not find a string that looked mentioned unknown or interrupt.
That would seem to indicate that the device is interrupting but not
at the expected vector.
It is possible to use 'adb' to look at the contents of the vectors.
adb -k /unix /dev/kmem
0344/o
will show the contents of the 0344 vector. The value there should
be equal to 'cnrint' (or cnxint - I forget which comes first).
> I have a M3106 DZQ11 that I can use instead.
Definitely worth trying.
> The DHV is a DEC M3104:
> dhv ? csr 160440 vector 310 didn't interrupt.
> The DL11 card is a clone made by Sigma.
Ah, ok. Thanks for the correction. I misread the initial mail item.
> > 'halt' button?
> [...]
> Noticed that already. I am really not used to Unix stuff of that age.
:)
I did the the same thing - wondered why I could never get a clean
file system. Then I realized what was going on.
Cheers,
Steven Schultz
Hi -
> From: Jochen Kunz <jkunz(a)unixag-kl.fh-kl.de>
> I am preparing my PDP-11/73 for my exhibition at the VCFe. I want to get
> the DHV11 (M3104) and a four port DLV11J clone to work. At the moment I
> get upon boot:
>
> autoconfig: warning: more than three handlers for device cn on line 38.
That is not a normal message. I believe autoconfig is saying that
is something wrong with line 38 of /etc/dtab
> dhv ? csr 160440 vector 310 didn't interrupt.
> ra 0 csr 172150 vector 154 vectorset attached
> ra 1 csr 160334 vector 764 vectorset attached
> rx ? csr 177170 vector 264 skipped: No CSR.
> tms 0 csr 174500 vector 260 vectorset attached
> ts 0 csr 172520 vector 224 attached
> cn 1 csr 176540 vector 344 no address found for kl/dl-11
> What is wrong with the "cn" devices?
Is 'cn 1 ...' line 38 of the /etc/dtab file?
Did you compile a kernel with NKL set to 5 (1 for the console and
4 for the DLV11J)?
Cheers,
Steven Schultz
Hi -
> From: Jochen Kunz <jkunz(a)unixag-kl.fh-kl.de>
> > > cn 1 csr 176540 vector 344 no address found for kl/dl-11
> > Is 'cn 1 ...' line 38 of the /etc/dtab file?
> Yes:
> cn 1 176540 344 5 cnrint cnxint
Interesting. I do not recall any particular problem getting
additional DL devices recognized (the 11/93 had 7 of them).
Seeing the 'no address found' error is *strange* though - that
would indicate that 'autoconfig' could not find 'cnrint' or 'cnxint'
in the /unix symbol table. Look at /sys/autoconfig and you can
see where that message is coming from.
If you do
nm /unix | egrep 'cnxint|cnrint'
what do you see?
> NKL 4 # KL11, DL11
> The card has four ports, one of them is the console. (The M8192 CPU card
> has no SLU / ROM / ...)
Ah, ok. My 11/73 has a SLU/ROM card and the console is on that. I
also have a DHV installed (alas, the system is powered down now
so I can not check for more information).
> But I would prefere to get the DHV11 working. It seams that this device
> is more suitable for multi user operation.
Yes, it's a little better. Not as nice as a DHQ-11 though (which can
run in DHU or DHV modes - with DHU mode having much better silo
handling).
I forget the exact error you were getting on the DHV but if it was
'no interrupt' then it might be that the DHV clone is not behaving
exactly like a DEC DHV
In /sys/autoconfig/dhvauto.c here is how the probing attempts to
force an interrupt:
dhvprobe(addr,vector)
struct dhvdevice *addr;
int vector;
{
if ( grab ( &(addr->dhvcsr) ) & DHV_CS_MCLR )
DELAY(35000L);
if ( grab ( &(addr->dhvcsr) ) & (DHV_CS_MCLR|DHV_CS_DFAIL) )
return ( 0 );
stuff ( DHV_CS_RI | DHV_CS_RIE, &(addr->dhvcsr) );
DELAY(3500L);
stuff ( 0, &(addr->dhvcsr) );
return(ACP_IFINTR);
}
Either 3500 microseconds (very approximately of course) is too short
of a wait _or_ the method of trying to generate an interrupt is
not correct. You can try changing 'ACP_IFINTR' to 'ACP_EXISTS'
which tells autoconf to not care if the device interrupted or not.
> ** Last Mounted on /
> ** Root file system
> ** Phase 1 - Check Blocks and Sizes
> ** Phase 2 - Check Pathnames
> ** Phase 3 - Check Connectivity
> ** Phase 4 - Check Reference Counts
> ** Phase 5 - Check Free List
> BLK(S) MISSING
> SALVAGE? y
>
> ** Phase 6 - Salvage Free List
> 1364 files, 11625 used, 2430 free
>
> ***** FILE SYSTEM WAS MODIFIED *****
>
> But on the next reboot I get the same when running fsck. Any hints?
How are you rebooting? With the "reboot" command or by using the
'halt' button? You do not want to use the 'reboot' command because
that does a "sync" which flushes the disc cache (and superblock) back
out to disc - that overwrites the work that 'fsck' did.
A few 'missing' blocks is not a serious problem though and can be
ignored.
Cheers,
Steven Schultz
Hi!
> From: David Evans <dfevans(a)bbcr.uwaterloo.ca>
> > cn 1 176540 344 5 cnrint cnxint
>
> to the end of this line? Perhaps the autoconfig parser becomes confused
> if there aren't any.
I don't think that's the problem in this case - the error that is
being printed out:
cn 1 csr 176540 vector 344 no address found for kl/dl-11
comes from what appears to be a missing entry (or an entry that
autoconfig can't find) in the /unix kernel symbol table. One way,
I think, this can happen is when booting an alternate kernel (/genunix
instead of /unix).
THe only suggestion I have at this point is to turn on debugging
in autoconfig. To do this go into /sys/autoconfig/main.c and
add a line that forces 'debug = 1;', then install (after saving the
original ;)) autoconfig into /etc and reboot. Hopefully useful
info about what autoconfig is doing will be printed.
> Mine is at least correctly identified by autoconfig, though I've never
> attached a terminal to it to see whether the ports actually do anything.
> The post that's vanished included my dhv line from /etc/dtab but, except
> for the goofy CSR I used for some reason that I cannot now remember, it
If I find the time I'll power up the 11/73 and see what it says but
I've had a DHV11 on the system for years (it's how I got the RTS/CTS
flow control working).
My suspicion is that the DHV clone isn't behaving 100% like a DEC
DHV card.
> > BTW: Never play with the SMD cables when the machine is running. Now I
> > get:
>
> Is the disk write-inhibited?
Doing a 'reboot' (which performs a sync(2) call) will overwrite
what fsck has done - when the message about "reboot" comes out you
should use the front panel or ODT to simply halt the cpu and then
start the boot process cold.
Cheers,
Steven Schultz
Hi,
I really enjoy hacking ancient unix rather seriously and want a cross
reference tools for them. Since some of them are written in pre-K&R C,
modern tools are not very useful. Is there any cross reference tool
for pre-K&R C source codes?
BTW, early UNIX assembler document has bugs which state '>>' and '<<'
are shift operators despite that really '\>' and '\<' are. I wonder
where these bugs came from...
Cheers,
- nao
> On Friday, 18 April 2003 at 18:56:16 +0200, Igor Sobrado wrote:
> >
> > I asked to the people of the NetBSD Foundation about the possibility
> > of adding those commands to the base system (as a part of the tarball
> > with documentation tools) but they think that it is not possible,
> > as a consequence of a licensing issue. I supposed that all the
> > software provided in the 2.11BSD was under a BSD license, but it
> > looks like 2.11BSD is a closed source release.
>
> That's not correct any more. Who were you talking to at the NetBSD
> project?
Hi Greg.
I am worried with possible licensing issues with AT&T's Documenter's
Workbench (DWB). In fact, AT&T retained the copyright and distribution
rights on those parts of the UNIX documentation tools they developed
some years ago. That is the reason we have [nt]roff, but not
diction (diction(1), explain(1), suggest(1)) and style(1).
Last days, Perry E. Metzger observed that 2.11BSD was closed source:
"And it is closed source. Sorry. We aren't allowed to use code that did
not originate in V7/32V. If Caldera did not specifically release the
sources, we cannot use them. If your claim is that diction and style
were not in 32V, then we have no rights to them."
Well, in a previous email Perry observed that:
"I appreciate all this and I thank you for doing the work, but please
do your work against a version we have clear ability to use."
In short, he does not says that "we cannot add diction(1) and style(1)
to NetBSD" only that *license terms are NOT clear*.
What I do *not* want to do, is asking for adding a piece of code
that will report problems to the NetBSD Foundation. They are
doing a superb job, and I do not want to start a legal problem
adding some tools whose license is not clear.
On the other hand, Steven M. Schultz observed that "Not 100% - much of
it is covered by the BSD license and the Caldera/SCO/whatever license(s)".
I believe that diction(1) and style(1) are covered by a different
license agreement, but I did not find it in the source code.
> > Can someone, please, helping me on this matter? What should I do?
> > Should I just drop this software?
>
> We discussed the Caldera release of "ancient UNIX" on this mailing
> list recently. Caldera (now SCO again) was supposed to make some kind
> of official statement, but it's taking its time.
Well, there are some operating systems under Caldera's agreement
(a BSD-style license), including v7 and 32V, but looks like 2.11BSD
is *not* under those terms. In fact, it is not available through
Caldera, it is in tuhs, not covered by Caldera's license agreement.
(at least I think that it is right...)
I am not a lawyer, only a Physics grad student working on a Ph. D.
on CS. I have no idea about the legal status of 2.11BSD or, to
be more precise, about the status of diction(1) and style(1).
Cheers,
Igor.
--
Igor Sobrado, UK34436 - sobrado(a)acm.org
Hello.
I have just finished porting diction(1) and style(1) from 2.11BSD
to the NetBSD operating system. Those utilities are a part of the
AT&T Documenter's Workbench (DWB), and are not available on the v7
and 32V UNIX releases.
I asked to the people of the NetBSD Foundation about the possibility
of adding those commands to the base system (as a part of the tarball
with documentation tools) but they think that it is not possible,
as a consequence of a licensing issue. I supposed that all the
software provided in the 2.11BSD was under a BSD license, but it
looks like 2.11BSD is a closed source release.
Can someone, please, helping me on this matter? What should I do?
Should I just drop this software?
Cheers,
Igor.
--
Igor Sobrado, UK34436 - sobrado(a)acm.org
