HDTenEightyP/NetNews huggingface dataset:
From: dri@gl.pitt.edu (Paul)
Newsgroups: comp.unix.bsd
Subject: /dev/lp and LARGEW configurations
Date: 11 Sep 92 01:02:21 GMT

I have a quick question about the lp.c patch in the unofficial/terry
directory on agate.berkeley.edu for 386bsd-0.1.

I have applied the patch to the various files and double checked the
changes, and when I build a new kernel with the GENERICISA configuration
I get a reboot after trying to print something to /dev/lp (I did mknod).

More exactly the printer starts to spit out a ROOT banner page and then
the system softreboots.

Has anyone else had this difficulty or do I have a small error I
created?

BTW, when I use the LARGE configuration the kernel builds but when I
reboot with the new kernel the boot loader complains that the file
(386bsd) is too large to load, andd tries to load 386bsd.alt and
386bsd.old.  What is causing this? 

So, that is two quick questions, but oh well.  Any help would be great.
Please respond via e-mail because I have yet to catch up on this
newgroup, and I want to read all messages.

dri@apollo.gl.pitt.edu
__
Newsgroups: comp.unix.bsd
From: stark@cs.sunysb.edu (Gene Stark)
Subject: Program dies with FP Exception
Organization: SUNY at Stony Brook Computer Science Dept.
Date: Sun, 13 Sep 1992 05:26:50 GMT

Here's a tough one I've been trying to track down -- maybe somebody out there
who knows more can guess what is going on.

I am running 386BSD on a 486/33 system with 4MB RAM and a 210MB Connor IDE
drive.  A program I was working on dies on Signal 8 (Floating point exception)
in a perfectly repeatable fashion.  It is not so easy to tell where the
exception actually comes from, though, because the signal seems to be getting
delivered to the process much later, when it is leaving the system after
a call to "write".  I haven't been able to get a small test program that
repeats the bug, however there seem to be several crucial elements involved:

	(1)  A call to "atof", which returns a double that is then
		stored in a temporary on the stack.  Removing the call
		removes the error.

	(2)  The actual magnitude of the number being converted by "atof".
		I found that the string "1e10" and "1e12" cause the error,
		but "1e9", "1e6", and "0.0" do not.

	(3)  Some later "write" system calls.  The signal is actually
		delivered on the fourth call to write after the atof.
		What is happening in the interim is just C code without
		any other system calls.  I do not know what causes the
		signal to get delivered when it actually does.

After a lot of debugging, I boiled the problem down to this section of
source code:

	lp->token.value.flot = atof("1e10");

This compiles (no optimization) to the following:

	pushl $LC10
	call _atof
	addl $-8,%esp
	fstpl (%esp)		# This instruction seems to be the culprit
	popl %eax
	popl %edx
	movl 8(%ebp),%ecx
	movl %eax,20(%ecx)
	movl %edx,24(%ecx)

Removing the "fstpl" instruction removes the error.  Placing the code:

	pushl $1
	call _sleep

immediately after the "fstpl" instruction also removes the error.

Taking the code out of context and putting it in a small test program
does not produce the error, so presumably there is some interaction with
the virtual memory state.

I also tried putting the instruction

	movl $0,(%esp)

just after the fstpl instruction, on the theory that maybe the fstpl
was causing a page fault with bad consequences, but this did not eliminate
the error.

So, are these enough clues that somebody who knows more than I do can
guess what the problem might be?  Any help appreciated.

						- Gene Stark



Newsgroups: comp.unix.bsd
From: sef@kithrup.COM (Sean Eric Fagan)
Subject: Re: AT&T Long Distance Boycott (was: BNR2SS, Mach, and The Lawsuit)
Organization: Kithrup Enterprises, Ltd.
Date: Tue, 08 Sep 1992 09:28:10 GMT

In article <1992Sep7.153453.7370@pegasus.com> richard@pegasus.com (Richard Foulk) writes:
>If you're saying that POSIX specifies *everything* necessary to build
>those GNU products, I think you are mistaken.

I am saying that I have built those GNU products using a library and header
file set that had been written to be ANSI and POSIX conformant.

