HDTenEightyP/NetNews huggingface dataset:
From: adh@cbnewsi.cb.att.com (andrew.d.hay)
Subject: Re: (long) Microport/286 won't boot (was: Re: Microport cactus, newsfeed dead, spouse rabid)
Organization: AT&T
Date: Fri, 31 Jul 1992 12:28:22 GMT
Keywords: Microport 286 System V/AT usenet boot primary disk failure broken

In article <1992Jul31.074716.21851@chpc.utexas.edu> jonathan@chpc.utexas.edu (Jonathan Thornburg) writes:
[]
"(Aside #2 -- does anyone have an disk defragmenter for Microport that
"works without having to dump and restore everything?)

i've got 'disk tuner' from AIM tech.  it was for my 3b1, but delivered
in src (!) form...  dunno where they are, of if they are...

-- 
		+--------------------------------------------------------------+
Andrew Hay	|         I want to lie, shipwrecked and comatose -	       |
a_d_hay@att.com	|              Drinking fresh mango juice...		       |
		+--------------------------------------------------------------+
From: wjolitz@soda.berkeley.edu (William F. Jolitz)
Newsgroups: comp.unix.bsd
Subject: Re: 386BSD 0.1 release
Date: 30 Jul 1992 20:19:39 GMT
Organization: U.C. Berkeley, CS Undergraduate Association
NNTP-Posting-Host: soda.berkeley.edu

In article <157ovgINN2bo@ghidra.UU.NET> revell@uunet.uu.net (James R Revell Jr) writes:
>In article <14c63bINNh22@agate.berkeley.edu> wjolitz@soda.berkeley.edu (William F. Jolitz) writes:
>} Do *not* obtain 386BSD from uunet! BSDI is funded partially from UUNET
>} coffers, and those idiots still see 386BSD as a rival to their hopes.
>} 
>} As with other related situations, they have come up with "plausibly deniable"
>} reasons to not provide information that they feel affects their competitive
>} advantages.
>
>Well, despite what Bill may say or think, this is not true.

I still disagree, and maintain the above. There's an easy way to correct
this if it has changed, and become "stale" information. I'm waiting...

Have Rick Adams utter the following phrase: "UUNET is unrelated to BSDI
and does not act on it's behalf". Then I'll withdraw my objections stated.
Sounds simple to me.

>I said before that UUNET would drop our no-binaries policy when I got
>the new disks up on the archive, and since I've just finished moving
>the archive from uunet.uu.net to the new 9 GB on ftp.uu.net, that
>policy is now history.

I can't verify this, but if it has happened that is a positive development
for those who only have access via UUNET. It's a pity that this was not this
way from the start. As the rest of my posting stated, I think the idea of
UUNET per se is not a bad thing. Nice to know that some people do grow up.

Bill
From: osynw@warp.mhd.montana.edu (Nate Williams)
Newsgroups: comp.unix.bsd
Subject: Re: emacs type editor wanted
Keywords: emacs no_vi
Date: 26 Jul 92 05:40:27 GMT
Article-I.D.: coe.1992Jul26.054027.28848
Organization: /usr/local/lib/MYORG

In article <1992Jul25.223126.26886@NeoSoft.com> gclarkii@NeoSoft.com (Gary Clark II) writes:
>Hello,
>I'm trying to find a emacs type editor that has already been ported to
>the 0.1 version of 386BSD.  I can get GNU Emacs, but I'm trying to avoid
>the size (I only have about 30 megs free...).  I really do hate vi though.
>
>Gary Clark II  *N5VMF*
>gclarkii@tghost.gbdata.com
>gclarkii@sugar.neosoft.com
>

I just ported (not really) uemacs 3.11a to 386BSD.  I grabbed the source
I had for the DECstation, and I had to change two lines in one of the
files to include <sys/ioctl_compat.h> just before <sys/ioctl.h>, and 
things compiled w/out a hitch.

