HDTenEightyP/NetNews huggingface dataset:
From: ugewa001@unibi.uni-bielefeld.de (0134)
Subject: can't extract src01 and serial line problem
Date: Mon, 27 Jul 92 07:25:54 GMT
Organization: Universitaet Bielefeld
Keywords: src01, serial line, stty, extract
Followup-To: comp.unix.bsd


Hi there

I have been playing with bsd0.1 for a couple of days now and it's great,
but ...

I can't extrat the src01 distribution.

I put all the src01 files in the /tmp directory and then run extract.
It runs for about 20 mins, checks the files, then says something about
being almost ready and then quits. It complains about 
the missing file /tmp/install.src01

I have tried another src01 pack, (the first was from gatekeeper) but 
the results remain the same.

*****
The other one is probably even more basic. I have a Epson Lq-850 on the serial
line. Now I want to tell /dev/com2 to go into cs8,-parenb,-istrip mode. How can
this trick be done with bsd0.1. I am not familiar with the BSD-way of 
installing printers. (as you see)


Any help greatly appreciated
TIA



-- 
------------------------------------------------------------------------
Folker Meyer                      * "God is real,
Universitaet Bielefeld            *  unless declared integer."

Newsgroups: comp.unix.bsd
From: hasty@netcom.com (Amancio Hasty Jr)
Subject: Re: Writing a driver for QIC-40, floppy controller tape drives
Date: Tue, 28 Jul 92 22:52:48 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Keywords: QIC-40 tape

In article <151sfdINNreh@network.ucsd.edu> brian@ucsd.edu (Brian Kantor) writes:
>In article <greg.712272225@hibp1.ecse.rpi.edu> greg@ecse.rpi.edu (Greg) writes:
>>   Meanwhile, I wonder if anyone has any info on this type of drive. Right now,
>
>The documents describing the QIC interfaces are available from Quarter
>Inch Cartridge Standards, Inc, somewhere in the Bay Area on 805-963-3853.
>
>QIC-40 and QIC-80 apparently describe the tape formats.  QIC-117 is the
>floppy-controller-style interface.  Or so the people at Colorado Memory
>Systems say.
>
>I don't know how much they standards cost.  Our library has copies, but
>they're checked out right now so I haven't seen them.

The standards are for free! Just give the Standards a call an request
the standards --- thats all what I did to get the standards.

From what I heard from different sources QIC-40 is not easy to implement
(which can be construed as a challenge), also the QIC-40 demands stringent
timing constraints as to when to respond to the tape drive.

I know that sounds blasphemous but I am wondering if there is a dos
program capable of reading unix/file system which we can use to help us
backup our unix file systems. Currently, I have colorado tape drive
collecting dust and 300 MBs of binaries/sources. Not a pleasant scenario!


Cheers,
amancio



Newsgroups: comp.unix.bsd
From: wkt@rodos1.cs.adfa.oz.au (Warren Toomey)
Subject: 386BSD: /etc/rc's exit kills slattach(8)
Keywords: slattach SLIP etc/rc
Organization: Australian Defence Force Academy, Canberra, Australia
Date: Fri, 24 Jul 1992 01:40:14 GMT

Quick bug report, and workaround. /etc/rc's exit 0 (i.e what happens after
this) causes an slattach(8) in /etc/netstart to die. It's not getty and it
is after the exit 0, because I renamed getty -> betty and put a sleep 10
on the line above rc's exit 0.

I tried at least two slattach lines in /etc/netstart:

	slattach /dev/com2 9600
	slattach /dev/com2 9600 < /dev/null > /dev/null

Didn't try

	nohup slattach /dev/com2 9600

Workaround: 

	Manually restart the slattach once you log in.

Misc:
	I spent 3 hours trying to work out why my `network was down'
because of this :-(. Ifconfig reports sl0 being UP, even with the slattach
dead. Sigh.


  Warren Toomey VK1XWT, on the path to insanity
  No longer in the bowels of ADFA Comp Science.
   `Version 7 Job Control: just use ptrace(2).'