I think you are very, very much behind the times.  1003.1 specifies a *lot*,
and is more than enough for an application.  It doesn't have sockets or any
other form of networking; it also doesn't have a couple of other things.
But none of the programs I built needed it.

One thing to bear in mind is that the GNU BFD library is almost completely
self-contained, since it needs to be used for cross-compilation systems.  As
a result, things like the COFF and debugging symbol formats are embedded in
the BFD library.  That's how I got make, for example, to compile in my
admittedly limited library:  I used BFD headers to deal with the archive
file format.

And, in case I haven't made this clear:  I *DID* build these.  I did not use
any vendor library or header file, and started out with an extremely limited
library that was written to be used in an embedded system, and be only
ANSI-conformant.  I added to it by trying to compile the applications I was
interested in, and either recoded or added to the library, or,
occassionally, both.  And all the recoding I did was to make it work with
the "POSIX way," and was surprisingly little (mostly some small routines to
simulate a BSD signal environment on a POSIX signal environment).

You should try to actually do something before you claim it can't be done.
I did, and was quite (happily) surprised.

-- 
Sean Eric Fagan  | "You can't get lost in one room, no matter how
sef@kithrup.COM  |  little effort you make to learn your way around."
-----------------+    -- William E Davidsen (william@crd.GE.COM)
Any opinions expressed are my own, and generally unpopular with others.
Newsgroups: comp.unix.bsd
From: duzan@daffy.cis.udel.edu (Gary D. Duzan)
Subject: Re: 386BSD PARTIAL PATCH KIT NOW AVAILABLE
Organization: Your Organization Could Be Here!
Date: Tue, 15 Sep 1992 02:39:02 GMT

   Applying these patches to my newly unpacked src01 distribution
caused a couple problems with nested comments in init_main.c (the patch
date, I assume). It was a simple fix, but it is a bit annoying in an
official (or semi-official) distribution.

                                   Gary D. Duzan
                                   Network Administrator
                                   Delaware State Hospital



-- 
                             duzan@cis.udel.edu
   _o_                       ------------------                         _o_
 [|o o|]       Virtual Reality? No thanks, I've already got one.      [|o o|]
  |_O_|       Disclaimer: I have no idea what I am talking about.      |_O_|
From: jks@teal.csn.org (John Stevenson)
Newsgroups: comp.unix.bsd
Subject: Re: new boot roms
Date: 6 Sep 92 21:25:45 GMT
Organization: Colorado SuperNet, Inc.

eje@irenaeus.mlo.dec.com (Eric James Ewanco) writes:


>In article <183c4vINNfit@maverick.ksu.ksu.edu>, brtmac@maverick.ksu.ksu.edu (Brett McCoy) writes:
>> From: brtmac@maverick.ksu.ksu.edu (Brett McCoy)
>> Subject: new boot roms
>> Date: 2 Sep 1992 16:36:31 -0500

>> Okay, here's a thought.  Why doesn't someone write up some new boot
>> room code that would make a PC act a lot like a Sun when you turn it
>> on.  Get rid of all the gunky MS-DOS support.  Put in a nice little
>> monitor to examine memory and various registers and i/o ports and
>> allow easy booting from any device and any partition on that device.