Also, since uemacs and beav (binary editor) have the same roots, I
also ported beav 1.32 to 386BSD.  Both work great, with one little
funny thing so far. When run under screen, you must type CTRL-V twice
to do a page-down.  Under a normal tty it works fine, so I suspect
screen is doing something funny.

If you want the source, I could put it up for ftp somewhere, but it
was SIMPLE!!! to compile.

I am also working on mush 7.2.4, but I am getting Segmentation faults
in sglob.  Don't know why, but I suspect it's some assumption I made
when changing things to compile.


Nate
-- 
osynw@terra.oscs.montana.edu |  A hacker w/out a home.  Anyone  interested
work: (406) 994-5991         |  in a used Sys. Admin., which alot of 
home: (406) 586-0579         |  good hacks left?
Newsgroups: comp.unix.bsd
From: musik@iastate.edu ()
Subject: Some errors using cc under 386bsd r0.1
Organization: Iowa State University, Ames, IA
Date: Wed, 29 Jul 1992 18:01:05 GMT

Strange little error coming up when trying to compile
with cc.  I've just been writing some silly little
utilities, some of which require command line args.
I've compiled the sources (which are very short, very
basic, very simple) on other machines, i.e. HP/UX, Ultrix,
IBM PC clone, etc. and they work.  However, when I try
to compile anything that uses argc and argv in cc on 386bsd,
somehow, even though I declare it as an int, argc is
being made into (I think) an unsigned long.  Anyway...
It comes back with numbers in the billions instead of
the expected 2 or 3 command line args count.  :)

Any ideas?
Should I just ditch cc and go with gcc?
Or is the error somewhere else?

Thanks a mil...

DG
musik@iastate.edu

Newsgroups: comp.unix.bsd
From: cflatter@nrao.edu (Chris Flatters)
Subject: Re: Jolitz 386BSD-0.1 -- floating point perform
Reply-To: cflatter@nrao.edu
Organization: NRAO
Date: Fri, 24 Jul 1992 16:16:46 GMT

In article l6qc51INN1gu@neuro.usc.edu, merlin@neuro.usc.edu (merlin) writes:
>I have most of the US Army BRLCAD three dimensional CSG modeling and
>distributed ray tracing system ported to the Jolitz 386BSD-0.1.  But,
>I am getting only about one fifth of the floating point performance
>previously measured using AT&T pcc and GNU gcc 1.4x on ATT UNIX SYSV.
>
>Does the compiler default to '387 emulation?  Is there some flag which
>needs to be set to actually use the coprocessor?  Or are there reasons
>386BSD-0.1 would exhibit relatively poor floating point performance?

