HDTenEightyP/NetNews huggingface dataset:
From: "Stefan Berg" <sgberg@peach.ucs.indiana.edu>
Subject: Does 386BSD run on Gateway2000 EISA system?
Organization: Computer Science, Indiana University
Date: Fri, 2 Oct 1992 16:59:08 -0500

I couldn`t find any FAQ on 386BSD, so I`ll just post my question here
(or does 386BSD have its own newsgroup like Linux?).

I have a Gateway 2000 computer with:
486-33 EISA
8MB RAM
ATi Ultra 1MB
UltraStore Ultra 24F EISA SCSI Host Adapter (real EISA! 32bit)
                     ^^^^---(my biggest concern)
Maxtor 340MB
250MB Tape Drive
3.5 & 5.25 1.44MB disk drives
TelePath 14.4kbps FaxModem

I want to run a Unix system in in parallel to OS/2 and MSDOS5,
which I have installed right now (using the Boot Manager). I
initially tried to use Linux (back then 386BSD was very unstable),
but I couldn`t get Linux to recognize my Ultra 24F. I couldn`t
make the controller simulate IDE mode. The Unix system definitely
needs to coexist with the other OS`s (one HD). I cannot afford to
loose data due if my Unix goes nuts.

Does 386BSD satisfy my requirements? It would be nice to have somebody,
who actually saw a system similar to mine running 386BSD. If it would
be possible, please also let me know, where I can get the distribution
files (and "getting started files").

Thanks a lot,

Stefan
-- 
,--------------------------------------------------------------------,
| Usenet   sgberg@charon.bloomington.in.us            Stefan G. Berg |
| Internet sgberg@ucs.indiana.edu        GE Mail: s.berg5            |
| Bitnet   sgberg@iubacs  NeXT Mail: sgberg@arapahoe.ucs.indiana.edu |
`--------------------------------------------------------------------'
Newsgroups: comp.unix.bsd
From: herm@coombs.anu.edu.au (Herman H. Fredriksson)
Subject: Racal Interlan NI6510 Ethernet Cards [386bsd]
Organization: Coombs Computing Unit, Australian National University, Canberra.
Date: Sat, 3 Oct 92 12:50:38 GMT

G'day,
     We have quite a few 386 machines here with Racal Interlan NI6510
ethernet cards. I am wondering if anyone has a 386bsd kernel/device
driver which supports this particular card.. any information
appreciated...

Herman.
--
+---------------------------------------------------------------------+
|  Herman H. Fredriksson         email:    <herm@nitha.etsu.edu> USA  |
|  Things that make you go herm...      <herm@coombs.anu.edu.au> AUS  |
+---------------------------------------------------------------------+
From: veit@du9ds3.uni-duisburg.de (Holger Veit)
Newsgroups: comp.unix.bsd
Subject: Re: Clock.exe doesn't seem to work
Date: 2 Oct 92 17:46:45 GMT
Organization: Uni-Duisburg FB9 Datenverarbeitung
Reply-To: veit@du9ds3.uni-duisburg.de
NNTP-Posting-Host: du9ds3.uni-duisburg.de

In <wmbfmk.718016107@rw9.urc.tue.nl> wmbfmk@rw9.urc.tue.nl (Marc van Kempen) writes:

>If I use clock.exe to determine my videoclocks, 
>this is what I get:
>D
>  25.2   28.3   19.8  23.7  25.2  28.3  19.8  23.7

>I have however another program for the videocard, DMODE.EXE, 
>which gives the following results:

>  50.35  56.672  65.306  72.240 80.276  90.172  63.114  75.498

>My videocard is an ET4000, with 15-bit RAMDAC.
>I know my card can run 1024x768x256 at 70Hz, I can put it into
>that mode using DMODE. I find both listings of clocks a bit 
>suspicious however.

>(I have not yet been able to test this because of a harddisk crash)

>Has anyone any ideas?

>Thanks in advance,
>A

>Marc.
>wmbfmk@urc.tue.nl

