HDTenEightyP/NetNews huggingface dataset:
From: thomasm@Ingres.COM (tom markson)
Newsgroups: comp.unix.bsd
Subject: Re: What happens if you have both BSD/386 and 386BSD?
Date: 7 Apr 92 22:41:09 GMT
Distribution: usa

roh@CS.ColoState.EDU (Lucas Roh) writes:

> What about the opposite direction?  It seems unfair that BSDI can
> use the free sources and incorporate it into their software but without
> recourse for others to the same.  A lot of people have sweated to create the
> Net/2 software, it is ridiculus that they can take the code and yet prevent
> others to do the same on their product.  I think GNU license makes a lot of 
> sense, if you base something on a GNU software, you should let yours be freely 
> redistributable also.  I mean it shouldn't be just one direction, you should
> pay something back in return.

I'm taking the BSD 4.4 Kernel INternals class and Kirk McKusick addressed
this issue directly.  He said the "copyright was too restrictive", "the
copyleft too restrictive".  What he tried to created was a "copy
center". (get it?)  Look at what the "copy center" philosophy has done for 
the Unix business: The standardization of BSD features into posix, tcp/ip
predomination, etc.  Maybe you should go yell at AT&T or IBM for using code
copyrighted by the "Regents...".  Why pick on BSDI when OSF is using the
BSD code directly, too?

Furthermore, I believe that BSDI CANNOT tell you that you can't
redistribute code copyrighted by the regents, only the original code
produced at BSDI.  The big secret here is to do a big grep on the whole
source tree for "BSDI".  Every file that doesn't match is from net/2.

And as for putting something back, a previous thread describes how Mike
Karels is working on bstreams.  Well, if you didn't know Mike is with
BSDI now. Bstreams, I believe, will be in a future "Regents" release.

I bought BSDI and I'm very happy with it.  Although I respect those of
you using 386bsd, I don't know that I'd be happy counting the kernel
panics that occurred today.  With BSDI I've gotten a stable OS (still in
beta, too) and fantastic support. Furthermore, I can hack on the system
where *I* want to and don't have to deal with "fixing that annoying bug
in the SCSI driver" unless *I* want to. 

Anyway, off my soapbox,

-- 
Tom Markson					Unix Systems
email: thomasm@ingres.com			Ingres Corp
Newsgroups: comp.unix.bsd
From: scotty@gagetalker.com (Scott Turner)
Subject: Re: swapping problems
Organization: L5 Computing
Distribution: comp.unix.bsd
Date: Mon, 13 Apr 1992 04:03:12 GMT

In article <1992Apr10.174323.27801@uwm.edu> knie2586@csd4.csd.uwm.edu (Robert  
Joseph Knier) writes:
|>     I've posted here before reguarding lockups while compiling the 386BSD
|> kernel.  Best that I can determine is that during I/O intensive operations,
|> the swapper can lock up.  Would anyone know of techniques to get around
|> this so I can compile the kernel (once I do this, I'll look into the bug)?
|> Currently, I have a 386 20Mhz Northgate systems (no cache) w/a RLL drive.
|> I can't uprade beyond the 4Mb that I have as the main board is full (old
|> system), so I am looking for a temporary solution.
Borrow an extended, not expanded, memory card. Memory can be added by plugging
it into the AT buss. The memory is slower than main board memory, but if
it reduces the amount of swapping so you can compile the kernel...

Scotty
Newsgroups: comp.unix.bsd
From: veit@du9ds3.uni-duisburg.de (Holger Veit)
Subject: Re: Problems with RLL controller and 386bsd?
Date:  7 Apr 92 09:45:57 GMT
Reply-To: veit@du9ds3.uni-duisburg.de
Organization: Uni-Duisburg FB9 Datenverarbeitung

In <veit.702629585@du9ds3> veit@du9ds3.uni-duisburg.de (Holger Veit) writes:

[...you probably read this just...]
>I suppose that the hd controler is the problem. It has an onboard ROM
>(format + bootup) and gets the disk configuration from a disk sector 
>and stores it in a reserved ram at seg 0xcb80 (real mode). BTW, it has
>26 sectors/track, not the common 17.

I forgot to mention that xenix386 and ISC386 3.2 worked with this configuration.

>Greetings 
>Holger