I ran some checks last night and 386BSD is certainly exploiting the coprocessor.
These are the results from the Plum2 benchmark (See section 8.2 of "C++
Programming Guidelines" by Thomas Plum and Dan Saks.  The results are
the average time for a register int, auto short, auto long and auto float
operation and the average time to call and return from an empty function.
Times are in nominal milliseconds (CLOCKS_PER_SEC was missing from <time.h>
so I guessed a value of 100 --- I now think that it should have been 60.
The tests were performed on a CompuAdd 325s (25MHz 80387SX CPU) with a
Cyrix 83S87 FasMath coprocessor.

                       register      auto      auto  function      auto
                            int     short      long  call+ret    double
            386BSD gcc    0.178     0.448     0.474      1.62      4.94  
         386BSD gcc -O    0.159     0.207     0.159      1.75      3.37  

The ration of floating-point time to auto long is 21.2 (with optimization)
which is in the correct ball park for a 386SX/387SX system but a little
on the long size.

As a control, I made a copy of the dist.fs disk with a compiled version of
bench2 on it and booted it on my portable: a 16 MHz 80386SX system without
a coprocessor.  The results were

                       register      auto      auto  function      auto
                            int     short      long  call+ret    double
         386BSD gcc -O    0.240     0.317     0.242      2.32       346  

Note that the ratio of of f-p time to auto long is now 1429.8 --- in other
words emulation is more than 60 times slower than the coprocessor.  Unless
BRLCAD uses very little floating-point I believe that the coprocessor is
active on Alexander-James Annala's machine too (If Alexander-James wants to
try these tests I'll send him the source code if he drops me a line).

For final comparison, I have some old figures from Linux with gcc 2.1.
Using the register int time to place the results on the same scale as
the 25MHz results above the mean time for a f-p operation was 2.09 usec
without optimization and 0.936 usec at -O1 and above.

	Chris Flatters
	cflatter@nrao.edu
Newsgroups: comp.unix.bsd
From: bzs@ussr.std.com (Barry Shein)
Subject: Re: Best Reaction to AT&T Suit == Join LPF
Organization: The World
	<1992Jul24.013957.10852@algor2.algorists.com>
Date: Sat, 25 Jul 1992 21:31:43 GMT


From: jeffrey@algor2.algorists.com (Jeffrey Kegler)
>I should add IMHO to the above, but I like to keep subject lines
>short.  :-) You can contact the League for Programming Freedom as
>shown below.  I believe the LPF is the best instrument for reacting to
>these situations.

Unfortunately (IMHBCO) RMS stated on the LPF mailing list yesterday
that he does not believe LPF has any stake in the USL/BSDI suit.

I think Richard is mistaken on this one and sincerely hope he and LPF
recant that position.

--
        -Barry Shein

Software Tool & Die    | bzs@world.std.com          | uunet!world!bzs
Purveyors to the Trade | Voice: 617-739-0202        | Login: 617-739-WRLD
From: bill@prijat.cs.uofs.edu (Bill Gunshannon)
Newsgroups: comp.unix.bsd
Subject: Re: AT&T sues BSDI
Date: 22 Jul 92 16:04:38 GMT
Reply-To: bill@platypus.uofs.edu
Organization: University of Scranton, Scranton, PA

In article <QUANSTRO.92Jul21140234@lars.StOlaf.edu>, quanstro@lars.StOlaf.edu (goon) writes:
|> 
|>    Imminent death of free-UN*X systems predicted...
|> 
|> Wouldn't that be great!
|> 

Well, I wouldn't hold my breath.  Back in 1981 when I got my first UNIX
system (actually XENIX) for my home I was told by most of the people I
worked with (government employees, no less) that I was crazy cause UNIX
was never going to catch on. Hmmmm.

Personally, I hope (and expect) that UNIX will loose this one.  But one
way or the other, I doubt that we are seeing the imminent demise of UNIX.

As an interesting point, protection in court for things like trade secret
status usually requires that the Plaintif has vigorously defended the
secrecy and proprietary-ness of the secret.  Based on the fact that AT&T
pushed schools to take UNIX and use it in teaching Operating Systems and
also it's active part in making SYSVID a standard that was used in defining
POSIX, aren't they in serious danger of a judge saying the whole shooting
match should be considered public domain??

I'm not a lawyer or a judge (and I don't play one on TV), I'm just curious.

bill

-- 

     Bill Gunshannon          |        If this statement wasn't here,
     bill@platypus.uofs.edu   |  This space would be left intentionally blank
     bill@tuatara.uofs.edu    |         #include <std.disclaimer.h>
From: bill@kepler.ucsd.edu (Bill Reynolds)
Newsgroups: comp.unix.bsd
Subject: Re: Removing 386BSD from the hard disk (FAQ)
Date: 22 Jul 92 13:33:05
Organization: Institute for Nonlinear Science, UCSD
Distribution: world
NNTP-Posting-Host: kepler.ucsd.edu
In-reply-to: danson@lgc.com's message of Tue, 21 Jul 1992 15:22:25 GMT