Clock uses the "known" xtal frequency of 28.3 MHz (or was it 25.2?) as 
a reference. The first two clocks are standardized to allow compatibility
to the original IBM VGA. I don't think that the manufacturers risk to 
give up this compatibility, they usually add different clock oscillators.
For the first two frequencies it seems that DMODE returns the double value 
of clock.exe The others are totally different. Clock shows the same numbers 
twice, so at least its notion of the 2^2 switch bit is wrong for this card.
ET4000's, in particular those which can display 1024x768x256/70Hz, need
higher frequency oscillators. Is it possible that you have a "programmable"
oscillator on the board? In this case you should try X386 with the "legend"
option. Read the manual page of x386 on this.

Holger

-- 
|  |   / Dr. Holger Veit         | INTERNET: veit@du9ds3.uni-duisburg.de
|__|  /  University of Duisburg  | "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
|  | /   Dept. of Electr. Eng.   |   Sorry, the above really good fortune has
|  |/    Inst. f. Dataprocessing |      been CENSORED because of obscenity"
From: veit@du9ds3.uni-duisburg.de (Holger Veit)
Newsgroups: comp.unix.bsd
Subject: Re: HELP! VM problems while recompiling X11R5
Date: 1 Oct 92 11:50:56 GMT
Reply-To: veit@du9ds3.uni-duisburg.de
Organization: Uni-Duisburg FB9 Datenverarbeitung
NNTP-Posting-Host: du9ds3.uni-duisburg.de

In <48140@shamash.cdc.com> pbd@runyon.cim.cdc.com (Paul Dokas) writes:

>I'm having even more problems while trying to compile X11R5.  :-(

[...]
>Now normally this wouldn't be suprising for a 386-40 with 8MB of memory
>except for two things:  1) I've got 43MB of swap, 2) this didn't happen the
>first time that I built X11R5 with PEX.

>I've tried reducing the size of my kernel by reducing MAXUSERS, ptys and
>unneeded devices (sd2, sd3, st?, cd?, etc).  I've also removed nfs daemons
>from the startup procedure (they aren't running now).  But I still get
>stuck with "virtual memory exhausted".

[...]

>BTW, I've tried to use ps -aux to trace VM usage, and it seems that cc1
>is the culprit.  It's VSIZ goes up to over 6500 before it fails.

>-- 
>#include <std.disclaimer>
>#define FULL_NAME                          "Paul Dokas"
>#define EMAIL                              "pbd@runyon.cim.cdc.com"
>/* we are realizing infinite possibilities in exchange for our soul */

cc1 *is* the culprit. I had this problem not in the PEX tree, but already 
before in the xlib. Interesting difference. The obivious reason is that
it exceeded its memory allocated by the "limit" command of the csh.
Set 'limit memoryuse unlimited', datasize unlimited, and also increase 
the number of file descriptors (just for insurance, should not be a limit). 
Additionally, look for different limitiations (you shouldn't increase the
coredumpsize for some reasons :-)).

Hope that helps

Holger

-- 
|  |   / Dr. Holger Veit         | INTERNET: veit@du9ds3.uni-duisburg.de
|__|  /  University of Duisburg  | "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
|  | /   Dept. of Electr. Eng.   |   Sorry, the above really good fortune has
|  |/    Inst. f. Dataprocessing |      been CENSORED because of obscenity"
Newsgroups: comp.unix.bsd
From: deeken@iti.informatik.th-darmstadt.de (Hans-Christoph Deeken)
Subject: Re: new new scsi release beta2 part 1 of 5 (fixed)SKIP
Date: Thu, 1 Oct 1992 14:42:55 GMT
Organization: TU Darmstadt

In article <rwa.717885468@aupair.cs.athabascau.ca>, rwa@aupair.cs.athabascau.ca (Ross Alexander) writes:
> terry@cs.weber.edu (A Wizard of Earth C) writes:
> 
> >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.
> 
> <yawn, another newbie...>
> 
> If you can't handle it, admit you're an incompetent and stay out of
> the kitchen.  You might change your silly mail address too; a wizard
> indeed!  Real wizards don't so much as imagine that the simple list of
> trivial steps you mention are worth spending time on, much less
> kvetching about.
> 
> Just run the GENERIC kernel, and leave the hacking to your betters.