-- 
|  |   / Holger Veit             | INTERNET: veit@du9ds3.uni-duisburg.de
|__|  /  University of Duisburg  | BITNET: veit%du9ds3.uni-duisburg.de@UNIDO
|  | /   Dept. of Electr. Eng.   | X.400: /S=veit /O=du9ds3 /P=uni-duisburg
|  |/    Inst. f. Dataprocessing |        /A=dbp /C=de
Newsgroups: comp.unix.bsd
From: james@bigtex.cactus.org (James Van Artsdalen)
Subject: Re: 386BSD 0.1 boot block mods.
Keywords: 386BSD wdbootblk.c
Reply-To: james@bigtex.cactus.org (James Van Artsdalen)
Organization: Institute of Applied Cosmology, Austin TX
Date: Wed, 15 Apr 1992 23:19:46 GMT

In <1992Apr13.164733.10829@digi.lonestar.org>, mmitchel@digi.lonestar.org
	(Mitch Mitchell) wrote:

> I had to make some changes to wdbootblk.c to get it to boot from a new
> Quantum Peripherals 200MB hard disk on my Toshiba 5100.  Specifically,
> the loop at "readblk:" needed a delay between accesses to the disk status
> register.  I've no idea why -- the 200MB disk is faster than the standard
> 40MB that came with the 5100 (and which booted fine). 

IDE drives have this sort of problem fairly often.  One must also be
very careful with the DRQ bit - sometimes the drives give an interrupt
before the data is really ready...

Please don't code a delay loop like the patch below.  There isn't any
good way to tell how long that loop will take to run.  Different x86's
will take very different amounts of time to do that, and the loop is
obviously very dependent on CPU clock rate.

Instead, for example, do 8-bit I/O writes to an unused port (port 0x80
is a good choice).  On compatible machines, an 8 bit I/O-write takes
about the same amount of time, about 1 us.

This, for example, would take about 25us on any processor at any clock
rate in a 386-or-better ISA/EISA system (except notebooks on power
management at very slow clock rates):

	movl $random_memory_ptr,%esi
	movl $25,%ecx
	movw $0x80,%dx
    rep outsb

> *** wdbootblk.c.std	Mon Apr 13 11:19:03 1992
> --- wdbootblk.c	Mon Apr 13 11:21:11 1992
> ***************
> *** 146,151 ****
> --- 146,155 ----
>   
>   	/* check to make sure controller is not busy and we have data ready */
>   readblk:
> + 	movl	$0x0000000f,%ecx
> + dwait:	NOP
> + 	loop dwait
> + 
>   	movl	$ IO_WD1+wd_status,%edx
>   	inb	%dx,%al
>   	NOP
-- 
James R. Van Artsdalen          james@bigtex.cactus.org   "Live Free or Die"
Dell Computer Co    9505 Arboretum Blvd Austin TX 78759         512-338-8789
From: jawilson@athena.mit.edu (Jason A Wilson)
Newsgroups: comp.unix.bsd
Subject: Re: BSD names (was: BSD on floppies)
Date: 10 Apr 92 21:16:25 GMT
Organization: Massachusetts Institute of Technology

I think a clear way to tell them apart is to always use a "/" when referring to BSDI's
product.

Therefore, 386BSD and BSD386 would be the free BSD
whereas, BSDI BSD/386, or BSD/386 or even 386/BSD.

I hope this convention sticks because it will end confusion AND it won't require
any creativity.
Newsgroups: comp.unix.bsd
From: peter@ferranti.com (Peter da Silva)
Subject: Re: The great BSD name-off...
Organization: Xenix Support, FICC
Distribution: usa
Date: Mon, 13 Apr 1992 20:10:26 GMT

In article <1992Apr13.164709.22125@acsu.buffalo.edu> ferrick@acsu.buffalo.edu (Patrick K. Ferrick) writes:
> There's something that's been sort of bothering me about some of the name
> suggestions I've seen posted lately, and I wonder if anyone else agrees: I'd
> prefer that whatever name gets chosen doesn't include the word "free" or
> suggest it.