In article <1992Jul21.152225.2082@lgc.com> danson@lgc.com (Doug Anson) writes:

	Doug> After many hours rebuilding kernels, etc.. the time came
	Doug> for me to uninstall 386BSD so that I can continue with
	Doug> my work (arg!!).  Anyway, I just tried reinstalling DOS.
	Doug> I was able to produce a DOS partition (386BSD occupied
	Doug> my entire disk), format it and install the dos system
	Doug> onto it. When I then tried to reboot the machine off of
	Doug> the hdisk (thus DOS), my system can no longer boot off
	Doug> of the hdisk! It simply resets again and again after
	Doug> trying....

	Doug> Could it be that the some part of the 386BSD boot strap
	Doug> on the hdisk is still there? When I fdisked the hdisk in
	Doug> DOS everthing seemed to work fine.

This one is in the install notes, but it took me also about a day to
finally find it (thanks to Dwight Cass). I nominate this for entry
into the FAQ list.

From INSTALL.NOTES in the BSD distribution:

     To erase 386BSD from the dedicated disk, simply  refor-
mat  the  system. Some versions of MS-DOS require the master
boot record to be rewritten as well, using the MS-DOS "fdisk
/mbr" command.

     Other versions of MS-DOS require that the	boot  record
lose  its  validity before being rewritten by fdisk. This is
accomplished by cat'ing a file to the "raw" partition 'd' of
the  drive, "cat /386bsd >/dev/rwd0d", and then reformatting
under MS-DOS.  If you are using an old	version	of  MS-DOS,
you can use this technique to delete the 386BSD partition as
well. This technique usually works (not always, however). As
such,  we strongly recommend that you obtain the most up-to-
date version of MS-DOS (5.0 or better) and save yourself the
headache.


--
_______________________________________________________________________
Bill Reynolds        |  
bill@kepler.ucsd.edu |	
Newsgroups: comp.unix.bsd
From: danson@lgc.com (Doug Anson)
Subject: rpcgen for 386BSD
Keywords: 386BSD RPC
Organization: LandMark Graphics Corporation LGC
Date: Mon, 20 Jul 1992 12:27:42 GMT

Hi:

I noticed that rpcinfo and rpcgen do not appear in bsd 0.1.  Does anyone
know where the source for rpcinfo and rpcgen (non-TLI based) is located
for ftp? 

Also,  has anyone experienced problems when trying to read from two floppies
(i.e. tar xvf /dev/fd0a and tar xvf /dev/fd1a) at the same time?  I get
numerous fd seek etc errors.

Cheers,
Doug
--
-------------------------------------------
Doug Anson					
Internet: danson@lgc.com			
Phone:	  713-579-4739
SNAIL:    Landmark Graphics Corporation LGC	
	  333 Cypress Run			
	  Houston, TX 77094			
-------------------------------------------
From: ferrick@acsu.buffalo.edu (Patrick K. Ferrick)
Newsgroups: comp.unix.bsd
Subject: Adaptek 1742B: anybody using one?
Date: 22 Jul 92 01:50:20 GMT
Organization: UB


First, many thanks to Bill and Lynne for an outstanding effort.

A few of us are trying to organize a group purchase of motherboards to run
386bsd on.  (The list is 386bsd-mothers@cs.athabascau.ca, btw)  We're thinking
maybe EISA, and have heard that the Adaptek EISA/SCSI card has been used
successfully in "ISA mode".  We're plotting to get an extra board for Bill and
Lynne, so they'll have something to work with EISA on...(pretty clever, huh?).
If somebody could confirm that a 1742B does in fact work with 386bsd, we'd
sure appreciate it.  Thanks.

pat
Newsgroups: comp.unix.bsd
From: fredw@mks.com (Fred Walter)
Subject: 386BSD 0.1 dist.fs doesn't like 12 meg in my machine
Organization: Mortice Kern Systems Inc., Waterloo, Ontario, CANADA
Date: Mon, 27 Jul 1992 15:32:14 GMT

I could not get 386BSD 0.1 to install with 12 meg in my machine.
Booting off of the boot floppy I made from 'dist.fs' and typing install
resulted in : nothing happening.

Once I told my machine it only had 8 meg (via cmos settings; I didn't feel like
physically removing the memory) the install worked.