GrrmmppffhihihihiHAHAHAHA *ROTFL* :-)

Seriously: take your newsreader and take a look at Terry's postings, as far
as they are not expired. And then rethink your article.


IMHO, he is right. You shouldn't have to do all these things manually, when the
computer could easily do it for you. The more steps you have to take, the
easier you make mistakes.


> Ross

Hannes
-- 
Hans-Christoph Deeken                                        (Glenlivet on IRC)
Inst. fuer theoret. Informatik		(deeken@iti.informatik.th-darmstadt.de)
TH Darmstadt, Germany          (I don't speak for THD, they don't speak for me)
        "Whisky ist fluessiges Sonnenlicht --- George Bernard Shaw"
From: rich@Rice.edu (Richard Murphey)
Newsgroups: comp.unix.bsd
Subject: Re: fax software for 386bsd?
Date: 3 Oct 92 18:36:52 GMT
Article-I.D.: kappa.RICH.92Oct3123652
Reply-To: Rich@rice.edu
Organization: Department of Electrical and Computer Engineering, Rice
	University

In article <7yB2RB1w165w@student.business.uwo.ca> mark@student.business.uwo.ca (Mark Bramwell CS STAFF) writes:
   My modem is a fax capable modem.

   Under dos/windows, I can use WinFaxPro to send and receive faxes.  I am
    am not interested in receiving faxes, just sending them.

   Is there any fax software for unix based machines?  text or X11?

Has anyone tried pub/gnu/fax-3.2.1.tar.Z on prep.ai.mit.edu (18.71.0.38)?
Newsgroups: comp.unix.bsd
From: stark@cs.sunysb.edu (Gene Stark)
Subject: Bug in Rlimit initialization? (was Re: getdtablesize)
Organization: SUNY at Stony Brook Computer Science Dept.
	<1992Sep29.142535.21001@nntp.hut.fi>
	<1992Sep30.164745.13200@fcom.cc.utah.edu>
Date: Thu, 1 Oct 1992 19:31:16 GMT

>In article <1992Sep29.142535.21001@nntp.hut.fi> alo@kampi.hut.fi (Antti Louko) writes:
>>>In article <Bv7Dz7.C2o@BitBlocks.com> bvs@BitBlocks.com (Bakul Shah) writes:
>>>tlukka@vipunen.hut.fi (Tuomas Lukka) writes:
>>>>for(i=getdtablesize(); --i>2; close(i));
>>>>and getdtablesize returned something like 2000000000 and this
>>>>naturally would take a while to run... 
>>
>>>Another culprit is popen(). It attempts to allocate an array to hold
>>>getdtablesize() number of descriptors and fails under zsh.
>>
>>>Now I don't think what zsh is doing is wrong.  The problem is in
>>>the use of getdtablesize() in popen() and the code above.  What is
>>>needed is a system call that returns the highest *open* file
>>>descriptor number.

Funny, I noticed this just tonight and tracked it down.
I noticed that after issuing the "unlimit" command to the shell (not running
as superuser), the "mtools" commands failed to work.  I traced the problem
to a call to "getdtablesize" to obtain the size of the open file table,
followed by a call to "malloc" to allocate corresponding storage.  The problem
was that the "unlimit" command was setting the RLIMIT_OFILE component of
the per-process resource limits to RLIM_INFINITY.  The behavior of
"getdtablesize" is simply to return this value (0x7fffffff), and it is of
course ridiculous to attempt to allocate this much memory.

I question whether "setrlimit" should be setting the RLIMIT_OFILE and
RLIMIT_NPROC values to RLIM_INFINITY, rather than NOFILE and MAXUPRC,
respectively.  The following patch shown below to /sys/kern/init_main.c
should fix this.  I would appreciate comments on whether this is a
reasonable thing to do.

							- Gene Stark

*** /sys/kern/init_main.c.orig	Sat Jul 11 20:32:04 1992
--- /sys/kern/init_main.c	Wed Sep 30 22:30:48 1992
***************
*** 161,172 ****
  	 */
  	p->p_limit = &limit0;
  	for (i = 0; i < sizeof(p->p_rlimit)/sizeof(p->p_rlimit[0]); i++)
  		limit0.pl_rlimit[i].rlim_cur =
  		    limit0.pl_rlimit[i].rlim_max = RLIM_INFINITY;