From: RLM@MAINE.MAINE.EDU (Robert L. Metcalf NV1A)
Newsgroups: comp.unix.bsd
Subject: SCSI controllers (Future Domain?)
Date: 29 Jul 92 12:30:46 GMT
Organization: University of Maine System

Are Adaptec SCSI controllers the only type that are supported by 386BSD?
Does anyone know if Future Domain SCSI controllers are compatable with
Adaptec?  Or, has anyone written a driver for Future Domain controllers?
(TMC-1650, TMC-1660, TMC-1670, or TMC-1680?)

The reason I am asking is that the Future Domain controllers sell for
around $150 and the Adaptec sell for $250-$450... :)

Thanks,
Robert
RLM@Maine.Maine.edu
Newsgroups: comp.unix.bsd
From: kaleb@thyme.jpl.nasa.gov (Kaleb Keithley)
Subject: Just a thought
Organization: Jet Propulsion Lab, Pasadena, CA
Date: Thu, 23 Jul 92 17:21:11 GMT

After struggling to surmount a plethora of niggling hardware problems,
I've finally managed to bring up 386BSD.

During one of my many installs, I was confounded at one step by the 
fact that 386BSD had usurped the Master Boot Record (MBR), which was 
insistent on booting 386BSD, even though it wasn't installed.  (Yes, 
I know about the D*S 'fdisk /mbr', but that doesn't work if you don't 
happen to have D*S 5 available, and you can't get to OS/2 because the 
machine is furiously trying to boot a non-existent 386BSD!, and no,
you really can't really run OS/2 on a floppy.)

After giving it five minutes of thought, I realized the rationale for
having done this.  Historically, UNIX has wanted/needed to be able to 
fall back to an older saved version of the kernel if it fails to find 
a bootable kernel image on the disk.  386BSD is no exception to this 
practice.

This is well and good, *but* IMHO, I like the method that ESIX, among
possible others, used for SVR4, which allows using the default MBR, 
and still allows for an attempt to load a fall-back kernel.

The ESIX install created 2..n UNIX partitions within the ESIX disk 
partition.  One of those partitions was called the "boot" partition, 
and, as near as I can determine, the default MBR executive loaded a 
small boot executive in the ESIX boot partition, which in turn loaded 
the kernel image, or, if necessary, the fall-back kernel image.

I also think that a change along these lines would also allow Boot 
Manager to grok the 386BSD partition as well.

-- 

Kaleb Keithley                          kaleb@thyme.jpl.nasa.gov

Not authorized, in any way, shape, or form, to speak for anyone.
Xref: sparky comp.unix.bsd:2726 comp.os.linux:6576 comp.periphs.scsi:3707
From: drew@ophelia.cs.colorado.edu (Drew Eckhardt)
Newsgroups: comp.unix.bsd,comp.os.linux,comp.periphs.scsi
Subject: Re: Query: Drivers for AHA >1522< ?
Date: 23 Jul 92 23:21:38 GMT
Organization: University of Colorado at Boulder

In article <14hjqoINNr78@agate.berkeley.edu> wjolitz@soda.berkeley.edu (William F. Jolitz) writes:
>In article <adam.711725819@mcrware> adam@microware.com (Adam Goldberg) writes:
>>...The 1542 is a bus-mastering controller.  This 1522 is not.  That makes
>>the 1542 much faster (at least in a protected-mode OS like Linux, with
>>properly written drivers).  
>
>One of the reasons that 386BSD works so well with the 1542B is the
>bus-mastering, the advantages of which are lost on DOS. There may
>be a false economy in getting a 1522, because the entire advantage
>of going to SCSI is the bandwidth improvement over the programmed I/O
>AT/IDE controllers. 

If you're talking about sustained transfer rate, it's going to be 
faster to do polled I/O because you don't have the couple of clock
cycles associated with each bus on period - you just crank data 
across the AT bus topspeed, 16 bits at a time.

However, if you can DMA to memory, and replace multiple interrupts with 
a single interrupt, you'll come out ahead in terms of speed because 
you're looking at ~200 clocks overhead for an interrupt on the i386
in protected mode.