>I think that is an excellent idea -- in fact I think hosing the BIOS is going
>to be a necessary step in moving to more advanced operating systems.  BIOS is
>out of date.  We need SCSI support in the ROMs, a monitor, and flexible booting
>choices.  We need BIOS code written in protected mode (like IBM's PS/2 code),
>not in real mode.  We need support for seven disk drives and other things.

>> This is far, far beyond any skills I have, but it seems like it might
>> be worthwhile and would solve a lot of the problems and workarounds
>> that people are having and using now.  Maybe someone should get on
>> AMI's or Phoenix's back and get them to add some support for other
>> OS's than MS-DOS in their boot code.

>Some company should propose a standard.  Maybe Digital.  IBM if they don't try
>to extract license fees from everyone.

>With 1 MB flash ROMs 1 mm thick, 8 mm wide and 15 cm long, we can afford to put
>a lot of ROM in PCs and put lots of stuff in it.  With memory management we can
>swap unused ROM out or compatibility ROM in.

>It is certainly something desparately needed.
>--
>/=============================================================================\
>| Eric Ewanco - Software Engineer     For the rash and outrageous opinions ex-|
>| Digital Equipment Corp, Maynard MA  pressed herein I alone am responsible;  |
>| ewanco@kalvin.enet.dec.com          they do not belong to DIGITAL(TM).      |
>\==============================- 2 Th 2:15 -==================================

There is just such a standard currently in the works. It is called
IEEE Draft Std p1275/d3 "Standard for boot firmware" 
and is similar to the sun booting system. Check with Ieee for a draft copy..
This does seem to be the way of the future for firmware.
good luck.
.sig file when I grow up.
bye
.
/
From: comrade@uniwa.uwa.edu.au (Peter Cooper)
Newsgroups: comp.unix.bsd
Subject: Re: 386bsd -- The New Newsgroup <Summary>
Date: 15 Sep 1992 11:31:36 +0800
Organization: The University of Westrn Australia
NNTP-Posting-Host: uniwa.uwa.edu.au

jcargill@grilled.cs.wisc.edu (Jon Cargille) writes:

>>In a soundbite
>>
>>	comp.os.bsd
>>	comp.os.bsd.pc-clone
>>
>>Which would cover bsd386, 386/bsd, mach-386, BNRSS-386, (the last two
>>only in regard to their BSD nature, not their mach nature)
>>

>Hate it, hate it, hate it.  Why should people have to read about
>systems they're not interested it, just because they're (possibly)
>similar?

It's not just (possible) similarity.  It's more than 90% of the code.
It's the whole user philosophy.  It's the huge number of programs that
have been written for this family of operating systems.  BSD.  It's more
than just a state of mind :)

>By this reasoning, we could just do away with newgroups altogether,
>and revert to one top-level group called 'news'.  If everyone had
>*really* nifty threaded newsreaders, it might work...  Not!

For most users, and even kernel hackers, it is difficult to find more
than small differences between each *implementation* of BSD.  None of
the above mentioned OS's have diverged enough to justify stuffing up the
usenet namespace for some really stupid politiking.

A modernish BSD on a VAX is similar to a modern BSD on an HP300, is
very similar to a modern BSD on a 386.  Software generally "just
compiles" (hahaha).  There is a justification for separate groups for
each implementation (after all, you've got all of those messy device
drivers ...) but none for a seperate *hierarchy* "go it alone cos
we're soooo much different from everyone else".


Peter

-- 
email:  comrade@uniwa.uwa.edu.au   snail:  Peter Cooper
fax:    +61 9 380 1041                     Guild of Undergraduates
phone:  +61 9 380 3929                     University of Western Australia
"It was the banana that did it!" - Julia Marley
Newsgroups: comp.unix.bsd
From: michael@uni-paderborn.de (Michael Schmidt)
Subject: Re: 386BSD #!/bin/csh
Organization: Uni Paderborn, Germany
Distribution: comp
Date: Thu, 10 Sep 1992 10:24:16 GMT

>>>>> About Re: 386BSD #!/bin/csh, Terry Lambert said:

Terry> In article <TRI.92Sep9011202@supergirl.hut.fi>
Terry> Timo.Rinne@hut.fi writes:

>386bsd 0.1 doesn't seem to respect #! in beginning
>of the shell scripts, Anyone knows why? Fixes?

Terry> Instead of:

Terry> 	#!/bin/sh
Terry> 	#
Terry> 	...

Terry> use:

Terry> 	:
Terry> 	#
Terry> 	...

Terry> This will result in invocation of /bin/sh.  Sorry; no
Terry> workaround known to make it execute csh instead.

