HDTenEightyP/NetNews huggingface dataset:
From: bde@runx.oz.au (Bruce Evans)
Subject: Buffer allocation bugs (was 386bsd: ftp problem, ...)
Organization: RUNX Un*x Timeshare.  Sydney, Australia.
Date: Sat, 26 Sep 92 20:33:07 GMT

In article <1992Sep24.200802.2971@fcom.cc.utah.edu> terry@cs.weber.edu (A Wizard of Earth C) writes:

>...  Also, since the physical memory percentage is blown for
>cache buffer allocation, you should either fix the calculation to make
>it 10% of buffer memory rather than 10% of physical memory (there is a patch
>to do this) ...

>All of the patches discussed, with the exception of the percentage
>calculation, which I had deemed to be questionable as to whether the code
>or the comments were what was wrong, are in the Alpha-3 patch kit.

I use 25% out of 8M of physical memory for buffers.  This causes no additional
problems (at least in combination with other fixes) although it gives
bufpages == 503 which is almost twice as large the recommended maximum of
NKMEMCLUSTERS/2.  It probably depends on the system not being used for much
except for (often) recompiling the kernel, so the system rarely swaps.  Only
half of the buffers are used for the disk cache so most of the time the 25%
is only 12.5% of physical memory and 50% of mallocatable memory.

If you change the code to match the comments, then only 2.5% of the memory
above 2M will be used for the disk cache.  That's ridiculously small.

>...and fix the buffer allocator, which currently blows the state
>calculation and allocates twice the needed memory.  Since it frees it twice
>as well, this problem takes care of itself.

Nope, it doesn't free it without the fix.  Divide all the above percentages
by 2.  The default of 10% gives about 800K of buffers on an 8M system, of
which about 400K are reserved for the disk cache and about 200K are actually
used.
-- 
Bruce Evans  (bde@runx.oz.au)
From: hitchens@untadh.enet.dec.com (Francis J. Hitchens)
Newsgroups: comp.unix.bsd
Subject: Xfree86 hardware question CT 82c452
Date: 2 Oct 92 13:30:54 GMT
Reply-To: hitchens@untadh.enet.dec.com (Francis J. Hitchens)
Organization: Digital Equipment Corporation


Hi,

My Digital PC has a 100% VGA compatible card, which supports 1024x768
resolution
in VGA Plus mode. It uses Chip Technologies 82C452 chip.

Does Xfree86 support this beast, or is it a real freak ?
Newsgroups: comp.unix.bsd
From: tlukka@vipunen.hut.fi (Tuomas Lukka)
Subject: getdtablesize
Organization: Helsinki University of Technology, Finland
Date: 26 Sep 92 10:45:12 GMT

I've had a couple of programs (most notably login and screen)
crash under zsh.
With gdb, I found that the reason was that they did something like
for(i=getdtablesize(); --i>2; close(i));
and getdtablesize returned something like 2000000000 and this
naturally would take a while to run... 

Patches, solutions, comments?
I'm running on a 486,33MHz,4Mb memory.
A friend with a 386SX,16MHz,8Mb and many other people don't seem
to have these problems.

The curious thing is that when I'm root, these programs work
as expected (using csh..)...???

	TJL
-- 
 /--\  TJL -- Tuomas J. Lukka  tlukka@vipunen.hut.fi IIIIIIIII -------    Just
/-\ o\        Puistokaari 1E18  _________--------------------+    I  J     go
\o \-/        00200 Helsinki    --------I GONE FISHING AGAIN ->   I        to
 \__/  SIGh.. Finland T. +358-0-6923924 /---------------------    L___    sleep..
Newsgroups: comp.unix.bsd
From: nils@merlin.ims.uni-stuttgart.de (Cornelis van der Laan)
Subject: ktrace - is it working ?
Reply-To: nils@ims.uni-stuttgart.de
Organization: IMS, University of Stuttgart, Germany
Date: Fri, 2 Oct 1992 03:12:39 GMT


I tried ktrace this evening. It creates a file ktrace.out and
ends with a 'Bad system call: core dumped' message.

Has anyone tried this already ?

-- Nils.
Newsgroups: comp.unix.bsd
From: ronald@gate.demon.co.uk (Ronald Khoo)
Subject: It works, thanks, a few problems (Re: New scsi system beta3 (part 1 of       10))
Organization: Demon Systems Ltd.
Date: Wed, 7 Oct 1992 02:32:37 GMT

julian@tfs.com (Julian Elischer) wrote:

> # This is a shell archive.