SCSI-I also allows you to have one outstanding command per LUN 
(you can have one disk seeking, or transfering to local buffer 
while yoou're transfering data to another disk), which IDE and 
"traditional" disk controllers do not.

This gets you a lot in a multi-disk system.  The current Linux SCSI 
drivers do not support this, the next ones do.
Newsgroups: comp.unix.bsd
From: fstx@meryl.csd.uu.se (Fredrik Stax{ng)
Subject: Re: AT&T sues BSDI
Organization: University of Uppsala
Date: Wed, 22 Jul 1992 09:23:14 GMT

If AT&T wins, wouldn't that mean that in computers, you can't switch company
without switching careers? This claim could be applied to any company that
employs programmers that has worked for any other company before.


Fredrik Stax{ng              
CS Student@Uppsala University
fstx@emil.csd.uu.se          
(+46 18) 46 32 07            
--
Fredrik Stax{ng                | Part of the problem is that some of us have
CS Student@Uppsala University  | an incurable tendency to take ourselves
fstx@emil.csd.uu.se            | seriously.
(+46 18) 46 32 07              |                             - Thomas Nagel
From: lyndon@ampr.ab.ca (Lyndon Nerenberg)
Newsgroups: comp.unix.bsd
Subject: Re: AT&T vs. BSDI --> 4.3BSD-NET2 distribution requires AT&T license!!!
Summary: We don't give a shit; we're The Phone Company
Date: 23 Jul 92 07:30:52 GMT
Organization: Alberta Packet Radio Network

michael@resonex.com (Michael Bryan) writes:

> How long has the NET2 distribution (and other AT&T-void sources) been
> available?  If this is indeed the first legal action that AT&T/USL has
> taken, perhaps a point in BSDI's favor is that AT&T has waited until
> now to protest.  The NET2 distribution was no secret, nor were the
> various projects which are based upon it (especially Jolitz's 386BSD
> and BSDI's BSD/386).

ftp.uu.net logs every transfer. Perhaps they could be persuaded to
post a list of all the downloads of NET1 and NET2 that landed inside the
.att.com domain over the last couple of years.

I suspect (and hope) that they are saving that information for the
court case.

--lyndon
Newsgroups: comp.unix.bsd
From: comrade@uniwa.uwa.edu.au (Peter Cooper)
Subject: Re: 386BSD: /etc/rc's exit kills slattach(8)
Keywords: slattach SLIP etc/rc
Organization: University of Western Australia
Date: Fri, 24 Jul 1992 05:24:15 GMT

wkt@rodos1.cs.adfa.oz.au (Warren Toomey) writes:

>Quick bug report, and workaround. /etc/rc's exit 0 (i.e what happens after
>this) causes an slattach(8) in /etc/netstart to die. It's not getty and it
>is after the exit 0, because I renamed getty -> betty and put a sleep 10
>on the line above rc's exit 0.

>I tried at least two slattach lines in /etc/netstart:

>	slattach /dev/com2 9600
>	slattach /dev/com2 9600 < /dev/null > /dev/null

>Didn't try

>	nohup slattach /dev/com2 9600

The nohup one definitely works.

>  Warren Toomey VK1XWT, on the path to insanity
>  No longer in the bowels of ADFA Comp Science.
>   `Version 7 Job Control: just use ptrace(2).'
-- 
email:  comrade@uniwa.uwa.edu.au   snail:  Peter Cooper, box 22
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
From: grog@adagio.UUCP (Greg Lehey)
Newsgroups: comp.unix.bsd
Subject: Re: AT&T vs. BSDI --> 4.3BSD-NET2 distribution requires AT&T license!!!
Keywords: AT&T 'Death Star' rises over BSDI's horizon [Tel. 1-800-800-4BSD
Date: 23 Jul 92 17:10:45 GMT
Organization: LEMIS, Schellnhausen 2, W-6324 Feldatal, Germany

In article <1992Jul22.212903.29537@gateway.novell.com> terry@npd.Novell.COM (Terry Lambert) writes:
>*** prediction alert *** prediction alert *** prediction alert ***
>
>I think that AT&T will win; not on the merits of reality, but on the merits
>of their arguments.  It will be difficult, without educating the judge to
>the point of a CS degree, to draw the distinctions necessary to prove
>non-infringement by BSDI.  It certainly *looks* like BSDI is infringing
>to a layman, and that's what the judge will be.

Well, I sincerely hope you're wrong; but I also believe you will be.
Certainly AT&Ts win/lose situation won't be based on `the merits of
reality', but on the other hand they have so far not been able to give
a single example of where the alleged infringement is. I don't believe
they want to win; they're playing this court case relatively low-key,
and I suspect their motives are more to keep BSDI from doing real work
(like a production release of BSD/386) and to keep potential customers
away. That way, they don't need to win.

-- 
Greg Lehey                       | Tel: +49-6637-1488              
LEMIS                            | Fax: +49-6637-1489
Schellnhausen 2, W-6324 Feldatal, Germany
*** NOTE ***: Headers are mangled - reply to grog%lemis@Germany.EU.net
From: cflatter@nrao.edu (Chris Flatters)
Newsgroups: comp.unix.bsd
Subject: GNU emacs configuration for 386BSD
Date: 26 Jul 92 21:49:08 GMT
Reply-To: cflatter@nrao.edu
Organization: NRAO

I have a working configuration file for GNU emacs 18.58.  At the moment it
requires the kernel to be compiled with the COMPAT_43 option to get hold
of the load average.  I don't know if I'm duplicating someone elses work so
I'm checking whether anybody wants it before I post it.

	Chris Flatters
	cflatter@nrao.edu
From: james@raid.dell.com (James Van Artsdalen)
Newsgroups: comp.unix.bsd
Subject: Re: 386BSD 0.1: pccons.c bug
Date: 26 Jul 92 21:20:59 GMT
Reply-To: james@raid.cactus.org (James Van Artsdalen)
Organization: Dell Computer Co

In <1992Jul26.061759.13547@raid.dell.com>, james@raid.dell.com (me) wrote:

Sigh.  Obviously I hadn't tested this.  The second while loop needs to
wait for the output buffer bit to go high, not wait for it to go low.

Is there a PS/2 mouse driver (lots of Compaqs and Dells have
PS/2-style mice)?  If so, much of the code in pccons.c will have to
change to avoid race conditions.  The keyboard LED update code needs
to know that the next byte coming from the 8042 might be a keyboard or
mouse data byte, and not an ACK for the LED command.

	I haven't tested this change.  I found the bug by inspection.
	
	*** pccons.c.~1~	Sun Jul 26 01:12:26 1992
	--- pccons.c	Sun Jul 26 01:13:36 1992
	***************
	*** 155,161 ****
	  	
	  	while (inb(KBSTATP)&KBS_IBF);
	  	if (val) outb(KBOUTP, val);
	! 	while (inb(KBSTATP)&KBS_IBF);
	  	return (inb(KBDATAP));
	  }
	  
	--- 155,161 ----
	  	
	  	while (inb(KBSTATP)&KBS_IBF);
	  	if (val) outb(KBOUTP, val);
	! 	while (inb(KBSTATP)&KBS_DIB);
	  	return (inb(KBDATAP));
	  }
-- 
-- 
James R. Van Artsdalen          james@bigtex.cactus.org   "Live Free or Die"
Dell Computer Co    9505 Arboretum Blvd Austin TX 78759         512-338-8789
Newsgroups: comp.unix.bsd
From: tal@Warren.MENTORG.COM (Tom Limoncelli)
Subject: Re: AT&T vs. BSDI --> 4.3BSD-NET2 distribution requires AT&T license!!!
Organization: Mentor Graphics, Silicon Design Division
Date: Fri, 24 Jul 1992 17:06:40 GMT

In <1992Jul23.225144.10832@rice.edu> mmorg@ruf.rice.edu (Matt Morgan) writes:

>AT&T, you have lost another customer, not just for long-distance phone
>service, but for Plan 9 as well.

USL has never sold long distance.  You're going after the wrong men in
black hats.  (Or, in the case of Plan 9, black space suits)

Tom
-- 
Tom Limoncelli -- tal@warren.mentorg.com (work) -- tal@plts.uucp (play)
      Maybe Bush will follow Perot's lead.
Newsgroups: comp.unix.bsd
From: sef@kithrup.COM (Sean Eric Fagan)
Subject: Re: AT&T vs. BSDI --> 4.3BSD-NET2 distribution requires AT&T license!!!
Organization: Kithrup Enterprises, Ltd.
Date: Mon, 27 Jul 1992 19:37:57 GMT

In article <1992Jul27.164228.28312@gateway.novell.com> terry@npd.Novell.COM (Terry Lambert) writes:
>1)	SysVr3.x has got to be SVR3.2 or later.  It didn't include streams
>	prior to that.

Some platforms had STREAMS as early as SysVr3.0.

>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.

>3)	OSF/2 is the beast of interest, and it is based on Mach 3.0.