Ooops. The patch to kern_execve in
agate.berkeley.edu:pub/386BSD/386bsd-0.1/unofficial/williams/kern_shell.0_1
works for me (somehow (;-).
--
      Michael Schmidt, FB 17, Uni-GH Paderborn, Warburgerstr. 100,
                     D-4790 Paderborn, West Germany
Mail:   michael@pbinfo.UUCP         or          michael@uni-paderborn.de
From: lmjm@doc.ic.ac.uk (Lee M J McLoughlin)
Newsgroups: comp.unix.bsd
Subject: Re: Archive site?
Date: 9 Sep 92 14:43:09 GMT
Organization: Dept. of Computing, Imperial College, London. U.K.
NNTP-Posting-Host: swan.doc.ic.ac.uk
In-reply-to: beacker@babylon.wpd.sgi.com's message of 8 Sep 92 23:10:48 GMT

In article <pjv5sho@fido.asd.sgi.com> beacker@babylon.wpd.sgi.com (Brad Eacker) writes:

Brad>      Now that this group is no longer being mailed out.  I was
Brad> wondering if there is an archive site available that compiles all
Brad> the postings from this group?
Brad>              Thanks in advance for any info,
Brad>                     Brad Eacker (beacker@sgi.com)

src.doc.ic.ac.uk:Usenix/comp.unix.bsd
--
--
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
Newsgroups: comp.unix.bsd
From: sef@kithrup.COM (Sean Eric Fagan)
Subject: Re: AT&T Long Distance Boycott (was: BNR2SS, Mach, and The Lawsuit)
Organization: Kithrup Enterprises, Ltd.
Date: Tue, 08 Sep 1992 19:20:00 GMT

In article <1992Sep8.134824.5149@pegasus.com> richard@pegasus.com (Richard Foulk) writes:
>A good example of the problem that half a standard (POSIX) creates!  Take
>a look at just about any of the larger products that have crossed over
>from the DOS world.  They all use their own incompatible version of a
>termcap-like library.

A good example of what a closed mind creates.

The termcap library I used was the Net/2 termcap library.  Since I was
creating a library suite that could be used without any of the system's
library or header files, I obviously couldn't use the system termcap library.

Sad situation.

-- 
Sean Eric Fagan  | "You can't get lost in one room, no matter how
sef@kithrup.COM  |  little effort you make to learn your way around."
-----------------+    -- William E Davidsen (william@crd.GE.COM)
Any opinions expressed are my own, and generally unpopular with others.
From: brtmac@maverick.ksu.ksu.edu (Brett McCoy)
Newsgroups: comp.unix.bsd
Subject: Re: More on X386 1.2E 1.0.1 startup problems
Date: 8 Sep 92 13:49:30
Organization: Kansas State University
NNTP-Posting-Host: maverick.ksu.ksu.edu
In-reply-to: tgt@neon.ecn.purdue.edu's message of Tue, 8 Sep 1992 04:58:13 GMT

In article <1992Sep8.045813.11493@noose.ecn.purdue.edu> tgt@neon.ecn.purdue.edu (Conan the Librarian) writes:

>Regarding my being unable to startup X386 1.2E on my system
>(I get a blank screen and then nothing...apparently xinit is 
>gagging) someone suggested that the 386bsd kernel packed with
>the X386 1.2E 1.0.1 binaries on agate.berkeley.edu doesn't work.
>Is this true?  If so, could someone either A) tell me where
>I can get a kernel which will work with X386 or B) tell me
>what the kernel problem is and where the patches are, so I
>can attempt a kernel remake myself?

I could not get that kernel to work.  Patching the sources and
building my own got me a working kernel.  The patches are in with
the X distribution.

>Lastly, is anyone going to place the X386 1.2E 1.0.2 binaries
>in an archive, like on agate?  I keep hearing people say
>"check the pub/incoming/X386 directory" but boys, there's
>nothing there!

Do an anon ftp to agate, then do a cd pub/incoming/X386.  Then
do a 'dir' and walla, there it is.  The incoming directory does
not have read permissions for the world so you have to know what
you are looking for.  It's impossible to get a listing of the
files that are there.

++Brett;
Newsgroups: comp.unix.bsd
From: mark@student.business.uwo.ca (Mark Bramwell CS Staff)
Subject: 2 types of X386 on agate?
Organization: University of Western Ontario
Date: Sat, 5 Sep 1992 17:44:22 GMT

There seems to be two versions of X on agate.  One is off the 386BSD
directory and seems to follow 'normal' directory names.

the 2nd version, is in incoming/X386 and seems to follow a X386 directory
structure.  Which you have people been using.

I have tried the first one, but can not get it to run.

Other than extracting off root, and verifying Xconfig is ok, what else
is required to get it going under 386BSD.


