HDTenEightyP/NetNews huggingface dataset:
From: bostic@toe.CS.Berkeley.EDU (Keith Bostic)
Newsgroups: comp.unix.bsd
Subject: Re: Catch What They're Saying About Us...
Date: 1 Oct 1992 00:08:15 GMT
Organization: University of California at Berkeley
NNTP-Posting-Host: toe.cs.berkeley.edu

There are statements concerning the CSRG in the recent posting by Lynne
Jolitz that are not true.  Specific comments follow.

	> The [386BSD] system was ready for users in 1989,
	> but it's release was consistently put-off by CSRG.

The contribution letter from Jolitz to the CSRG for the 386 architecture
support is dated December 31, 1990.  Regardless of its "readiness for
users", the CSRG had no permission to redistribute it until that time.
The CSRG at no time made any agreement to distribute the 386 support at
any specific time, other than "as part of the next release", which was
done in June of 1991.  A copy of this contribution letter is available
from me by providing me a stamped, self-addressed envelope.

	> They [BSDI] have received many changes from CSRG
	> (one and the same with BSDi), but are not distributing them.

As we have publicly said before, the CSRG does not make software available
to any vendor that is not available to all other vendors and/or
individuals.  Period.  Accusations of this sort should be substantiated
with the names of specific files and programs to permit the truth to be
independently determined by the comparison of releases.

	> They [BSDI] have even received Chris Torek's sparc code, paid for
	> by the taxpayers, which has not been made available to others
	> despite repeated requests, and are currently attempting to make
	> money off of it in the same manner in which they tried to
	> appropriate 386BSD.

We note this statement only because it was part of the above paragraph,
possibly implying that this was an issue for the CSRG.  Chris Torek's
Sparc port belongs to the Lawrence Berkeley Laboratory (his employer) and
we have no idea if BSDI has the Sparc code or not.  A copy has been
contributed by Lawrence Berkeley Laboratories to the CSRG for distribution
with 4BSD.  As is our practice with the code contributed to us, it is
available from the CSRG on our most recent release, 4.4BSD-Alpha.  It is,
unfortunately, a licensed release, but there's nothing we can do about
that.

	> If we hadn't spent the time making sure 386BSD was completed and
	> distributed, it still would not be available either.

Once again.  Every line of code contributed to Berkeley by Jolitz was made
available as part of the next release by the CSRG, in this case, the NET/2
release made last year.

Keith Bostic
Kirk McKusick

Xref: sparky comp.unix.bsd:6693 comp.sys.ibm.pc.rt:517 comp.unix.large:331
From: wutcd@chemnitz.guug.de (Joerg Wunsch)
Newsgroups: comp.unix.bsd,comp.sys.ibm.pc.rt,comp.unix.large
Subject: Re: strdup
Date: 1 Oct 92 22:16:52 GMT
Organization: tu-chemnitz

br.pct@RLG.Stanford.EDU (Peter C. Tam) writes:


>	In BSD 4.3 C lib, there is no strdup that is provided in System 5,
>& I just happened to get a program that was supposed to be able to compile
>in BSD also. Can anyone tell me where I can get the strdup routine for
>BSD 4.3, especially, in ibm.pc.rt AOS.

This is an easy exercise. You'll find an example in K&R, here is my
version. (Of course, the function should be included into the libc.a.)

#include <strings.h>	/* strlen(), include a prototype for strdup here */
#include <stdlib.h>	/* malloc() */

char *
strdup(const char *src)
{
	char *rv;
	register char *dst;

	if(rv = dst = (char *)malloc(strlen(src) + 1))
		while(*dst++ = *src++) /* hmmm... */ ;
	return rv;
}

	J"org

--
J"org Wunsch, TCD GmbH Dresden, R"ahnitzgasse 18, D-O-8060 Dresden
                                                              \     ~.~. 
	joerg_wunsch%bonnie@hadrian.hrz.tu-chemnitz.de         \   ~  | ~ 
	voice: +49-351-5965 137                                 \    ===