OK, how about suggesting the other meaning of free: liberated? "Liberix",
or "Openix" (Karl could go for that), or "Anarchix", or "Liberated Software
Distribution" (LSD).
-- 
/F{findfont exch scalefont setfont}def /S{moveto show}def /T{/Times-Roman F}def
8 T(Ferranti International Controls Corporation)24 28 S(+1 713 274 5180)24 12 S
(Sugar Land, TX  77487-5012)24 20 S 12 /Courier F(`-_-')320 32 S( 'U` )320 16 S
12 T(Peter da Silva)24 36 S 16 T(Have you hugged your wolf today?)358 24 S
From: jot@zevs.ifi.unit.no (Jo Torsmyr)
Newsgroups: comp.unix.bsd
Subject: ps/sps
Date: 8 Apr 92 20:16:50 GMT
Organization: Dep. of Comp. Sci., Univ. of Trondheim

I dare ask this questions even though they're simple to
answer (when you know the answer...).

I've 'ps' and 'sps' up and running. So far all well, but
'ps' gives me this warning message every time:

warning: no device database /var/run/dev.db

And that's correct, I have no such file. So -- how do one create
this file?

'sps' says:

sps - Can't read struct pgrp for ttypX

where X is any number 1,2,3... I have initialize 'sps' with
# sps -i -s /386bsd
(or something like that), any idea anyone?

One more then -- My arrow keys does not work correctly with
'tcsh', they just display some numbers. When I think about it,
the arrow keys does not work in 'elvis' either, am I using
a wrong termcap entry or what?

Maybe I should have done my homework and RTFM, but I have just
had time to glance through the manual pages, and could find
little or nothing. This list is certainly not overloaded for the
moment, so I use the opportunity to ask some simple questions :-)

-jo



-- 
Jo Torsmyr
Department of Computer Science
College of Arts and Sciences
University of Trondheim, Norway		FAX: +47 7 59 17 33
Email: jot@ifi.unit.no			Voice: +47 7 58 88 79
Newsgroups: comp.unix.bsd
From: lmjm@doc.ic.ac.uk (Lee M J McLoughlin)
Newsgroups: comp.unix.bsd
Subject: Re: Recompiling the bootcode. Fix for my PC
Date: 14 Apr 92 14:52:37 GMT
Organization: Dept. of Computing, Imperial College, London. U.K.


Have you tried the locore.s patch?  A copy of my kernel with this
patch applied along with the recent collection of patches to get
kern_execve to work is in:
	src.doc.ic.ac.uk:incoming/386bsd.lmjm

The two patches applied to this kernel are given below.  I also
rebuilt it to allow NFS.  I cannot promise that these are the only
patches.  I've been hit by an odd problem with login and have been
bouncing in and out of RCS revisions.

From: james@raid.dell.com (James Van Artsdalen)
Subject: a20 bug in locore.s
Date: 31 Mar 92 02:28:30 GMT

From: tinguely@plains.NoDak.edu (Mark Tinguely)
Subject: Re: Fixed problem with long command lines
Date: 9 Apr 92 02:50:02 GMT

Copies are in, respectively:
	src.doc.ic.ac.uk:386BSD/comp.unix.bsd/volume92/Apr/920401.11.Z
	src.doc.ic.ac.uk:386BSD/comp.unix.bsd/volume92/Apr/920409.20.Z
--
--
Lee McLoughlin.                          Phone: +44 71 589 5111 X 5085
Dept of Computing, Imperial College,     Fax: +44 71 581 8024
180 Queens Gate, London, SW7 2BZ, UK.    Email: L.McLoughlin@doc.ic.ac.uk
From: pk@cs.few.eur.nl (Paul Kranenburg)
Newsgroups: comp.unix.bsd
Subject: 386bsd: bug in trap.c
Date: 8 Apr 92 11:17:14 GMT
Reply-To: pk@cs.few.eur.nl
Organization: Erasmus University Rotterdam

The trap handler in `trap.c' attaches wrong sementics to the system call
interface and can also cause your machine to silently lock up. This bug
is tickled when the kernel takes a page fault while in supervisor mode
with `pcb_onfault' set (eg. when doing copyin/out). If the page fault
turns out to be a protection exception, an attempt is made to deliver a
SIGBUS to the process, where returning EFAULT is appropriate. Furthermore,
the saved PC is not set to the fault handler which causes the offending
intruction to be restarted, resulting in an immediate recurrence of the
page fault. The following fix seems to cure the problem.