Verily!  Well, I've just tried it out with a aha 1742 and a horrid
cheapo disc we had lying around, and didn't have too many problems.
I started out with a stock 0.1, added Terry's beta patch kit, and, after
upgrading to gcc 1.42 (2.2.2 is being compiled at the moment)
the next step was to try out Julian's driver.

My problems were:

	a) had to create a zero length pio.h file to keep aha1742.c
	   happy (perhaps should omit the #include line from the .c file ?)
	   Just curious: what is pio.h ?

	b) locore.s didn't seem to have outl and inl defined.
	   My 386 is close to nonexistent, so I guessed this:
	   (is it right ?)

        .globl  _inl
_inl:   movl    4(%esp),%edx
        subl    %eax,%eax       # clr eax, presumably unnecessary ? 
        NOP
        inl     %dx,%eax
        ret

        .globl  _outl
_outl:  movl    4(%esp),%edx
        NOP
        movl    8(%esp),%eax
        outl    %eax,%dx
        NOP
        ret

	c) The readme isn't quite clear about bootblocks to use ..
	   Does it refer to using the standard asboot/bootas ?
	   Disklabel seems to be unhappy if I don't specify them at all,
	   but I don't actually want to boot off the slow old SCSI,
	   since it's fine for archival use, but not much else.
	   But for reference, I'd like to know which bootblocks the
	   README refers to.

	d) I agree that a system for encoding target/luns into the system
	   would be nice.  The old drive I'm playing with seems to
	   answer to ALL LUNs that the probe asks for, so the probe
	   sees 8 devices where there is only one.  I got fed up
	   so I hacked the probe to look for LUN-0 only, and that
	   seems to work fine, but I'd be interested to hear of a
	   neater way to cope with old kit like this.

	e) it seems to be a fairly large driver, and I didn't seem to
	   be able to delete the tape and cd sub-drivers (but then
	   I haven't tried very hard yet).  So I had to take quite
	   a lot of stuff out of my kernel to get it small enough to
	   boot.

	f) I guessed that the geometry to use in calculating disktab
	   was the rigid geometry as reported by the probe and not the
	   BIOS remapped geometry ?  Well it seems to work like that.
	   Does this not have implications for /386bsd lying beyond
	   1024 cylinders or am I barking up the wrong tree ?

Lots of questions I know, but I'm sure lots of people would ask the same
ones, so may I perhaps suggest that the author include a Q&A section
in his next distrib ?

In any case, thank you for your wonderful work.
Newsgroups: comp.unix.bsd
From: pauls@css.itd.umich.edu (Paul Southworth)
Subject: Re: Mounting NFS volumes
Organization: University of Michigan ITD Consulting and Support Services
Date: Tue, 29 Sep 1992 21:23:39 GMT

And furthermore, I have tried adding a line to /etc/fstab and couldn't
get it to mount that way either.

What I did there was:

<hostname>:/<path> /mnt nfs rw,rsize=1024,wsize=1024,intr 0 0

Funnily enough, no mention of that shows up in the reboot messages.
Not as success or error.

Paul Southworth                    |     ftp redspread.css.itd.umich.edu
Consulting and Support Services    |        Anonymous Political Archives
Information Technology Division    |                     100% 386BSD 0.1
University of Michigan, Ann Arbor  |  Coming soon: mirror of ftp.eff.org

  <Representing myself.  Everything I say is for educational use only.>
From: rkb55989@uxa.cso.uiuc.edu (Rafal)
Newsgroups: comp.unix.bsd
Subject: Extractuing ETC01??
Keywords: etc01 extract files
Date: 4 Oct 92 23:32:47 GMT
Organization: University of Illinois at Urbana

I have a quickie:

	When I try to extract the ETC01 distribution, I get a "too
	many files open" or some similar error on about the 75th
	file.... I know someone did ask about this before, but could
	not find any references to it...

				Any help appreciated...
						Rafal
From: volker@sfb256.iam.uni-bonn.de ( Volker A. Brandt )
Newsgroups: comp.unix.bsd
Subject: Re: Motif for 386BSD
Date: 6 Oct 92 12:41:01 GMT
Organization: Applied Math, University of Bonn, Germany

In article <1992Oct5.205641.1147@fcom.cc.utah.edu> eb@felix.Sublink.Org (Enrico Badella) writes:
>For example if there were 200 parties interested in Motif 386BSD [...]
>which adds out to $105 + shipping costs. This is still much lower
>than any Motif on the market, BTW all are 1.1.

I think this is an excellent idea.  I would pay about $50 - $60 (as a student).
I am sure that our university department would buy Motif for 386BSD at $105.