From: peter@ferranti.com (peter da silva)
Newsgroups: comp.unix.bsd
Subject: Re: Newbies (Was Re: new new scsi release beta2 part 1 of 5)
Date: 3 Oct 92 17:50:16 GMT
Organization: Xenix Support, FICC

In article <9227609.9212@mulga.cs.mu.OZ.AU> ggr@koonda.acci.com.au (Greg Rose) writes:
> I've been mucking around with kernel configurations for way too long
> already, and agree with Terry that there are many possible improvements.
> However, like both Ross and Terry, I assert I know how to do it.

I've been doing it since Version 7, and I was recently stunned by the discovery
that modern BSD-based systems still use basically the same method. For the past
6-8 years I've been gafiating in System V land, and one of the few really nice
things about System V (and lord knows there are few) is the configuration
method. Short of dynamically loading the kernel on startup (which is of course
the ideal method) I've not seen better, for any OS.
-- 
Peter da Silva                                          `-_-'
Ferranti Intl. Ctls. Corp.                               'U` 
Sugar Land, TX  77487-5012
+1 713 274 5180                           Heb jij vandaag je wolf al geaaid ?
From: linkt@GroupW.cns.vt.edu (Tim Link)
Newsgroups: comp.unix.bsd
Subject: getting net config with SIOCGIFCONF ioctl call
Keywords: ioctl ifconf ifreq
Date: 29 Sep 92 05:19:30 GMT
Followup-To: linkt@Groupw.CNS.VT.EDU
Organization: Va Tech Communications Resources

I'm working on a program that needs to determine the network
configuration under 386BSD.  I'm using the SIOCGIFCONF IOCTL function
which *I THINK* should return to me an array of ifreq structures which
have the name of the interface and it's ip address.  This ain't what I'm
gettin'.  I've poked and prodded and looked at if.c to try to figure out
what's going on, but I can't see where the problem is.  Just as a test I
compiled the program on an Ultrix machine and the results were close to
what I expected, but still not exact.  Can anybody look at this and tell
me if I'm completely wrong in what I'm doing of if SIOCGIFCONF isn't
returning what it should be???

As always, any and all help appreciated.  
  Tim


Here's the output with 386BSD:
(The addresses are completely wrong, and why are the "if" names
spaced?)

if:we0 	 addr:0.3.0.0
if: 	 addr:4.5.0.0
if: 	 addr:12.3.45.35
if: 	 addr:7.0.0.1
if: 	 addr:0.0.3.0
if: 	 addr:0.0.0.0
if:sl0 	 addr:24.0.0.2
if: 	 addr:0.0.0.0
if: 	 addr:0.0.0.0
if: 	 addr:0.0.0.0


Here's the output on the Ultrix system:

if:ln0 	 addr:0.0.0.0    <---+-- What are these??? 
if:ln0 	 addr:4.5.0.2    <---+
if:ln0 	 addr:128.173.5.9<-----+- These are correct.
if:lo0 	 addr:127.0.0.1  <-----+  
if: 	 addr:0.0.0.0
if: 	 addr:0.0.0.0
if: 	 addr:0.0.0.0
if: 	 addr:0.0.0.0
if: 	 addr:0.0.0.0
if: 	 addr:0.0.0.0


And here's the program:

#include <sys/types.h>
#include <sys/socket.h>
#include <sys/ioctl.h>
#include <net/if.h>
#include <netinet/in.h>
#include <stdio.h>

struct ifreq ifreq[10];		/* Holds interface configuration */
struct ifconf ifconf;		/* Int. config ioctl block (pnts to ifreq) */

int s;
int i, y;
struct in_addr ipa;
struct ifreq iftest;
struct in_addr test2;