*but* it disklabeled/partitioned my drive incorrectly, putting a far-too-big
wd0b at the start of wd0a. I used disklabel -r -e to fix the size and
position of wd0b - I put it after wd0a (assuming that the sector postions
start at 0 and not at 1). Now, how do I tell my machine that this is supposed
to be swap space ? What do I need to do to prepare it ? (Where can I ftp or
otherwise get documentation ?)

BTW, thanx for second.drive.randy.

One nit - in trying to setup the swap space I managed to get a panic, and it
then dumped all over my hard disk, trashing the file system. What do I change
so that it won't trash my filesystem like that ? I'd prefer to be able to boot
from floppy and fix what caused the panic... 

	Thanx,
	fred
-- 
Disclaimer: everything I write is my *personal* opinion and does not represent
or reflect the opinion of the company which employs me.
Newsgroups: comp.unix.bsd
From: franky@duteca.et.tudelft.nl (Frank W. ten Wolde)
Subject: 386BSD-0.1 Install problem: can't relabel disk, etc...
Keywords: 386bsd
Organization: Delft University of Technology, Dept. of Electrical Engineering
Date: Tue, 28 Jul 1992 20:06:25 GMT

I'm having trouble installing 386BSD-0.1 to my system.

The 386BSD tiny floppy boots fine. When I type: 

	# install -debug

I get the following response:

	 bios finds: cyl 1001 heads 15 sectors 17
	Partitions:
	offset  size    type    flag
	0	0	0	0
	153765	101235	81	0
	0	0	0	0
	0	0	0	0
	0 MB free. You do not have enough free space on your drive
	to install 386 BSD in a new partition.

Yet, I have appr 73 Mb free on my ST1144AT drive. (Partition #2 contains
my Linux OS :-).