-- Volker
-- 
----------------------------------------------------------------------------
Bitnet:   UNM409@DBNRHRZ1                              Volker A. Brandt
UUCP:     ...!unido!DBNRHRZ1.bitnet!unm409             Angewandte Mathematik
Internet: volker@sfb256.iam.uni-bonn.de                (Bonn, Germany)
From: chet@odin.ins.cwru.edu (Chet Ramey)
Newsgroups: comp.unix.bsd
Subject: Re: Catch What They're Saying About Us...
Date: 29 Sep 1992 11:49:01 GMT
Organization: Case Western Reserve University, Cleveland, OH (USA)
NNTP-Posting-Host: odin.ins.cwru.edu

In article <19ta0nINNj2q@agate.berkeley.edu> wjolitz@soda.berkeley.edu (William F. Jolitz) writes:
>They have
>even received Chris Torek's sparc code, paid for by the taxpayers,
>which has not been made available to others despite repeated requests,

Oh, please.  This has come up before on comp.unix.bsd.  BSDI made an
arrangement with LBL, who owns the code.  Whether it was a licensing
agreement or a code exchange, I don't know, but neither BSDI nor Chris
can make it available without the consent of LBL.

Chet
-- 
``The use of history as therapy means the corruption of history as history.''
	-- Arthur Schlesinger

Chet Ramey, Case Western Reserve University	Internet: chet@po.CWRU.Edu
Newsgroups: comp.unix.bsd
From: ujlh@pool.info.sunyit.edu (James Henrickson)
Subject: 386bsd networking -- help needed
Organization: State University of New York -- Institute of Technology
Date: Sat, 26 Sep 1992 06:48:47 GMT

Hi all,

I am in the process of switching from Linux to 386bsd because of NE2000
support, and have run into a problem.

I would like to eventually network two 386bsd systems but first I would
like to get one working as a "stand alone" system.  So far, I can't get 
rlogin, telnet, or ftp to work.  I get a "Permission denied" message when 
trying to connect.  I get a similar message from talk, also.  It is 
probably a configuration problem, since I am new to network administration.  
I would appreciate it very much if someone could assist me with setting up 
the necessary files, since the man pages have only gotten me to this point.