main()
{
    printf("\n");

    /*
     * Get  a socket.
     */

     if ((s = socket(AF_INET, SOCK_DGRAM, 0)) < 0) {
        printf( "socket error\n" );
        exit(1);
     }

    /*
     * Get network configuration.
     */

    ifconf.ifc_len = sizeof(ifreq);
    ifconf.ifc_req = ifreq;
    if ((ioctl(s, SIOCGIFCONF, (caddr_t) &ifconf) < 0) ||
	(ifconf.ifc_len <= 0)) {
	    printf("ioctl error\n");
	    exit(1);
    }

    printf( "\n" );
    for ( i = 0; i < 10; i++ ) {
        printf( "if:%s \t addr:%s\n", &ifreq[i].ifr_name, 
          inet_ntoa( ((struct sockaddr_in *)(&ifreq[i].ifr_addr))->sin_addr ) );
    }
}
Newsgroups: comp.unix.bsd
From: richard@pegasus.com (Richard Foulk)
Subject: Re: Catch What They're Saying About Us...
Organization: Pegasus,  Honolulu
Date: Sat, 26 Sep 92 05:08:40 GMT

>
>I don't think your RAM is the limiting factor, but the HD space available -
>there's eleven 5.25'' floppies of *compressed* stuff and I doubt very much
>this'll fit on 14 megs.
>

Someone could probably write a script to just read in the bare
essentials to reduce the space requirements a bit.

(Of course shared libraries would help some in the future -- the AT&T
3B1 was shipped in a 20 meg version that actually worked.)

-- 
Richard Foulk		richard@pegasus.com
Newsgroups: comp.unix.bsd
From: terry@cs.weber.edu (A Wizard of Earth C)
Subject: Re: [386BSD] fixing ps: major/minor numbers for /dev/console wrong?
Reply-To: terry@icarus.weber.edu
Organization: Weber State University  (Ogden, UT)
Date: Mon, 28 Sep 92 15:56:09 GMT

In article <1992Sep27.222353.2163@drycas.club.cc.cmu.edu> ghod@drycas.club.cc.cmu.edu writes:
>In article <wutcd.717632941@hadrian>, wutcd@chemnitz.guug.de (Joerg Wunsch) 
>writes:
>> ghod@drycas.club.cc.cmu.edu writes:
>>> [1) some names not found...]
>>>Problem #1 is not, ps's fault: it's the kernel. The stock kernel in the 0.1
>>>...
>> Okay, it's quiet clear: the dist kernel had to fit onto a diskette:-)
>> 
>
>Actually, this was a true honest to goodness bug, not an attempt to whittle
>the kernel down to fit onto the distrubution diskette. The kernel on dist.fs
>is slightly larger than 400 Kbytes. The one I ftp'ed from
>rachel.ibmpcug.co.uk was about 380 Kbytes, and included more drivers than the
>stock kernel. Go figure. :)

This is the difference between the kernel being stripped or unstripped, and
stripping *is* the result of an attempt to fit it on the dist.fs.

>Also, upon further investigation, ps's inability to print command line args
>doesn't appear to be due to a bug in its code. The call used to get the 
>arguments from the kernel is kvm_getargs(), which I'm assuming is related
>to the kvm_getcmd() call in SunOS. kvm_getargs() seems to return only the
>command name, not the command line args, so I guess the solution will indeed
>lie in some kernel hacking. Unfortunately, I don't have the space to build
>a new kernel (and with only a 16Mhz 386SX it would probably take days :)
>so I guess I'll just have to wait for the next release or patch.

I you haven't rebuilt the kernel, you won't have the symbol information in
to to look up the arguments from.  You *must* rebuild the kernel after
installing to make "ps" and other utilities happy ("route get", "arp -a",
"netstat", etc.).