! 	limit0.pl_rlimit[RLIMIT_OFILE].rlim_cur = NOFILE;
! 	limit0.pl_rlimit[RLIMIT_NPROC].rlim_cur = MAXUPRC;
  	limit0.p_refcnt = 1;
  
  	/*
  	 * Allocate a prototype map so we have something to fork
  	 */
--- 161,174 ----
  	 */
  	p->p_limit = &limit0;
  	for (i = 0; i < sizeof(p->p_rlimit)/sizeof(p->p_rlimit[0]); i++)
  		limit0.pl_rlimit[i].rlim_cur =
  		    limit0.pl_rlimit[i].rlim_max = RLIM_INFINITY;
! 	limit0.pl_rlimit[RLIMIT_OFILE].rlim_cur =
! 	  limit0.pl_rlimit[RLIMIT_OFILE].rlim_max = NOFILE;
! 	limit0.pl_rlimit[RLIMIT_NPROC].rlim_cur =
! 	  limit0.pl_rlimit[RLIMIT_NPROC].rlim_max = MAXUPRC;
  	limit0.p_refcnt = 1;
  
  	/*
  	 * Allocate a prototype map so we have something to fork
  	 */

Newsgroups: comp.unix.bsd
From: nbladt@autelca.ascom.ch (Norbert Bladt)
Subject: Re: fax software for 386bsd?
Organization: Ascom Autelca AG, Guemligen, Switzerland
Date: Mon, 5 Oct 1992 07:58:14 GMT

mark@student.business.uwo.ca (Mark Bramwell CS STAFF) writes:

>My modem is a fax capable modem.
Which modem are you using ?

>Under dos/windows, I can use WinFaxPro to send and receive faxes.  I am
> am not interested in receiving faxes, just sending them.
With the software mentioned below you can send and receive faxes.
Although all received faxes will end up in one directory. That might
be a problem if you plan to use a real multi-user environment.
This is what I gathered from the README file.

>Is there any fax software for unix based machines?  text or X11?
Yes. It is under the GNU project.
Its name is
	fax-3.2.1.tar.Z
This is a spooling system. I didn't take a look at it but it seems to be
written for BSD systems. So it should not be too difficult to port it.
Somebody in Munich, Germany did it, but, unfortunately I lost his
e-mail address.
I have the patches for a Supra FAXModem (but not tried those, yet).

Oh yes, if you don't want to change all the Makefiles you should port
GNU-make (make-3.62.tar.Z), first.

Hope this helps,

Norbert.
-- 
Norbert Bladt, Ascom Autelca AG, Worbstr. 201, CH-3073 Guemligen, Switzerland
Phone: +41 31 999 65 52			FAX: +41 31 999 65 44
Mail: nbladt@autelca.ascom.ch   UUCP: ..!uunet!mcsun!chsun!hslrswi!aut!nbladt
Newsgroups: comp.unix.bsd
From: nbladt@autelca.ascom.ch (Norbert Bladt)
Subject: [386BSD] EISA 486/33 & Adaptec 1742A - COMPLETE SUCCESS
Organization: Ascom Autelca AG, Guemligen, Switzerland
Date: Fri, 2 Oct 1992 11:01:54 GMT

Granville.Moore@purplet.demon.co.uk (Granville Moore) writes:

>On 22 Sep 1992, You said to All:

>JM>   Dell 450SE, 486 50Mhz, EISA, 24 Meg RAM
>JM>   Adaptec 1742 SCSI controller
>JM>   WD 8013W 10baseT ethernet

>JM>   when i boot the Fixit disk (with debug stuff) i get:

>JM>   [ lots of what looks like disk sector debugging ]
>JM>   [ 0.1 headers ]
[ list of devices found by 386BSD deleted.]

>JM>   it then hangs, or at least appears to do nothing.
>JM>   any ideas?

>I get exactly the same results with a Texas Instruments 1300 (386/dx) system.
>Currently with MDA (ugh!, but itwas a terminal server...), just about to
>upgrade to VGA.