OSF/2 does not exist, nor is there any guarantee from OSF that they will
ever ship a Mach3.0-based system.

-- 
Sean Eric Fagan  | "My psychiatrist says I have a messiah
sef@kithrup.COM  |  complex.  But I forgive him."
-----------------+              -- Jim Carrey
Any opinions expressed are my own, and generally unpopular with others.
Newsgroups: comp.unix.bsd
From: dmuntz@dip.eecs.umich.edu (Daniel A Muntz)
Subject: Re: AT&T sues BSDI
Keywords: BSDI AT&T
Organization: University of Michigan EECS Dept., Ann Arbor
Date: Sat, 25 Jul 1992 21:26:16 GMT

In article <1992Jul25.014246.11533@klic.rain.com> keithl@klic.rain.com (Keith Lofstrom) writes:
>dennis@nebulus.ca (Dennis S. Breckenridge)  [ and others ] write:
>
>>Send your $1000.00 to BSDI and get a source license now.
>
>I just did so.  There are a number of reasons why this is a good idea:
>

good idea?

1) Now you're tainted by having seen BSDI code.  Obviously there's one shining
   example of someone who's seen BSDI code and "contributed" to 386bsd, but
   what will BSDI's reaction be to BSDI owners who contribute code to 
   386bsd in the future?  Perhaps an official response would be useful for
   people considering purchasing BSDI code.  To avoid a vague response
   I'll suggest some scenerios below.