That being said, there is code missing that returns the command line
arguments for commands.  This has been disabled, apparently to avoid a
crash when you read from /dev/drum, rather than as a real fix to the
problem (which is fixing the uninitialized pointer to allow reading from
/dev/drum without a crash.  There was a patch posted here (comp.unix.bsd)
for the problem, but it was marked as a first attempt and subject to
rewrite.  Look it up and install it if you dare...


					Terry Lambert
					terry_lambert@npd.novell.com
					terry@icarus.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.
-- 
-------------------------------------------------------------------------------
                                        "I have an 8 user poetic license" - me
 Get the 386bsd FAQ from agate.berkeley.edu:/pub/386BSD/386bsd-0.1/unofficial
-------------------------------------------------------------------------------
From: andrick@sun.rhrk.uni-kl.de (Ulf Andrick [Biologie])
Newsgroups: comp.unix.bsd
Subject: Re: device 0/0 0/1
Date: 6 Oct 92 02:36:19 GMT
Organization: University of Kaiserslautern, Germany
X-Newsreader: Tin 1.1 PL4

nbladt@autelca.ascom.ch (Norbert Bladt) writes:
: kuku@acds.physik.rwth-aachen.de (Christoph Kukulies) writes:
: 
: 
: >I'm running 386bsd on a ah1542b with as0a as root, as0b swap, as0h /usr.
: >Yesterday I installed Julian Elischers (thank you, Julian), scsibeta2.1
: >release because my DAT tape (DEC TLZ04) was never recognized by the as
: >driver. With the above SCSI driver it is recognized.
: 
: >But I have a strange behaviour when booting. I always get 
: >no swap space present (yet)   and  later: 
: >savecore: device not configured as0b.
: 
: >I could not figure out where this string occurs in the kernel code. I did a 
: It does not occur in the kernel. This message is from one of the programs
: which are started during boot, e.g., in /etc/rc.
: This program's name is (didn't you guess it from the error message):
: 	savecore
: I had exactly this problem and solved it by looking at three things:
: 	1. If you had a line containing
: 		... root on as0 swap on as0
: 	   in your config file (e.g. SCSITEST), you should change that
: 	   to
: 		... root on sd0 swap on sd0
: 	2. Look at the "swap386bsd.c" file in your configuration directory
: 	   This should include something like "sd0".
: 	
: 	3. Do a "disklabel -r sd0".
: 	   If it doesn't show something like
: 		b: ....   swap ...
: 	   then this could be another cause of your problem. You have to fix it.
: 	   I won't recommend writing a new disklabel here, because after my
: 	   bad experience with disklabel I am very careful using it.
: 	   Do not misunderstand this statement. The actions "disklabel"
: 	   did to my harddisk were all caused by me !
: 
: 
I have no experience with that, but I wonder whether one
shouldn't have a look at /etc/fstab in such a case. That file
should be decisive for what devices are used as swap space,
shouldn't it?

--
Ulf R. Andrick                                andrick@rhrk.uni-kl.de
FB Biologie - Tierphysiologie
Universitaet                             Was du nicht selber weiszt, 
D-W 6750 Kaiserslautern       das muszt du dir erklaeren (Tegtmeier)
Newsgroups: comp.unix.bsd
From: julian@tfs.com (Julian Elischer)
Subject: Re: AHA1542B vs Sysgen SC4000 controller under BSD386
Organization: TRW Financial Systems
Date: Mon, 5 Oct 1992 10:02:19 GMT

In article <1ao4umINNaua@network.ucsd.edu> brian@ucsd.edu (Brian Kantor) writes:
>I managed to score a Sysgen SC4000 SCSI-to-QIC-02 controller, an Adaptec
>Stand-Alone-Tape-Controller QIC-02-to-QIC-36 board, and an Archive 5945C 
>drive.  This bizarre combination is what Sun used to use in their really
>old (Sun-2/68010 days) tape backup boxes.
>
>When I connect this mess up to my Adaptec controller and try to bood
>386BSD with Julian's SCSI package, the error light on the SC4000 comes
>on, and the computer just keeps telling me that command timed out.
>The light on the Adaptec just stays on.
>

I wonder if the SC4000 is really compatible with modern scsi.
Does the BIOS find the tape controller? (do you have the BIOS enabled?)
just for laughs, try the old scsi system and let me know
what happens.

I'm sorry that that is not much help.
But it sounds as if the low level protocols are failing.
Something is wedging the scsi bus.
That's not something the software can easily do.