mark@student.business.uwo.ca (Mark Bramwell CS Staff)
Western Business School  --  London, Ontario
Newsgroups: comp.unix.bsd
From: bremner@cs.sfu.ca (David Bremner)
Subject: Re: 386bsd -- The New Newsgroup
Reply-To: bremner@cs.sfu.ca (David Bremner)
Organization: CSS, Simon Fraser University, Burnaby, B.C., Canada
Date: Wed, 9 Sep 1992 02:20:07 GMT

In article <1992Sep8.203503.10969@col.hp.com> bdale@col.hp.com (Bdale Garbee) writes:
>wjolitz@soda.berkeley.edu (William F. Jolitz) writes:
>> 	comp.os.386bsd		(general questions and trivia)
>>      [ a zillion subgroups deleted ]
>
>Actually, I'd probably be more interested in seeing a single comp.os.386bsd
>than in seeing a set of groups this fragmented.  

I'd second Bdale's comment.  More importantly, why comp.os.386bsd, why
not comp.os.bsd.386, or to avoid the confusion with BSDI's product,
comp.os.bsd.386bsd.  Why do I say this, other than to burn inodes? Well, what 
about comp.os.bsd.sparc and comp.os.bsd.mips?  I hope that there will 
eventually be free BSD based systems for more than just intel x86 based 
architectures.  Heck, there are already.

David

-- 
bremner@cs.sfu.ca 				          ubc-cs!fornax!bremner
Newsgroups: comp.unix.bsd
From: st923150@pip.cc.brandeis.edu (Benjamin A. Tober)
Subject: Re: Shared Libs for X11?, was Re: 386bsd -- The New Newsgroup
Reply-To: st923150@pip.cc.brandeis.edu
Organization: Brandeis University
Date: Wed, 16 Sep 1992 02:34:16 GMT

Yes, correct, the same RAM can be aliased as arbitrarily many segments.  A lot
of Unixes do protect the text from being scribbled on, however, in which case
a kernel extension (but a pretty trivial one, like I said) would be needed.  I
dunno how 386BSD is on this, I haven't studied the kernel extensively.
-ben
Newsgroups: comp.unix.bsd
From: "Michael Squires" <mikes@moose.cs.indiana.edu>
Subject: Re: Fixed: Runs at 8MHz, Crashes at 33MHz, 386bsd
Summary: May be memory bus problem 
Keywords: bug
Organization: Indiana University, Bloomington
Date: Sat, 12 Sep 1992 13:46:59 -0500

When running SCO XENIX 386 and UNIX 386 on various clones it became clear that
all brands of clone were not alike and all brands of memory were not alike.
In some cases I know that there were problems with the memory bus caused by
poor design or unreliable DRAM.  I personally would not try to run 386 UNIX
on a really cheap motherboard, unless I'd already tested in some other way
(and the Checkit/AMIDIAG type of tester doesn't stress the hardware enough
to find the problems).  

I wonder if there is a program that is small enough to fit on the boot disk
which would really stress memory which could be used to test prospective
clones in the store or at the hamfest/computerfest/Trenton/Dayton Hamvention?

-- 

Mike Squires (mikes@iuvax.cs.indiana.edu)     812 855 3974 (w) 812 333 6564 (h)
mikes@iuvax.cs.indiana.edu          546 N Park Ridge Rd., Bloomington, IN 47408
From: andrew@zone4.ocunix.on.ca (Andrew Low)
Newsgroups: comp.unix.bsd
Distribution: world
Subject: Re: 386BSD - Seems to stop my disks from booting...
Organization: Zone4
Date: Sun, 13 Sep 92 14:46:52 GMT

In article <kjb.716286770@godzilla.cgl.citri.edu.au> 
kjb@cgl.citri.edu.au (Kendall Bennett) writes:
>120M Western Digitial 2120 hard disks (WDC AC2120M). 

IDE drives *should* be used in their native geometry, this often means
setting your BIOS up to have a user defined entry which is correct for
your particular drive.  Dos will work with this type of BIOS setting 
as well.

>Damn. I also worked out that if I do a shutdown -to386bsd, it puts the
>system back into the non-bootable state, and a shutdown -todos makes
>MSDOS startable again, but I have to load OS/2 2.0 from floppies to get
>boot manage to work again (using fdisk).