2) Anyone who recommends a BSDI purchase to their employer at this point is
   an idiot *unless* said employer is into pirating software or is more
   interested in making a donation to BSDI than receiving a product they can
   use (i.e. BSDI loses and your software becomes illegal).
  

I'd like to know what BSDI's reaction to the following cases would be.
They are purely fictional as I have seen no BSDI code.

 a) I notice that /usr/sys/kern/foo.c is nearly identical in BSDI and 386bsd
    except the BSDI version has some bug fixes (ptr+1 instead of ptr, etc.).
    I post a diff of the two foo.c's.  Am I in trouble?

 b) I notice BSDI uses buffering in wt.c to improve tape performance.  I write
    buffering code for wt.c in 386bsd (which I argue would have occurred to
    me independently...).  There are some coincidental similarities in the
    buffering code.

 c) Some code I post is similar to some BSDI code that I've never seen.
    Perhaps the BSDIers and I read the same article on hyperwidget-trees at
    some point in the past.

 d) (Remember, this is fiction) Bill Jolitz decides to market 386bsd
    as a commercial product by distributing source and binaries
    free, but selling support.  The company is successful.

Keep in mind that even if BSDI's reactions to these situations would be
positive (from my perspective; as I suspect they would be at the moment),
who knows what would happen if BSDI became more successful and the
human to lawyer ratio began to drop.

  -Dan
From: jimj@miller.cs.uwm.edu (James Jegers)
Newsgroups: comp.unix.bsd
Subject: Kernel namelist not found, man fixes
Summary: getting arp, w, uptime to work
Keywords: namelist, man
Date: 21 Jul 92 20:43:16 GMT
Article-I.D.: uwm.1992Jul21.204316.4729
Organization: University of Wisconsin, Milwaukee


   First, Thanks for writting 386bsd it's a great assest to us.