In case it matters, I am using 0.1 with the binary distribution only.
(I'll get everything else after I know it works.)

Thanks in advance,

-- 
Jim H.
*
* James L. Henrickson
* ujlh@sunyit.edu        "Some day I might have a real .signature!"
From: grog@lemis.uucp (Greg Lehey)
Newsgroups: comp.unix.bsd
Subject: Re: [Re: Catch What They're Saying About Us...]
Date: 28 Sep 92 16:48:26 GMT
Organization: LEMIS, W-6324 Feldatal, Germany

In article <9209252210.AA10552@cognition.PA.DEC.COM> vixie@PA.dec.com (Paul A Vixie) writes:
>Will someone -- ANYONE -- who believes that my previous message (subtitled
>"an open letter to Lynne Jolitz") was an attack, please let me know
this?

Not I. I had intended to stay out of this mess, since my opinion does
not diverge greatly from those expressed already. My concerns are
something else:

>Lynne, I know better.  When I read the UNIGRAM article it was an almost
>exact reprint of the story you and Bill were telling at the time.  There
>were statements buried in that article, presented as "facts", which you
>and Bill had asserted publically and in private e-mail to me, but which
>noone -- NOONE! -- else had ever presented in quite the same way.  The
>"signature" of the UNIGRAM statements was unmistakably yours or Bill's.

I'm going to have to take Paul's word for this. However, this reminds
me greatly of another article which recently annoyed me: in the
October issue of UNIX Magazin - already mentioned here because of
their (IMHO unrealistic) claim that 250,000 copies were already out
there - I read:

: In fact, there is a great probability that AT&T code is still present
: in BSD386. Insiders claim that BSDI deliberately included AT&T code in
: BSD386 in order to get to market more quickly. Bill Jolitz stresses
: the fact that he was very careful not to copy anything while writing
: his extensions. He is not sure if this also applies to the Net/2 tape.

This article - signed by the Editor-in-Chief, Juergen Fey - is full of
inaccuracies, in particular wrt timing. However, this particular claim
is so far off the mark of anything that I have seen on the net
(which UNIX Magazin explicitly quoted as a source) that I would really
be interested in its source. Therefore questions to all of you who are
still reading this thread:

1. Do you believe that BSDI genuinely and deliberately included AT&T
   code in BSD/386?
2. Do you know anybody who believes it?

Before anybody gets the wrong idea, I am myself in no doubt that this
claim is incorrect. I also believe it reflects very badly on UNIX
Magazin that they have published this claim: it's possible that BSDI
could sue them for it unless they can prove the claim.
-- 
Greg Lehey                       | Tel: +49-6637-1488              
LEMIS                            | Fax: +49-6637-1489
Schellnhausen 2, W-6324 Feldatal, Germany
From: bvs@BitBlocks.com (Bakul Shah)
Newsgroups: comp.unix.bsd
Subject: Re: new new scsi release beta2 part 1 of 5 (fixed)SKIP
Date: 30 Sep 92 06:52:31 GMT
Article-I.D.: BitBlock.BvDprK.K8n
Organization: Bit Blocks, Inc.

terry@cs.weber.edu (A Wizard of Earth C) writes:

>What we really need is some way of encapsulating the device name as part of
>the entry.  MAKEDEV should be part of kernel installation, and should
>scan the symbol table and read the cdevsw and bdevsw entries.  That
>way, we can automatically generate devices from the current kernel
>configuration rather than assigning entries at all.

One idea is to add a system call that takes a <type,major,minor>
tuple and returns its canonical name.  If the <type,major,minor>
device does not exist, the call fails.  There are no holes in the
major number sequence and no holes in the minor number sequence
for a particular device.  Type is either cdev or bdev.

This is sufficient for implementing a user level program that
cycles through all possible major/minor pairs and constructs a
list of device names.  It can then compare this new list with the
list of existing entries and replace entries that changed.  An
option can be added to delete entries that are no longer relevant.

Note that entries will change only when the kernel device
configuration has changed.  If and when loadable drivers are
implemented, we can simply rerun this program after loading a new
driver to make it available.

This idea can be further extended to query devices on the SCSI
bus and come up with canonical names for them.

We did something like this at Fortune Systems back in '81.  I don't
recall who came up with this idea but it wasn't me.  Anyway, this
made reconfiguration real easy.

>This would
>allow us to put several "empty"  entries in the table for future allocation
>by loadable devices.

No need to make the bdevsw/cdevsw tables fixed size when most
other tables are not.

>Currently, the command line configuration tools are abominable.  I shouldn't
>have to edit my file (hoping I have the right one) to change an IRQ or add
>pty's, config it, change directories (making sure I get the one named the
>same as my file), make depend, make, and then manually install the resulting
>executable, remembering to delete the devices which are no longer applicable
>to my new configuration, and adding the ones which are but did not exist
>prior to the most recent rebuild.

Some of these steps can be encapsulated in a shell script but
yes, we need something fancier for managing the configuration.

Bakul Shah <bvs@BitBlocks.com>
From: ujlh@pool.info.sunyit.edu (James Henrickson)
Newsgroups: comp.unix.bsd
Subject: Re: 386bsd networking -- help needed
Date: 26 Sep 92 08:28:43 GMT
Organization: State University of New York -- Institute of Technology

I said:
>
>I would like to eventually network two 386bsd systems but first I would
>like to get one working as a "stand alone" system.  So far, I can't get 
>rlogin, telnet, or ftp to work.  I get a "Permission denied" message when 
>trying to connect.  I get a similar message from talk, also.  It is 
>probably a configuration problem, since I am new to network administration.  
>I would appreciate it very much if someone could assist me with setting up 
>the necessary files, since the man pages have only gotten me to this point.
>

OK, I have narrowed things down somewhat.

I set up an entry in /etc/hosts for localhost and can now connect with
rlogin, telnet, and ftp.  What do I do now?  I would like to use a regular
address (such as 0.0.0.1) for my first system, but can't manage to get
it to work. 

-- 
Jim H.
*
* James L. Henrickson
* ujlh@sunyit.edu        "Some day I might have a real .signature!"
Newsgroups: comp.unix.bsd
From: dinesh@pyramid.COM (Dinesh Jalisatgi)
Newsgroups: comp.unix.bsd
Subject: Where can I find xterm for 386BSD for PC.
Date: 5 Oct 92 23:08:29 GMT
Distribution: usa
Organization: Pyramid Technology Corporation, Mountain View, California
NNTP-Posting-Host: shadow.eng.pyramid.com


 hi,

 I just downloaded the X386 oftware from agate and I find that there is no xterm included in it.

 Where can I find one for the 386BSD based PC.

 Thanks.

 Dinesh.
From: scotty@gagetalker.com (Scott Turner)
Newsgroups: comp.unix.bsd
Subject: Re: public S3 design (Was: Free software and ... Diamond products)
Date: 3 Oct 92 05:54:09 GMT
Organization: L5 Computing

In article <BvGoLF.8nn@pix.com> stripes@pix.com (Josh Osborne) writes:
|> In article <BvCyt0.JG4@immd4.informatik.uni-erlangen.de> Torsten Duwe  
(duwe@informatik.uni-erlangen.de) writes:
|> [...]
|> >Doesn't performance depend solely on the main (bus/memory/whatever) clock ?
|> >... would be a bad thing if drawing speed was closely coupled to the pixel
|> >clock. 
|> 
|> With normal DRAM (i.e., not VRAM, not duel ported RAM) if the shifter needs
|> to output 65 Mega Pixels per second (assuming 8bits per pixel) 65 Mbyte/sec
|> of bandwidth is used to feed the shifter, which is 65Mb/sec you can't use to
|> transfer data to the DRAM.
|> 
|> [...]
|> >In my opinion local bus is unnecessary if you have an 'intelligent' SVGA to
|> >give complex commands to. Only memory to screen bitblt is an issue but that
|> >should be solved using more video RAM - hope the '928 is able to address  
more
|> >than 1 Meg.
|> 
|> Well please optimise copy plane of pixmaps with xor on and have enough RAM
|> that all of xtanks pixmaps can be resident (I think there is over 1M of them
|> once rotated out, if not I know there is over 500K of them).  [...]
|> 
|> >[...]
|> >>(4) S3 corportation provides a software development kit
|> >Yup! They're very DOS-infected but nice people.
|> 
|> I thought they had a windows bias, the 911 isn't very fast unaccel'ed
|> (isn't as fast as, say, the ET4000), and most DOS programs arn't accel'ed.
|> Not that windows is all theat diffrent from DOS...
Interesting discussion guys, but you're both missing the big advantages to
using something like local buss or an S3/8514 card.

The single biggest thing you need is unbanked access to the video memory.
Next is mouse in hardware. Then comes video refresh rate vs VRAM/DRAM.

Not having to look over your shoulder to make sure you haven't switched
banks or drawn on the cursor make a huge difference in performance. The S3
chip has an on board mouse and having an 8514 interface it has unbanked
access to the video memory.

But massive bandwidth to the memory doesn't always pay off. I've benchmarked
the ATI Graphics Ultra against the ATI GraphicsVantage. The Ultra has over
twice the bandwidth of the Vantage and yet is only 20% faster in the windows
benchmarks.

I did a BLIT port of X11R4 to SysV386 3.2 and using the 82786's on board
mouse hardware almost doubled the speed of the server (using the onboard
drawing engine also gave it a BIG kick in the pants, too bad the damn thing
died, sigh.)

Western digital was shopping around a chip earlier this year that was designed
specifically to speed up X. It pratically ate X straight (like the 82786) and
thus might be an interesting chip to play around with.

Scotty
Newsgroups: comp.unix.bsd
From: bmyers@rucs2.sunlab.cs.runet.edu (B.Myers)
Subject: Re: Which C library to start hacking?
Organization: Radford University
Date: Wed, 30 Sep 92 05:46:30 GMT

In article <rcskb.717422977@minyos.xx.rmit.OZ.AU> rcskb@minyos.xx.rmit.oz.au (Kendall Bennett) writes:
>terry@cs.weber.edu (A Wizard of Earth C) writes:
>
>>There is a book (by Plauger?) from Prentice Hall on the C library, with
>>a large majority of the functions implemented.  I would hazard a guess
>>that this is publically usable.  I think it's something like "The UNIX
>>C Library" or something similar.  I saw it in Software Plus.
>
>I have P.J. Plauger's book, but I will be using it only for ideas, and
>not taking the code directly from it - you require a license to do this!
>Yes, damn silly if you ask me, but it is a fact of life...
>

I also have P.J. Plauger's book, and have found MANY errors in the code.
therefore it is unadvisable to copy the code even WITH a license. :)

>
>+------------------------------------------+-------------------------------+
>| Kendall Bennett,                         | Internet:                     |
>| Advanced Computer Graphics Centre,       | kjb@godzilla.cgl.citri.edu.au |
>| Royal Melbourne Institute of Technology, | rcskb@minyos.xx.rmit.oz.au    |
>| Victoria, AUSTRALIA.                     |                               | 
>+------------------------------------------+-------------------------------+
>| CoSysop (Bossman), PC Connection Australia:               +61 3 688 0909 |
>+--------------------------------------------------------------------------+


Brandon Myers
bmyers@rucs2.sunlab.cs.runet.edu

Newsgroups: comp.unix.bsd