>Likewise,  any ideas?
Yes. Take the new SCSI drivers from Julian Elischer (julian@tfs.COM) AND
his new boot-blocks. Without the new boot-blocks you can't boot
from the harddisk. Install them manually !
Put the 1742A (or 1740A ?) in "standard mode" (i.e. emulation mode of 1542B),
don't change the default factory settings (port 0x330, irq 11, drq 5)
build a new kernel (on a different system) and put it on a boot-floppy, e.g.,
fixit.fs - that's what I did - it may work with dist.fs, too.

After a lot of tests and many, many mistakes I made with the disklabel program
and esp. the calculation of blocks, etc. I succeeded yesterday in
getting the system installed and booted.
I even have a MS-DOS partition on the same disk !

THANK YOU VERY MUCH FOR YOUR PHANTASTIC WORK, Julian (and Bill, Lynne and
all the others) !
I wouldn't have a running 386BSD at home without you !
Yippieh !
Now I can start some further work on it.

Norbert.
-- 
Norbert Bladt, Ascom Autelca AG, Worbstr. 201, CH-3073 Guemligen, Switzerland
Phone: +41 31 999 65 52			FAX: +41 31 999 65 44
Mail: nbladt@autelca.ascom.ch   UUCP: ..!uunet!mcsun!chsun!hslrswi!aut!nbladt
Newsgroups: comp.unix.bsd
From: nbladt@autelca.ascom.ch (Norbert Bladt)
Subject: Re: [386BSD] Only root can login & MAXUSERS > 4?
Keywords: Permission denied  MAXUSERS  386BSD
Organization: Ascom Autelca AG, Guemligen, Switzerland
Date: Wed, 30 Sep 1992 07:12:52 GMT

bvickers@valentine.ics.uci.edu (Brett J. Vickers) writes:

>I've had two problems with 386BSD:

>1. All of a sudden, only the root user can login to my machine.  Whenever
[ text deleted - NB. ]
I am sorry, but I can't help with this one.

>2. I recompiled the kernel, setting MAXUSERS to 16, so that I could
>   at least open a few windows under X386, but it still limits me
>   to 4 pty's.  What have I done wrong?
The number of MAXUSERS is not related to the number of pty's you can access.
In the config file for your system there is a line containing something
like
	pty	4
You should change this 4 to, say, 16 and voila, you will have 16 pty's
devices for X (after creating a new kernel with this config file, of course).
I am not sure whether you have to create the devices in /dev or whether
they do exist already. To be sure, look in /dev for *pty* files.
If the don't exist, you can create the device entries by calling
	MAKEDEV pty
(or something similar). You should look into the MAKEDEV file to find
out what the exact syntax is. I am sorry to be not very specific, but I
have my 386BSD system at home and I am at work, now.

Hope this helps, anyway,

Norbert.
-- 
Norbert Bladt, Ascom Autelca AG, Worbstr. 201, CH-3073 Guemligen, Switzerland
Phone: +41 31 999 65 52			FAX: +41 31 999 65 44
Mail: nbladt@autelca.ascom.ch   UUCP: ..!uunet!mcsun!chsun!hslrswi!aut!nbladt
Newsgroups: comp.unix.bsd
From: bmyers@rucs2.sunlab.cs.runet.edu (B.Myers)
Subject: Re: HELP me make a /dev/vga for X11 under 386bsd
Keywords: HELP vga 386bsd X11
Organization: Radford University
Date: Wed, 30 Sep 92 05:40:09 GMT