1.  I'm having some problems with arp, w, and uptime.
    When I run them they say bad namelist, or can't get namelist.

    Looking at the sources it appears that w, uptime, and arp
    are looking for labels that I don't have in my kernel.
    Is this the way it's supposed to be? Or why were they programs
    put in with the system(just to make it complet?)

2.  How do I get the shell to reqonize the stop(control-C) and
    suspend(control-Z) character?  For example if I type make and
    decide I want to stop it, i have to login someplace else
    and kill the process.  Or hasn't this been added yet?
    
3.  I fixed a couple of man problems.

     The manual page for magic and file all have two dots
     before the commands,  eg.    "..SH" it should be ".SH"
     just delete one of the double dots in the whole file and then 
     it will work.

     The Makefile in /usr/othersrc/share/man/Makefile creates the whatis.db.  
     The problem is that it doesn't strip the backspaces in the
     title and apropos can't handle that.  So add a "col -b" to strip
     those.

exerpt from the makefile.

makedb:
	for file in `find /usr/share/man -type f -name '*.0' -print`; do \
		sed -n -f /usr/share/man/makewhatis.sed $$file; \
	done | col -b | sort -u > whatis.db
	install -o ${BINOWN} -g ${BINGRP} -m 444 whatis.db \
	    ${DESTDIR}/usr/share/man

-- 
     ______________________________________________________________
    /\               University of Wisconsin -- Milwaukee          \
    \_| Computing Services Division     Computer Science Department |
      |   jimj@csd4.csd.uwm.edu	          jimj@miller.cs.uwm.edu    |
Newsgroups: comp.unix.bsd
From: robert@psych.psy.uq.oz.au (Robert Dal Santo)
Subject: GCC 2.2.2 patches to cross compile 386BSD code
Keywords: I need them
Organization: Psychology Department, University of Queensland
Date: Tue, 21 Jul 1992 04:57:13 GMT

	Could some kind person E-mail me the necessary patches to 
gcc 2.2.2 so I can cross compile 386BSD code on my Sparcstation II.
Also any comments about experiences doing 386BSD cross compiling
would be appreciated, especially about the assembly and linking
phases.

	And while I'm here, Many thanks to Bill and Lynne Jolitz for
a great system. I've put my 386SX thru hell the last few days and
386BSD has bounced back every time!

===========================================================================
Robert Dal Santo               Phone +61 7 365 6687
                               Fax   +61 7 365 4466
Department of Psychology,      
University of Queensland 4072,
AUSTRALIA. 		       

"I've reached the driveway to destruction and I'm taking the stationwagon."
===========================================================================
Newsgroups: comp.unix.bsd
From: kcwellsc@watdragon.uwaterloo.ca (Ken Wellsch)
Subject: Re: 386BSD: Anyone using gcc-2.x on 0.1?
Organization: University of Waterloo
Date: Wed, 29 Jul 1992 20:59:51 GMT

> I'm highly interested in moving to the latest version of gcc-2.x,
> (currently 2.2.2) because:
> b) Its ability to emit PIC (Position Independent Code) seems to be
>   a pre-requisite for shared libraries.

Don't forget to upgrade "gas" (the assembler) to handle PIC (still a "gas"
ToDo item I think).

> Has anyone else "bootstrapped" up to 2.2.2 yet?  Has anyone who
> has, rebuilt the kernel with it yet?  Does anyone have any reasons
> why this might not be a good idea?

I tried it a few days ago.  I used "i386-bsd" as the configure type. I
found I had to add "-D_ANSI_H" to fix a gvarargs.h problem but I don't
know that this is the right way to handle it.  It got through to the
libgcc1.a stuff (even though I think you need a "stock" compiler for these
functions - not sure how to fix this part) but things bombed for me when
it tried to use the newly built gcc to compile libgcc2.a. I hope you have
better luck and post what is needed to successfully build a copy.
Newsgroups: comp.unix.bsd