Paul.


*** trap.c.orig	Wed Apr  8 13:10:25 1992
--- trap.c	Wed Apr  8 13:10:51 1992
***************
*** 92,97 ****
--- 92,98 ----
  	
  if(curpcb == 0 || curproc == 0) goto we_re_toast;
  	if (curpcb->pcb_onfault && frame.tf_trapno != 0xc) {
+ copyfault:
  		frame.tf_eip = (int)curpcb->pcb_onfault;
  		return;
  	}
***************
*** 127,133 ****
  	case T_SEGNPFLT|T_USER:
  	case T_STKFLT|T_USER:
  	case T_PROTFLT|T_USER:		/* protection fault */
- copyfault:
  		ucode = code + BUS_SEGM_FAULT ;
  		i = SIGBUS;
  		break;
--- 128,133 ----
From: u8acb@ohm.york.ac.uk (Alex Barclay)
Newsgroups: comp.unix.bsd
Subject: Re: Recompiling the bootcode. Fix for my PC
Date: 13 Apr 92 11:11:23 GMT
Organization: Electronics Department, University of York, UK

In <1992Apr13.104624.16982@minyos.xx.rmit.oz.au> s871780@minyos.xx.rmit.oz.au (Antony Suter) writes:

>I believe that Advanced AMI bioses have a CMOS config option specifying
>which drives and the order in which to boot. You can set it to 'A: C:' or
>'C:' etc. Look at yours, its probably 'C:' ! If you dont know how to get to
>your CMOS setup... 1) Be careful changing it! 2) Press the 'DEL' key just
>after the memory count before the rest of the boot is completed. (cold boot).
>Enter advanced CMOS setup. 3) Be careful changing it! 4) Be very careful
>changing it!

Well from what you describe I haven't got an advanced AMI BIOS. The boot
sequence is always A: then C:. The point of disabling the hard drive was
so that I could get the BIOS to barf up the insert boot disk message. BSD
doesn't need the bios to tell it about the hard drive so it's a case of the
BIOS behaving differently on booting first time of a 3.5in floppy and
booting after the message. It's very odd but I'm looking to have a go at
fixing it, by first printing numbers to the screen from the boot sequence
at various points. When the numbers stop then I've found the problem!

			Alex.
Newsgroups: comp.unix.bsd
From: sean@u36.uucp (Sean Goggin)
Subject: Partition ID's Version 1.2
Keywords:  partition 
Organization: U36 Research
Date: Sat, 11 Apr 1992 16:54:08 GMT

Please email new entries to me at sean@u36.kwnet.on.ca .
This list is in the public domain.

Thank you - Sean Goggin

Partition Type			Number 	
no partition			0x00
Dos 12bit FAT Table		0x01
Xenix Root			0x02
Xenix Usr filesystem		0x03
Dos 16bit FAT Table		0x04
Dos 3.3 Extended		0x05
Dos 4.0 large volume		0x06
OS/2 HPFS			0x07
QNX				0x07
Advanced Unix			0x07
AIX file system			0x08
AIX boot partition		0x09
OPUS				0x0A
OPUS				0x10
VENIX 80286			0x40
Novell ?			0x51
CPM ?				0x52
Microport SysV/AT		0x52
386/IX				0x63
UNIX System V/386		0x63
MACH MtXinu BSD 4.3 on Mach	0x63
GNU HURD			0x63
Novell				0x64
PC/IX				0x75
Minix 1.1  - 1.4a		0x80
Minix 1.4b - 1.5.10		0x81
Linux (Planned)			0x82
Amoeba file system		0x93
Amoeba bad block table		0x94
BSDI file system(s), then swap	0xB7
BSDI swap, then file system(s)	0xB8
CCPM Concurrent CPM		0xDB
C.DOS				0xDB
CTOS Convergent Tech OS -Unisys 0xDB
DOS 3.3+ Secondary		0xF2
Bad Track table			0xFF

-- 
Sean.Goggin....sean@u36.kwnet.on.ca..............................U36.Research...
Newsgroups: comp.unix.bsd
Subject: Re: To make 386bsd coexist with DOS partitions??
From: l00017@eeyore.stcloud.msus.edu (Networking Research)
Date: 7 Apr 92 05:34:40 -0600
Organization: Saint Cloud State University