Sounds like the MBR (master boot record) is used by all three of these
operations.  'shutdown -to386bsd' puts BSD boot code there, the -todos
option tries to put MSDOS boot code there and the OS2 boot manager 
lives in the same place.

>Any clues pppplllleaaasssse?

Try using the 'newbootables' from agate.berkeley.edu, these worked
for me when the original 0.1 disks did not.  Something minor was changed
in the boot code I believe.  That and find out the native geometry of
your IDE drive, it might make all the difference in the world.

+/+\+/+\+/+chew carefully/+\+/+\+/+\+/+\+/+\+/+\+/+\+/+\+/+\+/+\+/+\+/+\+/+\+/+
Roo [andrew@zone4.ocunix.on.ca] m a c h i n e l o v e h a t e f e a r v o i d .
               "dreams are all that separate us from the machines"
From: dj@godot.co.uk (DJ Walker-Morgan)
Newsgroups: comp.unix.bsd
Subject: Re: Are you sure UNIX is a trade mark?
Date: 11 Sep 92 14:58:27 GMT
Reply-To: dj@godot.co.uk
Organization: MicroMuse - The SPARC dudes

In article 18ns8rINNd81@agate.berkeley.edu, ag@cogsci.Berkeley.EDU (Keith Gabryelski) writes:
>When I four years old I used the words `Kleenex' and `Band-Aid' to
>refer to generic products of their respected kind.  Neither company
>paid much attention to my obviously wrong use of their trademarked
>brand names.
>
>Both companies still have trademark rights to the names (albeit
>possibly on shakey ground).

Well, try these, Jacuzzi and Biro. Both names which have lawyers in the UK scouring
the press for their "misuse".


---

============================================================================
  dj@micromuse.co.uk    |"In a perfect world we'd all sing in tune
  Voice +44-71-352-7774 | but this is reality so give some room" 
  Fax   +44-71-351-7834 |                           (Sir) William Bragg
------------------------+---------------------------------------------------
 Non-standard Disclaimer : "I didn't do it, it wasn't me, I wasn't there"
From: wjolitz@soda.berkeley.edu (William F. Jolitz)
Newsgroups: comp.unix.bsd
Subject: Re: 3 button mouse for X386
Date: 12 Sep 1992 05:41:49 GMT
Organization: U.C. Berkeley, CS Undergraduate Association
NNTP-Posting-Host: soda.berkeley.edu
Keywords: X386 386bsd



In article <3577@bcstec.ca.boeing.com> rjw9917@bcstec.ca.boeing.com (Robert J. Willard) writes:
>I've got 386bsd and X386 running smoothly, using
>a microsoft serial mouse.  However, I'm accustomed
>to using a 3 button mouse with X and am wondering
>which mouse (preferably a CHEAP one) would be good.
>Any ideas?

Well, I just bought a mouse for $ 9.95 from Whole Earth Access -- an Access It
3-button mouse. It's so cheap it doesn't even have a mfr name on it,
but it works great!. It works MS (Microsoft mode) and PC (Mouse system mode)
selectably. In any case, it's always best to get a selectable mouse.

Lynne.
Newsgroups: comp.unix.bsd
From: hasty@netcom.com (Amancio Hasty Jr)
Newsgroups: comp.unix.bsd
Subject: If you are using XFree86...
Keywords: X386
Date: 13 Sep 92 16:46:10 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest)

If you are using Xfree86 or X386 1.0.1, please send me the
following info:

VGA:	vga brand, model number and memory
CPU:	brand, type, cache size, memory

From your Xconfig file:
Xconfig:
clock:		your clock values that you are using.
modeDB entry:	mode, clock value, horizontal & vertical timings 
		which you are actually using.


Info on any successfull ports to 386bsd of popular programs like
xtank, window-managers,  etc.

And, if you are having any problems with the server.

The compilation will be posted back.

So far except for one person, everyone that has send me
e-mail with reported problems has been able to succesfully
use the stock XFree86 in agate.berkeley.edu:/pub/incoming/X386.

Thank you,
Amancio Hasty