mbm@mit-cipg@mit-mc (02/14/83)
To: csvax.2bsd-bugs@ucb-c70, unix-wizards@sri-unix Subject: Not enough core This error (ENOMEM) is returned in the berkeley pdp11 systems if a fork is attempted and there may not be enough swapping area available, in an effort to prevent "no swap" panics. This is a confusing choice of error code, because the manual (intro(2)) explicitly says ENOMEM does not indicate a temporary condition, but a permanent limitation of the system; this program is too big to run. I believe the vax systems also generate this error if the paging area appears insufficient. --mike
PGS%MIT-OZ@MIT-MC (03/18/83)
A friend of mine who is working in Japan is seriously in need of a 6809 macro assembler (preferably written in C) to run under Unix. I seem to have heard of a cross-assembler that ran under Unix once upon a time, but I don't remember if it assembled 6809 code or not. The reason he would prefer it were written in C is because they are about to purchase a development system that will run Unix, but they are not sure what the development system's processor will be; it may be a 68000, or an 11, or a z8000. They could presumably coerce a cross-assembler written in C to run on whatever they come up with. Thanks, replies to PGS@MC.
ron@Brl-Bmd.ARPA (03/28/83)
From: Ron Natalie <ron@Brl-Bmd.ARPA> Combining two of the recent discussions, how many of you used to find files called "p&P6" in their directories (those are the printing characters. The rest were the SETD and other instructions in crt0.o up to the first null). Even printf used to dump them on our terminals until it was trained to print "(null)" if 0 was passed to a %s field. - Ron
muha%bbn-unix@sri-unix.UUCP (06/14/83)
From: Ralph Muha <muha@bbn-unix> Is there an echo around here?
cpr%Shasta@sumex-aim@imagen.UUCP (08/06/83)
Has anyone noticed that 4.1a/c and 4.2 Unix DO NOT speak true TCP/IP on
Ethernet? They speak a private protocol that involves the use of trailing
IP headers for some packets for efficiency's sake. I'm all for efficiency,
but shouldn't they negotiate the use of these trailing IP header packets
before using them? (I've only verified this is true for 4.1a, and I've been
told it's true for 4.1c and 4.2.) Doesn't this bother anyone? I guess
everyone is assuming they'll have sources, and will go in and turn off the
trailing IP header code if they want to talk to a non-Berkeley Unix system.
I claim this is a crime. This software is being touted as running TCP/IP,
and, in fact, it isn't.
Where is the outcry?
/Chris Ryland, IMAGEN
(arpa: CPR@MIT-XX, g.ryland@Score; uucp: {decvax, shasta, ucbvax}!imagen!cpr)cpr%Shasta@su-score@imagen.UUCP (08/10/83)
I must re-state my flame concerning 4.2bsd Unix TCP/IP implementation problems. 4.2 fails to comply with a de facto standard for encapsulating IP packets on 10mb Ethernet. I hear from MIT that this is about to become a DoD standard, so then my flame will be valid: 4.2 doesn't implement TCP/IP on Ethernet properly. As Bill Shannon suggests, people supporting 4.2 will probably have to adapt it to talk with other implementations which don't support the trailing-IP-header packet type. Negotiation with private TCP options doesn't seem to be a bad idea; I don't quite understand Bill's comment that "it's another layer of software." I think it's just a private negotiation, just like the maximum segment size negotiation (though the TCP purists may exclaim that mixing this level (IP encapsulation) with the TCP level is a violation of aesthetics). Again, I'm truly amazed that no one has yelled at Berkeley for this deviation. As 4.2 comes out, and everyone tries to connect up to their other TCP/IP Ethernet implementations, fur is going to fly. /Chris Ryland, IMAGEN
cpr%Shasta@su-score@imagen.UUCP (08/10/83)
Re: a public-domain 68k port. I find it amusing that such a port to the Pacific Microsystems 68010 board is really just an "old SUN board" port (which SMI did, and now will leave behind with the SUN II's).
BYTE@mit-mc@sri-unix.UUCP (09/01/83)
From: Roger L. Long <BYTE@mit-mc> I know that recent messages have said there isn't any documentation on UMODEM, but before I go and write some, I'd like to make sure. Has anyone already written a `man' entry for UMODEM? (for those who aren't aware, UMODEM is a program that allows file transfers between UNIX and CP/M systems). Thanks... -roger
rconn@brl@sri-unix.UUCP (09/01/83)
From: Rick Conn <rconn@brl> I'm not aware of a man entry for UMODEM. Lauren Weinstein (the original author) or Keith Petersen are good sources who may know of one. Rick
jazzy@aerospace@sri-unix.UUCP (09/03/83)
From: Richard Fitzgerald <jazzy@aerospace> In reply to your message asking for suggestions, here are a few based on what we have running on a 750 at my site. First of all, the best (and cheapest(?)) was to swap out the old memory controller for a new 64k chip controller. We now have a full 8 meg on a 750. Makes one heck of a difference, also an FPA was added, since we do heavy INTEL processor development work on the machine and it needs the FPA. Second was the removal of all interrupt driven devices from the unibus, either totally, or replaced by a newer device (dz-11 -> dh/dm or vmz-32) which does dma. Anything and everything on the unibus of a 750 kills any performance you might see if it is interrupt driven. Especially if you are in to heaving editing as you say. Third, and perhaps the best, was the total replacement of all disk drives including the system disk (was an rk07 *ugh*) with Fujitsu Eagles. The important thing here is to put the system Eagle and the user Eagle(s) on their own MBA's! This made a tremendoues improvement in overall performance, and in fact we can even use the 750 as a real computer now! These additions may seem costly, but you can play with prices and mix and match the above to acheive a compromise. The new memory controller with 2 meg installed was only $10K, and since each additional (trendata) memory board was only $2900, it was not too bad. The Eagles were purchased from S.I. for about $18K (which includes an MBA AND 9900 controller) each for the first two (to give the 2 MBA's) and then add on drives (we have 2 user drives and 1 system drive) are about $16K. Overall, UNIX will perform quite well under this, and rather than go into details on this message (I hate long mail) perhaps we can talk more about the Unix configuration side of this in a future letter. However I have seen most of our performance come from the new hardware and not much unix twiddling. By the way, we are running anywhere from 30-64(max) users on this machine, running edits and such. Response is not fantastic when you get above 32, but much better than I have seen elsewhere. -Rich Fitzgerald (jazzy@aerospace)
mab@ucla-locus@csun.UUCP (09/21/83)
At CSUN, games are run through a restriction program which is suid and which accesses games in a specific directory. The variable "SHELL" and the varaible RSHEL are used to control his access. If SHELL is not already set, it is set to his default shell. RSHEL is set to refer to a program which will restore his uid, and exec his default shell. Any program placed into the games directory is edited (with adb for those games we dont have source to) to use the RSHEL variable where it otherwise used SHELL. Any binary that was hardcoded to refer to a specific shell gets edited to refer to our 'drop-shell'. This way, users who spawn shells from their game, get to be themselves. See any problems with this? Oh yes, the restrict program does a nice(20) too. rogue players love this (heh-heh). Michael A. Bloom California State University, Northridge
LAURA%mit-oz@sri-unix.UUCP (09/29/83)
a/ please remove me from your list. b/ why does ..-request lose on arpa?? Patrick.
SHAWN%mit-ml@sri-unix.UUCP (10/06/83)
From: Shawn F. McKay <SHAWN@mit-ml> Question:: Is there anyone out there, who has a list of public domain programs for Unix?? If so, please send me a copy, or get in touch with me, as I would love to see what's around. If there is interest, and no one out there seems to be doing (have done) this, I will try to get ahold of all notices of public domain stuff under unix, and do my best to make available this list to anyone who asks. Thanks, Yours In Hacking, -Shawn P.s. If anyone out there has public domain stuff and would be willing to be part of something like this, please send me the following info: 1) Name of program, 2) What program does, 3) Who to get in contact with, 4) If its available via ftp, or uucp, 5) Any special conditions, 6) Who to send bugs to, if bug reports are requested, (if requested, Please specify)
wise%seismo@cal-unix.UUCP (10/19/83)
Please delete me and delete Rick Wilder (rlgvax!cal-unix!rick@seismo) from the mailing list. rlgvax has complained about the volume of information. However, having seen what's on the unix-wizards list, I've been able to convince the powers-that-be to let us subscribe to net.unix-wizards. I apologize for causing you the work of adding then deleting me. Rick Wilder should be sending you a similar message, if you have doubts about removing his name on my say-so. Thanks for your help. Rick Wise
brad@bradley.UUCP (10/21/83)
#R:sri-arpa:-1244400:bradley:3900002:000:81 bradley!brad Oct 20 08:59:00 1983 Yea, I would like to see a listing of the programs if there is one. Brad Smith
KenWhaley@BRL-VGR.ARPA,whaley@lbl-csam (10/21/83)
:Re: editor for /usr/lib/vfont We are near completion of a font editor for the /usr/lib/vfont font files. It is text oriented, and thus will work with any terminal that can run on UNIX, with any text editor. Indeed the glyphs look better on some terminals than on others, and it's not intended to be used for designing fonts: just for "cleaning up" obvious mistakes in character sets. For example, one of our bracket-building characters is simply TOO SHORT...it's missing some bits. Some other features will be: move glyphs between fonts; move the baseline and width markers around; etc. We hope to release it with some version of BSD. Address any questions or comments (or suggestions!) to: whaley@lbl-csam ucbvax!lbl-csam!whaley -- Kenneth Whaley Lawrence Berkeley Laboratory Berkeley, California.
BRADST%MIT-OZ@MIT-MC.ARPA (11/19/83)
-------
bassen%nta-vax@sri-unix.UUCP (11/30/83)
From: Tor Sverre Lande <bassen@nta-vax> At our institute we have a couple of LA100 printers. Here is a couple of questions: 1) Does anybody have a nroff-definition for LA100? 2) Our LA100 only uses 1/2 of the ribbon. Does anybody know a method of how to use the other half? 3) Does anybody have experience with extra fonts (in ROM) used with nroff? In real life: Tor Sverre Lande Institute of Informatics, University of Oslo, Norway
vlsi.tg@SU-SIERRA.ARPA (01/08/84)
From: Thomas Gross <vlsi.tg@SU-SIERRA.ARPA> Recently, on of our disks "crashed". We heard by rumor of companies that specialize in the recovery of damaged or crashed disks. Does anybody have experience with these services or know a company that provides this service. The disk in question is a Fujitsu Eagle, and to the best of our knowledge, the head has not touched the surface yet. Any help or suggestion is appreciated. Please mail your replies to "trg@shasta". thomas gross ------- -------
cpr%su-shasta@imagen.UUCP (01/20/84)
Could someone give a UniForum review, at least of the new products and interesting talks? --Chris Ryland, IMAGEN
whaley%lbl-csam@sri-unix.UUCP (02/02/84)
From: (Ken Whaley [cc])whaley@lbl-csam
:re: speed improvements for troff.
We have two 11/70's running version 7 UNIX that are basically dedicated to
text processing. Therefore, most of the users are either running "vi" or some
form of nroff/troff (30 users per machine is typical during a normal work day).
The turnaround on vtroff (out main troff output device is a Versatec V-80) was
very slow, and "vi" was suffering too, because of all the n/t/roffs. Our
solution was to do (as I believe was suggested in an earlier reply) a queuing
system that would:
1) Be written in C (so as not too have the old vtroff's overhead of
additional processes), and be faster (if not by a whole lot).
The queueing algorithms can be easily changed (see end of note)
2) Queue troff INPUT, not output, so the apparent execution time
of "vtroff" is increased GREATLY. This is the main idea,
because only one troff is running at any given time.
(The output of troff IS queued to wait for the device.)
This system is MUCH nicer as far as working on the computer is
concerned. The actual time it takes for the device to spit out the document
is increased, just how long depends on the number of documents waiting to be
processed. However, it seems that waiting a little longer for final output is a
small price to pay for a more responsive computer. If there is an interest in
more detailed performance improvements, I'll post them to the net.
Ken Whaley ( whaley@lbl-csam )
Computer Services department, Computation Division
Lawrence Berkeley Laborartory
p.s. We run DITroff, but this doesn't change the concepts here.
p.p.s. One advantage to writing the queue handling programs in C (as apposed to
shell scripts) is that they are easy to modify (if written half decently).
To give an example, we just recently added a "priority" option to vtroff, with
the ability to specify rush jobs, deferred jobs, and "hold" jobs that will do
nothing until an operator starts it up.NEP.FOUTS%ames-vmsb@sri-unix.UUCP (02/07/84)
I am looking for a dr11c driver (ct.c) for the symbolics laser printer under 4.1c. Has anyone fixed the symbolics stuff so that it will run under 4.1c? nep.fouts@ames-vmsb ------
NEP.FOUTS%ames-vmsb@sri-unix.UUCP (02/07/84)
I need a running version of uucp for 4.1c. Anybody know where I can get one? nep.fouts@ames-vmsb ------
cak@Purdue.ARPA (02/08/84)
From: Christopher A Kent <cak@Purdue.ARPA> Yes, our response was the same. Our original VAX was usually swamped with about 30 people, 6 or 7 of them with troffs running in background, all getting nowhere. Bob Brown wrote a general job serializer, with multiple classes, organized so at most one job in each class is running. We currently have three troff input queues -- normal, big, and huge. Huge only run at night. Jobs are placed in the appropriate queue by length, and run shortest job first within a queue. So we have two or three troffs running at time, mean time to output is better, and everyone is happier. We also use the serializer for some of our output device spoolers; the win is that the same queue control commands are used for all these different services. I expect that this software could be made available, but don't know the details. Cheers, chris ----------
saj@iuvax.UUCP (02/15/84)
#R:sri-arpa:-1411400:iuvax:1200004:000:119 iuvax!saj Dec 2 18:56:00 1983 In addition, does anyone have the "plot" driver for an LA100? Thanks, Scott Jones Jones@Indiana ihnp4!inuxc!iuvax!saj
gwyn%brl-vgr@sri-unix.UUCP (03/03/84)
From: Doug Gwyn (VLD/VMB) <gwyn@brl-vgr> Oh, good grief. Don't make /usr/spool/mail publicly writable: $ mv /usr/spool/mail/me /usr/spool/mail/me.keep $ mv /usr/spool/mail/you /usr/spool/mail/me $ mail ...
alt%sri-tsca@sri-unix.UUCP (03/06/84)
> Oh, good grief. Don't make /usr/spool/mail publicly writable: > > $ mv /usr/spool/mail/me /usr/spool/mail/me.keep > $ mv /usr/spool/mail/you /usr/spool/mail/me > $ mail ... Better than that, you can use 'mail -u user'. An undocumented (I think) Berkeley mail option. This lets you pretend that you are that user, and play with the mail however you want. The only real problem is that it writes undeleted read mail into your mbox rather than his. I have often thought that it is a pretty silly option to have... Howard.
whaley%lbl-csam@sri-unix.UUCP (03/20/84)
From: (Ken Whaley [cc])whaley@lbl-csam :Re:versatec printers and fan fold paper. > From unix-wizards-request@BRL-VGR.ARPA Fri Mar 2 12:37:32 1984 > Received: from BRL-VGR (brl-vgr.ARPA) by lbl-csam.ARPA ; Fri, 2 Mar 84 12:37:32 pst > Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 2 Mar 84 15:02 EST > Received: From Purdue-Merlin.ARPA by BRL via smtp; 2 Mar 84 14:38 EST > From: Christopher A Kent <cak@Purdue.ARPA> > Message-Id: <8403021959.AA12877@merlin.ARPA> > Received: by merlin.ARPA; Fri, 2 Mar 84 14:59:07 est > Date: 2 Mar 1984 1459-EST (Friday) > To: unix-wizards@brl.ARPA > Subject: versatec printers and fan fold paper > > We have a Versatec 1200A on our VAX (4.2) that we use for troff output, > among other things. We choose to use fan fold paper instead of roll > paper; it's so much nicer not to have to cut up your output on a paper > cutter. > > Unfortunately, this is not all roses. All the standard macro packages > insist on just putting out cut marks as part of the footer, and in > order for us to use them, we have to hack them to put out a special > command that causes a hardware form feed. It works fine, once the > macros are fixed. > > We have just recently converted to 4.2, and I tried to use vgrind for > the first time last night, and discovered that its macro package hadn't > been so hacked. I didn't feel up to it, but started thinking about the > problem again. It's really a pain to have to modify every macro > library; they're not portable, and we can't easily import other > people's macros. Besides, we now have a Symbolics laser printer that > understands cut mark page marks, so we either have two copies of each macro > package or magic in the macro package to understand the output device; > both undesirable. > > It seems like the vcat program should be able to look for the cut marks > and do the right thing. I inquired about this (I wasn't involved in the > original solution), and was told that the cut marks don't always come > out evenly spaced; they sometimes actually come out slightly over a > page fold, so the form feed causes a blank page in the output. Or that > if a person outputs cut marks you might get spurious form feeds. And so > on. > > On the other hand, I said to myself, the people that print troff output > on 11" wide plotters after rotating must know where a page ends; how do > they do it? Indeed, I can't believe that EVERYONE goes through this > crap like we do! After all, the Symbolics printer seems to be able to > parse the cut marks in the output stream. > > So, does anyone have a better solution, or do you all use roll paper? > > Cheers, > chris > ---------- We too have had problems with the cut marks. We have a Versatec V80 running under Version 7 UNIX that uses fan-fold paper. There probably are many solutions, one of which is, as Chris said, modifying the macro packages themselves so as not to output the cut marks. While this is not the most desirable thing to do, there really is no way around it, and the modifications are trivial to do at worst. If you are running only one output device and you are sure that you never want cut marks, then delete or comment out the line(s) in the macros that put out a ".tl (something)" line. However, we, like most systems, output to different devices; so we chose to do something a little different. Instead of just deleting the reference to the ".tl (cut marks)", we changed it to "if !\nv .tl '\(ru'..'\(ru'". This conditions the printing of the title line on the value of a number register (we called it "v"). So then all typesetting to devices where cut marks are NOT wanted is: troff (or ditroff) [normal options...] -rv1 which sets the number register "v" to 1, and thus the ".tl ...." is not processed. Kenneth Whaley Systems Group, Computer Services Lawrence Berkeley Laboratory Berkeley, CA. whaley@lbl-csam.ARPA ...ucbvax!lbl-csam!whaley
whaley%lbl-csam@sri-unix.UUCP (03/20/84)
From: (Ken Whaley [cc])whaley@lbl-csam :ditroff infinite loop bug. DITROFF has an infinite looping bug. It goes crazy on the following input: .fs this is a footnote. [End of File] In other words, a footnote start without a footnote end causes an infinite loop. The footnote diversion just can't handle the EOF. We have the feeling that any diversion that has to deal with EOF before finding the end-diversion makes DITROFF blow up. The section of looping code has been pinned down (by means of dbx on 4.2 BSD), but those with any knowledge of what the (di)troff source is like can imagine that it's no small task to debug. So if anyone has solved, or is interested in solving, this riddle, please let us know! Kenneth Whaley Systems Group, Computer Services Lawrence Berkeley Laboratory Berkeley, CA. whaley@lbl-csam.ARPA ...ucbvax!lbl-csam!whaley
sean%mit-cogs@sri-unix.UUCP (03/22/84)
Send me mail, please. We are debugging and need an arpa mail source.
----- Mail saved at Wed Mar 14 09:23:02 1984
To: rbn@brl-vgr, sean@mit-ccc@mit-mc
Subject: Re: Adding us
Note: my mailing address is actually sean%mit-cogs@mit-mc
(Our outgoing mailer was buggy at the time the message was sent).
I currently have mail forwarded from mit-ccc, however, so
things will work for a bit, anyway...
----- Mail saved at Wed Mar 14 14:47:26 1984
To: info-unix@brl-vgr
Subject: Pert charts
Has anyone out there written *any* sort of pert chart program?
Preferably with reasonable graphics output (like to plot filters...)
FYI: for those who haven't used them, pert charts are a way of
evaluating projects for resource and personnel needs. Useful for large
systems development projects.
Thanks.
Sean D. True
Department of Brain Science, MIT
sean%mit-cogs@mit-mc
----- Mail saved at Thu Mar 22 09:46:12 1984
To: hartwell@Su-Shasta.ARPA, hnp4!rlgvax!guy@Ucb-Vax.ARPA,
ihnp4!rlgvax!guy@Ucb-Vax.ARPA
SuDSullivan@HI-MULTICS.ARPA (06/27/84)
Subject: Re: VT100 and bagbiting The real problems is "ANSI" computer terminals don't support the FULL protocall. There is a defined character (Data Link Escape or ^P) that whos meaning is "the next character is to lose its meaning". If all ANSI terminal generated this character before all USER generated control sequences then the whole problems disapears for ANSI terminal in that ^S/^Q flow would be unadorned but the user typed ^S would be transmitted as ^P^S. What you have here is the clasic case of Hardware is deficient so the Software has to compensate.
FIRTH%TARTAN@CMU-CS-C.ARPA (06/27/84)
Jack, In answer to your question, it is the language definition that requires args to be stored in consecutive cells. In fact, the BCPL Standard (May 83) defines in Para 2.0 the meaning of "adjacent" storage cells, and then specifies three circumstances in which a collection of cells is adjacent: the Global vactor (2.1.3), a dynamic VEC (6.6), and the actuals of a routine call (5.1). The reason for this last requirement is specifically to permit the actuals of a routine to be treated as a vector (cf Richards: BCPL - The Language and its Compiler), so it's a genuine language feature. It is perfectly proper for a BCPL implementation to pass params in registers (cf the implementations on PDP-11, Vax-11, PE3200), but the called routine must then store them in true memory, unless of course the global optimiser can prove the addresses are never referenced (that's one optimisation I always wanted to put into our codegenerators and never did) Robert Firth -------
gwyn@BRL-VLD.ARPA (06/28/84)
From: Doug Gwyn (VLD/VMB) <gwyn@BRL-VLD.ARPA> Use of an escape like DLE would certainly permit in-band flow control transparently, but I have never heard of this being used by any ASCII terminal. DLEs are usually reserved for protocols like HDLC etc. Is there ANY known general-purpose computer terminal using DLE this way?
cjet%ucbamber.CC@UCB-VAX.ARPA (07/04/84)
Dear Newsletter Editor:
Please include the following flyer (below the dotted line) in your
newsletter. The flyer is being sent by the Center for Jobs Education
and Technology, the non-profit corporation which is the technology
consultant for the Berkeley School District's Model School Project.
Please ignore this request of you have already received one.
If you need more information, please send requests to the address
given on the flyer. Thank you very much,
Eric Novikoff, C-JET
...........................................................................
ANNOUNCING
----------
The opening in September 1984 of a Model School which will develop
new ways to use computers in education for use throughout the Berkeley Uni-
fied School District, the state, and the nation. The District seeks colla-
boration with persons, firms, research organizations, universities, and
others interested in the leading edge of technology in the schools.
FEATURING
---------
* Computer workstations on local area networks
* Many workstations per classroom
* Computers used to teach regular curriculum
* Computers used for classroom and school administration
* Total Integration, including persons with physical and mental
disabilities in the classroom
* Collaboration by prominent members of business and faculty from
the University of California at Berkeley toward curriculum design
and technology integration
* A site for research, development and demonstration of effective
use of educational technology
REQUEST FOR INFORMATION
-----------------------
We desire information about advanced hardware or software systems that
could be acquired for use in the Model School. In addition to computers,
courseware, and networks, the District is interested in peripherals that
address the needs of younger children and children with disabilities, such
as special keyboards, graphic displays, voice synthesisers, etc.
The Berkeley Unified School District is investing substantial funds in the
school, staff and technology. We seek collaboration, sponsorship, assis-
tance and state-of-the-art products. People of many disciplines, skills and
viewpoints are working together to make major advances. We invite you to
explore fuller involvement and/or participation in any of the major aspects
of this exciting project. Please contact us at cjet@amber@berkeley or call
(415) 527-9030.bob@SU-SHASTA.ARPA (08/09/84)
Subject: Re: What is the root inode number in BSD 4.2
In 4.2bsd ROOTINO is defined in /usr/include/sys/fs.h as 2 typecast to ino_t.
I do 'grep thing /usr/include{,/sys}/*.h' a lot working closely with both
4.2 & Sys -V. You'll also want to include /usr/include/sys/types.h.
Many system things are in different include files under 4.2bsd. My comments
about that are not printable.
Bob Toxen
Silicon Graphics
{decvax,ihnp4}!ucbvax!Shasta!olympus!bobspeck@CIT-VAX.ARPA (08/17/84)
From: Don Speck <speck@CIT-VAX.ARPA>
Responding to Kirk McKusick's analysis of disk throughput:
> Thus the interesting question is why your system drops revs with
> only a 4K skip. I will suggest two possibilities. The first is that
> the rdist and/or sdist parameters (in struct hpst, hp.c) are set
> up incorrectly for your controller/disk combination.
I experimented with the sdist/rdist parameters for our 9775 (using
adb -k -w /vmunix /dev/mem) while running 'cp bigfile /dev/null' and
'iostat 2'. Any value of sdist from -1 to 31 made no difference; any
value of rdist less than 32 (the number of sectors per track) made no
difference. When I raised rdist to 32, throughput rose from 40 4K-byte
blocks/second to about 100.
In hpustart(), the calculations for when to do a search instead of
a transfer depend on the controller's "lookahead" register `hpla', which
on the SI 9900 is "not emulated - reads as 0". (The calculation is also
wrong!). For any value of rdist less than nsect (# sectors/track (32)),
the controller was told to "search" before every transfer. (Search is
supposed to seek, and then wait for the desired sector). In the 9900,
"Search" appears to be equivalent to "Seek" -- apparently the controller
just doesn't *know* the rotational position of any of our disks.
The fix is to add the line: hpsoftc[mi->mi_unit].sc_doseeks = 1;
to the appropriate place in hpmaptype().
Our 9775 is mapped as two RM05's. DEC diagnostics measure the seek
time as 1.14ms regardless of distance. Apparently the 9900 doesn't
emulate "Seek" for drives mapped as several logical drives (overlapped
seeks on two logical drives make no sense when there's only one physical
disk arm). Seek *does* take the right amount of time on our 9766.
The 9900 also doesn't bother to emulate the hpec1 & hpec2 registers.
The code in hpecc() case ECC looks like it will screw up on an SI 9900.
Does anyone know why the driver hangs when it reads a bad sector as
part of a large (8K) read on a raw device?
Don Speckscott@SU-SHASTA.ARPA (09/18/84)
Has anyone successfully used the Xylogics Model 450 Multibus disk controller to do overlapped seeks, i.e. simultaneous seeks on multiple drives? If so, could you contact me directly by mail (we're not yet on usenet)? Thanks. Scott Weikart ...ucbvax!Shasta!cdp!scott
emacs@ucb-vax.ARPA (09/27/84)
From: 05170000 <ucscc!emacs@ucb-vax.ARPA>
Bill ( Who distributed Prin. Forth ) or anyone,
Just recently I started to compile to Princeton Forth distributed
at the end of june. I ran into the following problem I thought you might
be able to help with. Here is a run of the makefile. I am on a 4.2bsd
system. I have put the bug fix (_errno, and the globl line) into the
source. Were there any other bug reports, I got that one message
that had to two problems in it.
Thanks,
Mike
ucscc!emacs@berkeley
hal.dove@ames-vmsb
p.s. Please respond to me since I am not getting wizards until our
ether is up. Thanks.
cat forth1.S forth2.S forth3.S >forth.s
/lib/cpp -DFDIR=\"/b/r/emacs/forth/\" -DFBLK=\"/b/r/emacs/forth/vaxforth/forth.blk\" -DBSD4_2 forth.s >forth.i
as -d2 -o forth.o forth.i
Assembler:
"", line 3187: Relocation error
*** Error code 1saks@ll-xn.ARPA (10/30/84)
From: Joft Saks <saks@ll-xn.ARPA> We recently switched from version 7 UNIX to 4.2 BSD. On our old system, it was possible to logout from the shell while background jobs were running, and the jobs continued to run. However, on our new system, the jobs apparently terminate at logout. This is from the shell only; when one logs out from the C-shell, background jobs continue to run. Has anyone seen this problem? Does anyone know the cause and/or have a solution? An alternative explanation is that our version 7 shell was hacked to allow background jobs to continue after logout and that the "standard" shell kills background jobs at logout. Does anyone know anything about this possibility? Please explicitly include me in any responses as I am not on the wizards list. Thanks. Jonathan Saks (saks@ll-xn)