(If it makes you feal better I'm having the same problem
with a particular disk and the aha1742 card (aha1542 loves it).


>Has anyone gotten this or a similar setup to work?  What firware
>revisions are in your controllers, and what jumper/switch settings did
>you use?
>	- Brian

julian

+----------------------------------+       ______ _  __
|   __--_|\  Julian Elischer       |       \     U \/ / On assignment
|  /       \ julian@tfs.com        +------>x   USA    \ in a very strange
| (   OZ    ) 2118 Milvia st. Berkeley CA. \___   ___ | country !
+- X_.---._/  USA+(510) 704-3137(wk)           \_/   \\            
          v


Newsgroups: comp.unix.bsd
From: olof@ikaros.fysik4.kth.se (Olof Franksson)
Subject: How long AT-buss DMA transfers can be done to "user memory"?
Organization: Physics IV, Royal Institute of Technology, S-100 44 Stockholm,
	Sweden
Distribution: comp
Date: Mon, 28 Sep 1992 19:20:46 GMT

How large AT-buss DMA tranfers can be done between the "user memory" space
and the AT-buss? 

The DMA hardware limit is 64k, but on my system it seems to be 20k (21k or
more makes the system reboot). Is this as it should, a bug, or due to
erroneous use of the kernel routines?

The following device driver call was used in my tests:
	rawwrite(dev, uio);

The strategy routine calls isa_dmastart() and isa_dmadone():
		.
		.
	isa_dmastart(readflag, bp->b_un.b_addr, bp->b_bcount, channel);
		.
	/* Wait for end of transfer */
		.
	isa_dmadone(readflag, bp->b_un.b_addr, bp->b_bcount, channel);

Since AT-buss DMA is restricted to 64k of continous, non 64k block address 
breaking, one problem might be that the isa_dma*() routines dont check
for these things. Another restriction might be that the routines are
unable to lock more than a certain amount of address space in continous
physical memory.

I am not so familiar with kernel physical/virtual memory management
and would like to avoid these topics at length. My experience mostly 
concerns writing device drivers for SUN and XENIX, not BSD derivatives. 

	Sincerely

		Olof Franksson
		Physics IV, KTH, Sweden
		+46 8 790 7219 
Newsgroups: comp.unix.bsd
From: bmyers@rucs2.sunlab.cs.runet.edu (B.Myers)
Subject: Re: How to get parallel printer to work ?
Organization: Radford University
Date: Mon, 5 Oct 92 21:01:39 GMT


How do I make /dev/lp... If I say that the printer
is com1 or com2 it works.. what is the major and minor numbers
for mknod, I have the patched kernel supplied with X386.
lpr works, but I connot find where to make the lp device.

--
Brandon Myers
bmyers@rucs2.sunlab.cs.runet.edu
From: paoletti@cps.msu.edu (David R. Paoletti)
Newsgroups: comp.unix.bsd
Subject: Wangtek 5150ES's for $349
Date: 30 Sep 92 05:43:24 GMT
Organization: Dept. of Computer Science, Michigan State University
Originator: paoletti@pacific.cps.msu.edu

NOTE: I am NOT selling these tape drives.  I am simply a satisfied
      customer helping out fellow 386BSDers.  I have no affiliation
      (other than happy customer) with the person selling these,
      nor am I being recompensed in any way for my recommendation.

The following ad was posted to misc.forsale.computers, and I've
purchased one.  I am very satisfied with the drive (except maybe
the black faceplate ;), and the person selling them was very prompt,
courteous, and helpful when I had a slight problem (cause == me).
The best mail order price that I've seen was about $650.  This tape
drive will work fine with 386BSD with no modifications to the kernel
(as long as you have an Adaptec 1542B).  I can't make any comment
about the new 386BSD SCSI modules, as I haven't tried them.

David Paoletti :)
AI/KBS Lab Manager
--
Newsgroups: misc.forsale.computers
From: asg@unixland.natick.ma.us (asg@unixland.natick.ma.us)
Subject: Wangtek 5150ES 250Mb SCSI Tape Drive
Organization: Unixland Public Access Unix  (508) 655-3848
Date: Sat, 26 Sep 1992 15:13:22 GMT