veit@du9ds3.uni-duisburg.de (Holger Veit) writes:
> This is an idea and a question how to make 386BSD work with the
> DOS partition system. Comments on whether this works or not, and additional
> hints are welcome.

	I like the way that Mach 2.6 deals with this on the 386.  You have
only one Mach partition in the DOS partition table, but within that partition
you have a standard BSD style disklabel with it's own partition table.  This
allows for leaving 3 DOS style partitions free, and having a fair number
(8?) of partitions available for Unix.  This way, one could concievably have
multiple unixes stored on one disk too, each with it's own partition table.

-Mark Holden
l00017@eeyore.stcloud.msus.edu
From: richard@pegasus.com (Richard Foulk)
Newsgroups: comp.unix.bsd
Subject: Re: What happens if you have both BSD/386 and 386BSD?
Date: 12 Apr 92 00:02:08 GMT
Organization: Pegasus,  Honolulu

>
>Furthermore, I believe that BSDI CANNOT tell you that you can't
>redistribute code copyrighted by the regents, only the original code
>produced at BSDI.  The big secret here is to do a big grep on the whole
>source tree for "BSDI".  Every file that doesn't match is from net/2.

And why wouldn't you expect to see BSDI litter in, and taint, more and
more BSD files as they add new `features', large and small?

They have yet to make any public statements to give us any other impression.

>
>And as for putting something back, a previous thread describes how Mike
>Karels is working on bstreams.  Well, if you didn't know Mike is with
>BSDI now. Bstreams, I believe, will be in a future "Regents" release.
>

What I got from reading the thread you mention is that Mike Karels made
it a condition of his employ with BSDI that he be allowed to finish
bstreams and give it to Berkeley.

You make it sound like it was BSDI's idea.  Their participation shouldn't
be ignored, but neither should Mike's.


-- 
Richard Foulk		richard@pegasus.com
From: composer@Beyond.Dreams.ORG (Jeff Kellem)
Newsgroups: comp.unix.bsd
Subject: Re: BSD names (was: BSD on floppies)
Date: 7 Apr 92 14:22:13 GMT
	<1992Apr4.015115.5860@cirrus.com> <1992Apr4.215301.17060@uwm.edu>
	<24838.9204051603@thor.cf.ac.uk> <28422@hoptoad.uucp>
Reply-To: composer@Beyond.Dreams.ORG
Organization: Beyond Dreams

In article <28422@hoptoad.uucp> zoo@cygnus.com (david d 'zoo' zuhn) writes:
 > But they're mnemonic at least.  There's nothing to tell 386BSD from
 > 386BSD unless you can keep them straight by other means.  Mine is BSDI
 > and BSDJ (I for Inc. and J for Jolitz).  

Actually, to be picky, the names are 386BSD (what you're calling BSDJ, the
free release) and BSD/386 (from BSDI, the product).

 > I like the fact that J is close to I: full source puts your 1 step
 > ahead.

Ah, but they both include full source.  It's just that one is completely
redistributable and the other isn't.  (Perhaps, you meant "freely available
full source ..."?  ;-)

Cheers...

			-jeff

Jeff Kellem
Internet: composer@Beyond.Dreams.ORG
From: jarinie@sulo.otol.fi (Jari Niemel{ T-230-3)
Newsgroups: comp.unix.bsd
Subject: From where I can get BSD ?
Date: 13 Apr 92 20:56:09 GMT
Article-I.D.: sulo.1992Apr13.205609.5180
Organization: Oulu Institute of Technology, Finland

I am interested in BSD-unix, but I also have a prob ! :(
Where I can get my copies ?

You can reply in private !

-------------------------------------------------------------------------------
Jari Niemela               Oulu Instite of technology
jarinie@otol.fi

-------------------------------------------------------------------------------
From: mm@mentor.cc.purdue.edu (Mike MacKenzie)
Newsgroups: comp.unix.bsd
Subject: Re: Bug fix coordination
Summary: We volunteer to help.
Date: 10 Apr 92 19:53:55 GMT
Article-I.D.: mentor.44836
Organization: Purdue University

In article <1191@alderan.sdata.de>, chris@alderan.sdata.de (Christoph Splittgerber) writes:
> In article <1992Apr3.141000.8354@ugle.unit.no> jot@zevs.ifi.unit.no (Jo Torsmyr) writes:
> 
> >I would appreciate any suggestions for organizing patchleves!
> 
> Maybe we should send our patches to somebody by email who is collecting
> them. Then this somebody passes the patches to a few other people to
> validate them and then put them together to an "official" patch assigning
> a official patch-number and post it to this group.
> 


We've set up a archive server that is accessable by email and anonymous
ftp.  We plan to have patches available as well as several PUCC
Unix Group internal tools.  We have about a dozen volunteers that
have expressed willingness to work on this project, so we have
the manpower.

We will begin putting tested patches on nova.cc.purdue.edu in
/pub/386bsd/submissions over the weekend.  You can get an index by
sending email to archive-server@nova.cc.purdue.edu with the subject 
"index 386bsd/submissions"


Michael MacKenzie	(Purdue University Unix Group)
mm@mentor.cc.purdue.edu
From: scott@pita.cns.ucla.edu (Scott Burris)
Newsgroups: comp.unix.bsd
Subject: Re: kernel panic when doing a make depend
Date: 15 Apr 92 10:48:06 PDT

eddy@aludra.usc.edu (George Edmond Eddy) writes:


>Bad News :( ... keep getting kernel panics when doing a "make depend"
>while trying to build a kernel.  I get basically the following messages:

>	vm_fault(...) -> 1
>	  type c, code 2
>	trap type 12 code = 2 ...
>	panic: trap 
>	syncing disks...

This is a result of execve() throwing up because the argument list exceeds
2K in length.  Put in one of the posted patches to kern_execve.c, recompile
without doing a make depend, then run the new kernel.

Beware, I've had some strange problems with at least one of the execve patches.
The system seems to hang randomly when doing makes -- the system doesn't
appear to be deadlocked, but completely blown away.  I haven't figured out
why yet (too busy working on TeX, C-news and threaded RN at this point).

On a completely different issue, does anyone have a driver for floppy based
tape backup systems?  I've got a CMS tape drive on another machine, and
I'm looking at a disaster in the making if I don't find a decent way to
do backups real soon now...


--
----------
Scott Burris
UCLA Campus Network Services
cnetslb@oac.ucla.edu (213) 206-4860 - OR - scott@pita.cns.ucla.edu
From: rlb@bsts00.uucp (Ronald (Ron) L. Bolin 3945 snk=)
Newsgroups: comp.unix.bsd
Subject: Missing Includes in 386BSD
Date: 15 Apr 92 12:25:07 GMT
Reply-To: gatech!sbmsg1!bsts00!rlb
Distribution: usa
Organization: BellSouth Services, Switching Technical Support (BSS-STS), Altanta, GA 30375


Ther are several missing include files in the 386BSD floppy distb. Where 
can I find them? One I am especially interested in is 
/usr/src/sys.386bsd/i386/isa/wtreg.h

Can someone tell me what ftp site has the complete include file set for 386BSD
please.


Thank's

Ron
Newsgroups: comp.unix.bsd
From: manningc@marsh.cs.curtin.edu.au (COLIN ROBERT MANNING)
Subject: Mailing list?
Organization: Curtin University of Technology
Date: Thu, 16 Apr 1992 05:15:23 GMT


Hi,
	Is there a mailing list for 386BSD?

	If there is could someone let me know the address please.

	Thanks in advance.

	Colin Manning.

--

manningc@cain.cs.curtin.edu.au
From: pgd@compuram.bbt.se (Per Lindqvist)
Newsgroups: comp.unix.bsd
Subject: Re: ps/sps
Date: 11 Apr 92 05:57:22 GMT

jot@zevs.ifi.unit.no (Jo Torsmyr) writes:
: One more then -- My arrow keys does not work correctly with
: 'tcsh', they just display some numbers. When I think about it,
: the arrow keys does not work in 'elvis' either, am I using
: a wrong termcap entry or what?
Arrow keys, the function keys and the ALT key are not supported
by the terminal driver in 386BSD. 
The function keys not only don't work, but are toggling different
debug flags in the kernel!

-- 
Per Lindqvist

Internet: pgd@compuram.bbt.se   Fidonet: Per Lindqvist @ 2:201/332
Newsgroups: comp.unix.bsd