>|> In article <tony.717293304@babel.cltr.uq.oz.au> tony@ctpm.uq.oz.au (Tony Jago) writes:
>|> >If anybody could please tell me how to create this device or where I can find
>|> >some instructions I would be made muchly happy!
>
>do mknod /dev/vga c 12 0
>(remember to change the ... console ... line in /dev/ttys to ... vga ...).
>
>|> 
>|> i have it too, but a different problem. 
>|> i run /usr/bin/X11/X :/dev/console
>|> and it goes but then it can't make the unix domain socket. 
>|> It makes /tmp/.X11-unix, but then no socket ...
>|> any ideas here? 
>|> i am using the supplied 386bsd kernel that is part of the 1.2E distrib.
>
>The X server should be started as:
>X :0
>(or just X)
>in your .xserverrc.  Also be sure to have /usr/X386/bin in your
>path, and set the environment variable DISPLAY to :0 (setenv DISPLAY :0
>in csh).  You should also have a .xinitrc to start a few applications
>when X starts.  Use the startx command to start X, it (or rather xinit)
>will execute your .xserverrc and .xinitrc.  (This is assuming you don't
>use xdm.  I've never used it, so I don't know how to set that up.
>You can put the startx command followed by a logout last in your .login
>file to start X when you log in.)
>
There is a MUCH simpler way to go about starting Xwindows.. or at
least I use everytime I log in...

1: make a .xinitrc file that makes some Xterms and starts some applications.
2: make a text file with the following program:

		#!/bin/csh -f
		/usr/bin/X11/xinit ~/.xinitrc -- /usr/bin/X11/X386 :0 >>& /dev/null

3: chmod this little shell script to a+rx and put it in /usr/bin/X11 so anyone/everyone
   can use it. This script can also be made into an alias for Cshell, and a function for
	Bourne shell.
4: type xwin to start Xwindows.  Works every time. 

My X installation is in /usr/bin/X11 with
   a link from /usr/X386/bin -> /usr/bin/X11.

>
>Goran
>
>------------------------------+---------------------------------
>Goran Hammarback              |     goran@astro.uu.se
>Astronomiska Observatoriet    |
>Uppsala Universitet           |
>S-751 20 SWEDEN               |
>------------------------------+---------------------------------


Where can I get MWM? Is it worth the trouble?
I'm working on GWM port.. anyone else already got it???

Brandon Myers

bmyers@rucs2.sunlab.cs.runet.edu
From: terry@cs.weber.edu (A Wizard of Earth C)
Subject: Re: Marvellous Memory Munching Make
Keywords: where does it go? what does it do?
Organization: Weber State University  (Ogden, UT)
Date: Mon, 28 Sep 92 16:56:10 GMT

In article <1992Sep28.101928.8607@cs.few.eur.nl> pk@cs.few.eur.nl writes:
>In <1992Sep25.174613.19954@fcom.cc.utah.edu> terry@cs.weber.edu (A Wizard of Earth C) writes:
>
>>In article <1992Sep25.020038.28923@citec.oz.au> sgccseh@citec.oz.au (Steve Hocking) writes:
>>>
>>>	I've noticed that make seems to eat memory like there's no tomorrow.
>>>Often I have to stop & restart a make because gcc et al complains about
>>>being out of memory. I know that if I reinstall with something other than
>>>the default swap size, then the problem will be hidden, but it seems like
>>>this is not the optimal solution. BTW the leak only seems to happen when
>>>make actually kicks off another program.
>
>>This is because of the malloc before the exec.  Change the "vfork" used to
>>start the child process to a "fork" and the memory leak will go away.  This
>>will make make somewhat slower, but since the malloc occures into the parents
>>heap, this is the culprit.  The problem gets worse on larger environments
>>set up by the user.
>
>In the new VM system, the only difference between fork() and vfork() is in
>scheduling: the parent waits until its child either exits or execs. Sharing
>of address spaces on longer occurs.

Which "new VM system" is this?  If you mean the one in 0.1, I submit the
following from Chris Torek, which I hope he doesn't mind me quoting:

]> The BSD make has at least one leak: it calls vfork, then malloc,
]> then exec.  This malloc affects the parent as well.  It is fixable,
]> but not very cleanly (well, you could change the vfork to fork, I
]> suppose...).

He also went on to say that BSD uses large amounts of memory and that the
current memory management wasn't very efficient, and that a rewrite was on
a project list (not his).


					Terry Lambert
					terry_lambert@npd.novell.com
					terry@icarus.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.
-- 
-------------------------------------------------------------------------------
                                        "I have an 8 user poetic license" - me
 Get the 386bsd FAQ from agate.berkeley.edu:/pub/386BSD/386bsd-0.1/unofficial
-------------------------------------------------------------------------------
Newsgroups: comp.unix.bsd