-------------------------------------------------------------------------------
SPECIFICATIONS:

Formatted Capacity:        250Mb (500Mb w/ data compression)

Data Cartridge Type:       DC6250, DC6150

Recording Formats:         QIC-150 (DC6250/250Mb, DC6150/150Mb)
                           QIC-120 (DC600A/120Mb)

Read Compatibility:        QIC-150, QIC-120, QIC-24

Transfer Rate:
    Asynchronous           1.8Mb/sec
    Sustained              112.5Kb/sec (6.75Mb/min)

Quick File Access (QFA):   supported, reducing seek-to-data and append time
                           to under 2 minutes.

Condition:                 brand new, packaged for OEMs (read: bare drive),
                           a jumpers information sheet is enclosed

Warranty:                  1-year manufacturer's warranty/30-day replacement

Price:                     $349.00

Terms:                     prepaid/C.O.D.(cash, M.O. or certified check)

Shipping:
    Continental USA
        UPS Ground         $4
        UPS Blue           $8
    Canada
        UPS Ground         $9

-----------------------------------------------------------------------------
Alex    asg@unixland.natick.ma.us    508-263-6504 (8-11pm, EST)
-----------------------------------------------------------------------------
Newsgroups: comp.unix.bsd
From: u009@csx.cciw.ca (G. Stewart Beal)
Subject: [386bsd]Wanted:PC Diagnostic reporting bad BLOCKS (not track/head)
Organization: Canada Centre for Inland Waters
Date: Thu, 1 Oct 1992 17:31:09 GMT
Summary: actual bad sector numbers wanted

I am looking for some kind of diagnostic for a MFM hard disk which will
report the actual block number (or cylinder+head + SECTOR) of bad blocks
on it. I want to spare out the bad blocks under 386BSD but the only
diagnostics I can find (Speedstore, Disk Manager, Mace HTest) all report
only the track containing the error. While I was playing with the drive on
a Mac, I got a listing of some of the blocks after it was formatted with
1:1 interleave but on the PC, I can only use 2:1 so the block numbers I
currently have are probably meaningless. I have the Cyl/Head/BFI values
of some of the flaws from the manufacturer, but I can't calculate the sector
'cause I don't know the actual byte by byte organization of a track, besides
the interleaving would complicate things too much for my little brain!
So if you've got a pet diagnostic that reports Blocks or sectors, I'd
love to hear from you.
 
Regards, Stu Beal, VE3MWM, U009@CS.CCIW.CA,
National Water Research Institute, Burlington, Ontario, Canada.
 
"A breathless story that zips along at warp speed... because the characters
are undeveloped and the author has not the least sense of narrative pace."

Newsgroups: comp.unix.bsd
From: rich@Rice.edu (Richard Murphey)
Subject: Re: Problem with xconsole
Reply-To: Rich@rice.edu
Organization: Department of Electrical and Computer Engineering, Rice
	University
Date: Sun, 27 Sep 1992 22:19:27 GMT

In article <1992Sep27.174544.7822@news.cs.brandeis.edu> st923150@pip.cc.brandeis.edu (Benjamin A. Tober) writes:
	   I'm using 386BSD with X386 and it works nicely except that xconsole
   does not function properly.  Attempts to write to /dev/console cause
   keyboard input to be mangled, thus necessitating a reboot.  I do have
   getty disabled on /dev/console and the ownership of /dev/console is correct
   (i.e.- the same as the invoking user).  I'm using xdm and twm.  Has anyone
   seen this phenomenon?  Is there a fix?
   -ben
 A fix for xconsole will require more kernel support for redirecting
console output.  The first official 386BSD patch set may support this
since it's aimed at enhancing X support.  The kernel pathches supplied
with XFree86 don't include this.  Rich
Newsgroups: comp.unix.bsd