TUHS

tuhs@tuhs.org

6420 discussions

Re: [pups] 2.11BSD device config trouble

by Steven M. 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

21 years, 9 months

[pups] 2.11BSD device config trouble

by Jochen Kunz

Hi. I am preparing my PDP-11/73 for my exhibition at the VCFe. I wane get the DHV11 (M3104) and a four port DLV11J colne to work. At the moment I get upon boot: autoconfig: warning: more than three handlers for device cn on line 38. 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 Extract from /etc/dtab: # grep '^[a-zA-Z]' /etc/dtab dhv ? 160440 310 5 dhvrint dhvxint # dhv terminal mux ra ? 172150 154 5 raintr # uda50, rqdx1/2/3 ra ? 160334 764 5 raintr # uda50, rqdx1/2/3 rx ? 177170 264 5 rxintr # rx01/02 tms ? 174500 260 5 tmsintr # tmscp driver ts ? 172520 224 5 tsintr # ts11 driver cn 1 176540 344 5 cnrint cnxint cn 2 176550 354 5 cnrint cnxint cn 3 176560 364 5 cnrint cnxint What is wrong with the "cn" devices? I checked the CSRs of the DHV11 and the DLV11J cards with the "show qbus" command on a MicroVAX 4000-200 to be sure that the CSRs are where I am expecting them: >>>sh q Scan of Qbus I/O Space -20000120 (760440) = 009D DHQ11/DHV11/CXA16/CXB16/CXY08 -20000122 (760442) = F081 -20000124 (760444) = 0000 -20000126 (760446) = 0000 -20000128 (760450) = 0000 -2000012A (760452) = 0000 -2000012C (760454) = 0000 -2000012E (760456) = 0000 -20001940 (774500) = 0000 TQK50/TQK70/TU81E/RV20/KFQSA-TAPE -20001942 (774502) = 0BC0 -20001D60 (776540) = 0000 DLV11J -20001D62 (776542) = 0000 -20001D64 (776544) = 0080 -20001D66 (776546) = 0000 -20001D68 (776550) = 0000 DLV11J -20001D6A (776552) = 0000 -20001D6C (776554) = 0080 -20001D6E (776556) = 0000 -20001D70 (776560) = 0000 DLV11J -20001D72 (776562) = 0000 -20001D74 (776564) = 0080 -20001D76 (776566) = 0000 -20001F40 (777500) = 0020 IPCR -20001F70 (777560) = 0000 -20001F72 (777562) = 0000 -20001F74 (777564) = 0080 -20001F76 (777566) = 0000 -- tschüß, Jochen Homepage: http://www.unixag-kl.fh-kl.de/~jkunz/

21 years, 9 months

cross reference tool for pre-K&R C

by nao

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

21 years, 9 months

Re: [TUHS] 2.11BSD license question: porting software to NetBSD

by Igor Sobrado

> 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

21 years, 9 months

2.11BSD license question: porting software to NetBSD

by Igor Sobrado

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

21 years, 9 months

Re: TUHS digest, Vol 1 #145 - 2 msgs

by Larry McVoy

> I am fairly sure that 4.2BSD had manual pages for mmap, but it didn't > work. Right. Joy left Berkeley and joined Sun and the work got done at Sun. I'm pretty sure that SunOS 4.0 was the first release with mmap working as it was described. I was at Sun for the 4.1 release; 4.0 was the new VM system, and it wasn't "new" like "we changed some stuff", it was new as in everything was rewritten. The 4.0 VM system had segmap, read/write were implemented with segmap in the kernel (you did a read, the kernel mapped page, started a bcopy and would fault on itself if the page wasn't there or had no TLB entry). Etc. I have postscript of the papers on that, still very good reading if someone wants them. -- --- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm

21 years, 9 months

Did SunOS 3 have mmap(2)?

by Warren Toomey

Hi all, I just received a query: did SunOS 3 have a working mmap(2)? My vague memory says no, but I don't have access to a 3.5 box any more to find out. Can anybody help out here? Warren

21 years, 9 months

[pups] ISO9660 filesystem on 2.11BSD

by David Evans

Has anyone tried to do such a thing? Would anybody care? -- David Evans (NeXTMail/MIME OK) dfevans(a)bbcr.uwaterloo.ca Ph.D. Candidate, Computer/Synth Junkie http://bbcr.uwaterloo.ca/~dfevans/ University of Waterloo "Default is the value selected by the composer Ontario, Canada overridden by your command." - Roland TR-707 Manual

21 years, 9 months

Re: [TUHS] PDP11/34 boot problems, here i am again :)

by Carl Lowenstein

> From: asbesto <asbesto(a)freaknet.org> > To: tuhs(a)tuhs.org > Subject: [TUHS] PDP11/34 boot problems, here i am again :) > > well, i think now we have a more complete knowledge of the REAL > problem ! > > the M7891 board (128K x 18 bit MOS MEMORY MODULE) have the D2 red=20 > led light turned ON when turning on the CPU ! > > this means PARITY ERROR on this board :( > > checking the board we found 2 problems: > > 1) a 74LS175 chip named E15 on our schematic diagram, that seem > phisically BROKEN on an edge (there is a fessure on the plastic > DIP package). i can't change it now because i don't have a=20 > soldering station here to do a nice job, but looking the chip i > think it may work... While you probably _do_ have a real hardware problem with the broken IC, I think that the red Parity Error light on first turn-on is normal behavior. The MOS memory comes up with random values, and about half of them will have the wrong parity. Some software routine must turn off parity error detection and write a known data pattern (all 0's) to each memory location. I don't remember whether this is something that is done by the boot ROM of an 11/34. carl -- carl lowenstein marine physical lab u.c. san diego clowenst(a)ucsd.edu

21 years, 9 months

RE: [TUHS] PDP11/34 boot problems, here i am again :)

by Gooijen H

"asbesto" wrote: > 1) a 74LS175 chip named E15 on our schematic diagram, that seem > phisically BROKEN on an edge (there is a fessure on the plastic > DIP package). i can't change it now because i don't have a > soldering station here to do a nice job, but looking the chip i > think it may work... I never remove IC's in *one* go. The chances that you damage the multi-layer board beyond repair are real. This is what I do. I use a dremel tool (small motor with sharp rotating blade) to cut the pins of the IC one by one. Don't use a cutting tool to cut the pins because the side force might push the remainder of the pin through the solder joint thus damaging the board. After you have cut all the pins the IC just falls of the board. Now, you can use a fine hot soldering iron and remove the pins one by one use a pair of squeezers. good luck with your repairs, - Henk.

21 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