When I prepare a partition of type A5 on my disk and try to install again
(install -debug) I get:

	 bios finds: cyl 1001 heads 15 sectors 17
	Partitions:
	offset	size	type	flag
	17	153748	a5	0
	153765	101235	81	0
	0	0	0	0
	0	0	0	0
	Do you want to install <...> disk drive's 386BSD partition? (y/n) y
	making root size 143055 offset 17
	making swap size 10000 offset 143265
	label written at sector 17
	High level formatting of 386 BSD disk storage:
	...
	...
	super-block backups (for fsck -b #) at:
	32, ...
	...
	...
	...					, 134704, 138816
	newfs: ioctl (WDINFO): No such process
	newfs: /dev/rwd0a: can't rewrite disk label

and the installation fails again.
Can someone please explain? I also tries the fixit.fs boot floppy and
used disklabel. Then I get errors about not being able to find/write the
disk label and I get '/dev/rwd0a: invalid argument' errors.

My system is:	386/33 (unknown chipset)
		4 Mb core
		no NCP
		ST1144AT	(drive 1: 125Mb)
		ST251AT		(drive 2: 43Mb)
		SC499		(tape controller)

	
Thanks!

-Frank ten Wolde

--
#############################################################################
# Frank W. ten Wolde (PA3FMT)    | E-mail: franky@duteca.et.tudelft.nl
# Delft University of Technology |
# The Netherlands                |
Newsgroups: comp.unix.bsd
From: terry@thisbe.npd.Novell.COM (Terry Lambert)
Subject: Re: 386bsd 0.1 - Advice on bootstrap debugging needed.
Keywords: 386bsd boot wdboot
Organization: Novell NPD -- Sandy, UT
Date: Thu, 23 Jul 1992 21:39:47 GMT

In article <greg.711922033@hibp1.ecse.rpi.edu>, greg@ecse.rpi.edu (Greg) writes:
|> I've already ask this once before, but since the response was nearly
|> non-existsent, I'll try again. 
|> 
|> I seem to have a problem booting that is timing dependant. My machine will
|> boot off wd0 about 95 % the time when in low speed mode. In high speed (33MHz)
|> it boots only about 20% of the time.
|> 
|> My equipment:
|> 386-33 Advanced Integration Research motherboard (1 CHIPS & 2  ETEQ VLSIs)
|> Quantum 105lp IDE
|> Trident 8900 vga
|> Novell Ne2000 ethernet
|> 
|> 
|> I started to poke around in the boot stuff. I put a printf at the begining of
|> boot.c. I rebuilt wdboot and bootwd and then re-disklabeled. I verified that
|> boot.c was not reached when the boot failed. When it succeeded, I saw my
|> debugging message. I have tried to play with wdbootblk.c, but am getting   
|> nowhere. I tried to add code to write directly to the video memory so I can
|> see where the bootstrap fails. Years ago I dabbled in 8088 assemlbly language,
|> but I have forgotten most of what I knew. Of course, there have been substantial
|> changes to the instruction set since the 8088. It would be very helpful if 
|> someone could pass along the following things:  

This problem has to do with the fact that the "ready" on the controller isn't
being checked correctly.  Chris Demetriou (cgd@agate.berkeley.edu) has patches
available for download at agate.berkeley.edu.  Check out article #1912 or simply
download the patched boot image for dist.fs and fixit.fs, and the patches, if
you are planning on building your own kernel from sources.  The are in the
386bsd heirarchy unde 'unofficial'.

					Terry Lambert
					terry_lambert@gateway.novell.com
					terry@icarus.weber.edu
---
Disclaimer:  Any opinions in this posting are my own and not those of
my present or previous employers.
From: meissner@osf.org (Michael Meissner)
Newsgroups: comp.unix.bsd
Subject: Re: AT&T vs. BSDI --> 4.3BSD-NET2 distribution requires AT&T license!!!
Date: 28 Jul 92 19:32:43 GMT
	<1992Jul27.164228.28312@gateway.novell.com>
	<1992Jul27.193757.3628@kithrup.COM>
Organization: Open Software Foundation

In article <1992Jul27.193757.3628@kithrup.COM> sef@kithrup.COM (Sean
Eric Fagan) writes:

| >2)	OSF has licensed Mentat streams for inclusion, not AT&T.  The code
| >	is un-AT&T-encumbered, and runs on many diverse platforms (for
| >	instance, it also runs on VMS).
| 
| That's nice.  They also bought a SysVr3.x license, about three or four years
| ago, and the code they are shipping as "OSF/1," for both the macro- and
| micro-kernel stuff, still requires a USL source license, if you want source.

Try System V.2, not V.3.
--
Michael Meissner	email: meissner@osf.org		phone: 617-621-8861
Open Software Foundation, 11 Cambridge Center, Cambridge, MA, 02142

You are in a twisty little passage of standards, all conflicting.
Newsgroups: comp.unix.bsd
From: gwh@soda.berkeley.edu (George William Herbert)
Newsgroups: comp.unix.bsd
Subject: Berkeley Strikes Back?
Summary: It works both ways if it has to.
Date: 30 Jul 92 10:21:43 GMT
Organization: Dis-
NNTP-Posting-Host: soda.berkeley.edu


The "Berkeley License" currently gives anyone the right to use
BSD derived code in any way as long as it's clear it's at the
users risk and the license is kept on it.  That is not set in
stone.  Berkeley could conceivably pull the right for USL to
resell anything with "Copyright the Regents..." in it,
or derived therefrom.

How long would it take USL to make SVR4x BSD-Free?  Six months?
A year?  Eighteen months, plus some while the attorneys haggle?
The UC Regents don't lose any sales, but USL would...


-george william herbert
gwh@soda.berkeley.edu  gwh@lurnix.com  herbert@uchu.isu92.ac.jp until 28 aug
++  copyright (c)  george william herbert.       All rights except usenet   ++
++ transmission/use and inclusion in followup/reply articles/mail reserved. ++

Disclaimer: I sure as hell don't speak for UC Berkeley, it's Regents,
or anything else official.  Have a nice day 8-)
Newsgroups: comp.unix.bsd