HDTenEightyP/NetNews huggingface dataset:
From: terry@cs.weber.edu (A Wizard of Earth C)
Subject: Re: [386BSD] Still trying to install...
Organization: Weber State University  (Ogden, UT)
Date: Sun, 24 Jan 93 22:26:18 GMT

In article <AOKI.93Jan23202330@risk.Stanford.EDU> aoki@risk.stanford.edu (ikuro aoki) writes:
>
>  >>the cache overlays an area used for a disk I/O.
>                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^
>I would like to know where is the area. 

It depends on whether you are doing real DMA, or whether you are doing "DMA"
by virtue of a copy-buffer after an interrupt.  Basically, this boils down
to "Does the controller copy the buffer from the controller to main memory,
or does the main CPU do the copy?".

In the case of real DMA, this is any address in the lower 16M of memory.
It is possible (but not currently done) to restrict the region used for
the DMA by placing the copy buffers at a well known address.  This would
probably provide for "bounce buffers" to copy data above the 16M address
limit imposed by the ISA 10-bit DMA path at the same time if you were
smart.

>Is this location programable? 
>Could I specify the location of the area?

The cache location?  Yes, on some hardware, no on others.  It's dependant
on implementation, as is the ability to turn the cache off.

The DMA-to location?  Yes, it's specified in the buffer-address in the
request... and must live below 16M.  This isn't enforced by two-staging
the buffers (ala "bounce-buffers") in the current rev of Julian's SCSI
driver, which is why people with > 16M of real memory have problems (in
all fairness, these problems are shared with the default 0.1 SCSI driver,
which only works with a single controller; thus Julian's drivers are a
vast improvement no matter how you look at them).

I don't see a significant advantage to a data cache in most situations in
the 386BSD kernel; my advice would be to simply turn it off.  The only
data it is interesting to cache is ROM or disk contents.  386BSD does not
use the first, and has it's own method of doing the second.


					Terry Lambert
					terry@icarus.weber.edu
					terry_lambert@novell.com
---
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
-------------------------------------------------------------------------------
Newsgroups: comp.unix.bsd
From: mwiz@cia.austin.ibm.com (Marc Wiz)
Subject: Re: Can password file be split up?
Date: Mon, 25 Jan 1993 23:34:31 GMT
Distribution: usa
Organization: IBM, Austin
Keywords: passwd

In article <44001@sdcc12.ucsd.edu> zz1bb@impending.ucsd.edu (Barry Brown) writes:
>On one of our systems here, there are over 3000 entries in the passwd file.
>Every time a user wants to make a change to it (chfn, passwd, chsh), the
>file must be locked so the user has exclusive write access to it in order to
>make the change.  With lots of people trying to do this all time, changing
>one's password can take an HOUR!  First the user has to wait for a file
>lock, then the file has to be changed.  The first part takes up most of the
>time.  The situation is aggravated in the morning when the accouting
>programs take their tallies and turn off access for users who have exceeded
>their time quotas.
>
>Is there a way to split the passwd file into smaller chunks so it can be
>more managable?  For example, all users with 0 < UID < 500 would be in one
>passwd files, all users with 501 < UID < 1000 would be in another, etc.
>This would reduce the lock and write times on the passwd file tremendously,
>I imagine.
>

You might want to consider a way of speeding up accesses by using dbm files
like some commercial versions of Unix use.  That way you would only have to
lock the one record.  

IMHO this is one the problems with the traditional method of Unix password
file management.  (Or other files as well)  it doesn't work well with large
number of entries.

Marc

mwiz@austin.ibm.com
(512)823-9330
I type only for myself.
Yes, that really is my last name.
Newsgroups: comp.unix.bsd
From: terry@cs.weber.edu (A Wizard of Earth C)
Subject: Re: [386bsd] Won't recognize SCSI drive
Organization: Weber State University  (Ogden, UT)
Date: Thu, 21 Jan 93 22:23:04 GMT

In article <1993Jan20.201015.12046@unlv.edu> ostgard@unlv.edu (Doug Ostgard) writes:
>A friend has been unable to successfully install 386bsd, and so 
>asked me to post the following:
>
>    - - -
>Hardware Setup:
>486DX-50 Local Bus
>4MB RAM
>GA-486US Motherboard
>GA-201 Local Bus Video Controller
>GA-400 Local Bus SCSI Controller
>Maxtor LXT340S SCSI Hard Drive
>
>The problem is that the 386BSD kernal will not recognize that the hard drive
>is present.  The hard drive is partitioned with the 386BSD partition first,
>and the DOS partition at the end.  200MB have been partitioned out for
>386BSD with the remainder used for DOS.  The GA-400 SCSI controller 
>user's manual says that the controller is hardware and software compatible
>with Adaptec's AHA-1522 controller.  Everything I have read about 386BSD
>has implied 1542 compatibility.  Does anyone know if the problem I am having
>is related to the controller being incompatible?  And is there anything I
>can do about it in order to get my hard drive to be recognized.
>
>If necessary, we will try to modify the existing SCSI driver to work
>for the AHA-1522.  Any help in that area would also be appreciated.

This is what you'd have to do.  The 1522 is the retarded older brother
of the 1542.  I don't know (but suspect the answer is "no") if there
is a driver for the 1522 using Julian's SCSI subsystem.  If not, you
will either have to hack away or get a different controller.


					Terry Lambert
					terry@icarus.weber.edu
					terry_lambert@novell.com
---
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: dmuntz@quip.eecs.umich.edu (Dan Muntz)
Newsgroups: comp.unix.bsd
Subject: [386BSD] processor caching effect on kernel build
Date: 27 Jan 93 20:55:37 GMT
Organization: University of Michigan EECS Dept., Ann Arbor, MI


People have been wondering about how the internal and external caches
affect performance under 386bsd.  Here are some numbers I got doing kernel
builds.

System:
486DX50 (8k internal cache) EISA
16mb 80ns (4 4Mx9 simms)
Adaptec 1542B (ISA) scsi
Micropolis 1528 scsi disk
256k 20ns external cache
64mb swap (whatever portion of 64mb 386bsd is capable of using)
gcc version 1.39

both caches disabled:
	make depend:	05:38.13
	make:		28:51.15

external cache enabled, internal disabled:
	make depend:	05:37.53
	make:		28:49.88

internal cache enabled, external disabled:
	make depend:	01:35.66
	make:		07:49.75

both caches enabled:
	make depend:	01:25.28
	make:		06:10.84

Kernel being built is 0.1 + patchkit0.2 + julian's scsi + pcfs + minor patches
Running kernel is the same (and contains NONOP patch recently posted).
You've just got to love 7:36 for building a kernel from scratch :)

  -Dan
   dmuntz@eecs.umich.edu
Newsgroups: comp.unix.bsd,comp.sys.ibm.pc.hardware
From: wollman@hal.emba.uvm.edu (Garrett Wollman)
Subject: Re: [386BSD] i82586 Ethernet driver - Where to get
Organization: University of Vermont, EMBA Computer Facility
Date: Sat, 23 Jan 1993 19:45:25 GMT

In article <1993Jan23.194050.635@uvm.edu> I write:
>I am pleased to announce the release of the latest version of my
>i82586-based Ethernet device driver.  This driver is currently known
>to work on AT&T EN100 and StarLAN 10 controllers, but the job of
>porting it to another card should be simple.

And then promptly forget to tell you where to get this wonder of the
modern age.

The driver is available by anonymous FTP from tsornin.emba.uvm.edu, in
the directory 386BSD, as ie-driver.tar.Z.  It is also available in
untarred format on ref.tfs.com, in
/usr/src/sys.extras/wollman-ie-driver.

-GAWollman

-- 
Garrett A. Wollman   | Shashish is simple, it's discreet, it's brief. ... 
wollman@emba.uvm.edu | Shashish is the bonding of hearts in spite of distance.
uvm-gen!wollman      | It is a bond more powerful than absence.  We like people
UVM disagrees.       | who like Shashish.  - Claude McKenzie + Florent Vollant
Newsgroups: comp.unix.bsd
From: wrightj@hamlet.uncg.edu (Simply Jason)
Newsgroups: comp.unix.bsd
Subject: Logitech
Keywords: mouse,X,logitech
Date: 27 Jan 93 16:43:33 GMT
Organization: J. Random Misconfigured Site
X-Posted-From: hamlet.uncg.edu
NNTP-Posting-Host: sol.ctr.columbia.edu

I'm posting this for a friend (email responses to: tuttlem@meg.uncg.edu)

He has a Logitech Cordless mouse, and is having trouble getting it to work
under 386bsd (Xfree86).  We tried the Logitech driver Xconfig:

Logitech	"/dev/com2"
   Speed	2400          (1200 & 9600)
   SampleRate	150

It acts very flaky!  Has anyone experienced this and/or have a solution
for this problem?

Jason L. Wright		
Newsgroups: comp.unix.bsd,comp.periphs.scsi
From: terry@cs.weber.edu (A Wizard of Earth C)
Subject: Re: What is this scsi controller?
Organization: Weber State University  (Ogden, UT)
Date: Sun, 24 Jan 93 00:07:50 GMT

In article <1009321.23560.12980@kcbbs.gen.nz> dgd@kcbbs.gen.nz (David Dix) writes:
>
>Can anyone help me with information on this scsi controller?
>
>It is an ISA bus 16bit short card from 3Com Corporation and has SCSI PLUS
>ASSY 6175-00 REV A markings. It has an external 50 way centronics type
>socket and an internal 50way idc type socket. There are are two large
>chips, a WD33C93-PL 40pin dil type, and a square plc type in socket
>with L1A1287, 1880-00, LINK+, TAG 8915, and 8471 HONG KONG markings.
>
>I would like to get some programming information if at all possible
>and find out if it is a bus mastering type scsi controller.
>Does anyone know if it is compatible with any other scsi controller?
>I would like to try and get it working with 386BSD unix.

The Am33C93A (it's probably an A if it's a recent board) is a product of
American Micro Devices.  This is the chip used in the WD7000-ASC and
the WD7000-FASST and WD7000-FASST2 controllers.  Documentation is
available in the communications parts book from AMD.

Whether your controller is bus-mastering depends on it's native
intelligence above and beyond this chip.  Specifically, the WD7000 series
has a Z80.  It is the programming in the ROMs on board the card which allow
you to indicate by convention which command of those available in it's ROMs
that the 7000 will execute.  The command protocol is defined by Western
Digital, who produced the ROMs.

In your case, you will have to contact 3Com for programming information;
this may be difficult to get out of them, given their reluctance to
support the 3C501 in the past... it depends on how old the board is.

Knowing that you have a Am33C93A chip won't do you much good unless there
is a pass-through mode or a direct access interface on the controller.
Don't bet on the first (the WD7000 happens to have one), and if the
second is true, don't expect bus-mastering from a raw chip interface;
expect to have to take an interrupt and do a copy from a shared store
instead (ie: you do the DMA).

Either way, you are probably out of the water without 3Com docs.


					Terry Lambert
					terry@icarus.weber.edu
					terry_lambert@novell.com
---
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
-------------------------------------------------------------------------------
Newsgroups: comp.unix.bsd
From: hlu@eecs.wsu.edu (H.J. Lu)
Subject: Re: [386BSD] gcc2 and -fPIC
Organization: School of EECS, Washington State University
Date: Wed, 27 Jan 93 18:56:36 GMT

In article <1993Jan27.172321.14231@jpl-devvax.jpl.nasa.gov>, kaleb@jpl-devvax.jpl.nasa.gov (Kaleb Keithley) writes:

[...]

|> >|> least that's what I was told when I asked gnu.gcc.help.  There are patches 
|> >|> out there to make gcc generate PIC on 386.
|> >
|> >Those patches are for psudo PIC for SVR3. I don't care SVR3. I want ELF.
|> 
|> Actually the patches I'm referring to are for SunOS on Sun386i, which

They seem to be the same thing. SVR3 uses COFF.

|> is actually COFF.  At the risk of repeating myself, gcc itself doesn't
|> yet support PIC on any 386, irrespective of anything else.
|> 


I believe gcc supports PIC for SVR4. I didn't say there was no bug in PIC
support.

|> >That is precisely why I want PIC. I'like to see PIC/ELF be used in 386bsd
|> >and Linux.
|> 
|> I think you're asking for an awful lot.  Linus Torvalds, Richard Stallman,
|> and Bill and Lynne Jolitz already have a lot of momentum behind a.out in
|> their respective operating systems.  Even if the changes were isolated to 
|> only the assembler and linker, I haven't seen any evidence that any of them 
|> intend to deviate from that direction.
|> 

I know that. After having worked on the shared library under Linux, I am
convinced that ELF is the much better solution for dynamic linking. I have
been pushing it very hard. I will do whatever I can to help it.


H.J.
Newsgroups: comp.unix.bsd
From: mrh@io.nosc.mil (Mike Halderman)
Subject: Re: [386BSD] Continuous CPU usage of XFree?
Organization: Naval Ocean Systems Center, San Diego, CA
X-Newsreader: TIN [version 1.1 PL7]
Date: Tue, 26 Jan 1993 04:01:51 GMT

Mike Halderman (mrh@io.nosc.mil) wrote:
: 
: Why does XFree86 use 100% of the cpu even when it isn't doing anything?
: Other programs get only 50% of the cpu when X is running.
: 
: Mike Halderman
: mrh@nosc.mil

The problem was the select portion of the busmouse driver I was using.

I found one that works:

	Host snowhite.cis.uoguelph.ca
	  Location: /pub
	   FILE -rw-rw-r--      10519  Oct 19 10:58  386bsd-busmouse.tar.Z
From: wjolitz@soda.berkeley.edu (William F. Jolitz)
Newsgroups: comp.unix.bsd
Subject: [386BSD] Newsgroup Voting Ends the 31st
Date: 28 Jan 1993 19:07:48 GMT
Organization: U.C. Berkeley, CS Undergraduate Association
NNTP-Posting-Host: soda.berkeley.edu

Since Chris is at USENIX, I just thought I'd remind 386BSD users that
voting for the comp.os.386bsd newsgroups ends the 31st. 

Please vote for these newsgroups, if you haven't already. If you need
a voting form, check news.groups or send me email ASAP at 
ljolitz@cardio.ucsf.edu and I will forward you the CFV posting.

If you already have voted, thank you very much. I hope these newsgroups
can help us get development (and 0.2) coordinated and back on track.

Lynne Jolitz.
Newsgroups: comp.unix.bsd
From: eoahmad@ntuix.ntu.ac.sg (Othman Ahmad)
Subject: Re: [386BSD] Creative Labs CD-ROM drivers - Any progress?
Organization: Nanyang Technological University - Singapore
X-Newsreader: TIN [version 1.1 PL8]
Date: Tue, 26 Jan 1993 07:34:32 GMT

Scott Gray (gray@pecan.cns.udel.edu) wrote:
: I realize that this is beating a dead horse...and, yes, I am one of the
: fools that purchased the non-SCSI creative labs multi-media package, BUT
: has anyone made any progress on writing a driver for the damn thing?
Why do say we are stupid when the ATBus version is surely faster than the
SCSI version?
	The stupid ones are the manufacturers who refuse to give info on
the ATBUS CDROM interface.

: If not, can anyone point me towards some documentation for the CD-ROM.  I
: have seen the book on programming the sound-blaster, but not the CD-ROM 
: portion.


--
Othman bin Ahmad, School of EEE,
Nanyang Technological University, Singapore 2263.
Internet Email: eoahmad@ntuix.ntu.ac.sg
Bitnet Email: eoahmad@ntuvax.bitnet

Xref: sparky comp.unix.bsd:11870 comp.sys.ibm.pc.hardware:37299
From: noel@reg.triumf.ca (NOEL GIFFIN)
Newsgroups: comp.unix.bsd,comp.sys.ibm.pc.hardware
Subject: Re: ATI Mach32 and Xfree86 or XS3?
Date: 26 Jan 1993 13:26 PST
Organization: TRIUMF: Tri-University Meson Facility
Distribution: world
NNTP-Posting-Host: reg.triumf.ca
News-Software: VAX/VMS VNEWS 1.41    

In article <1993Jan26.162704.13442@usasoc.soc.mil>, ted@usasoc.soc.mil (Mr. Ted Nolan) writes...
>
>run 386BSD and X on.  I've seen a few advertisements for the ATI Mach32
>video card.  It seems this is a local bus card that can do 1024x1280 in
>256 color mode.  Does anyone know if this has an S3 or ET4000 chipset?
>Can you run X on it?

bad news
	No it isn't an S3 or ET4000 chip, it is their own mach32 accelerator chip.

good news
	however it does emulate ibm 8514 graphics device and generic unix drivers
	for this standard should work, so x-windows is possible.

bad news
	Then again with 8514 drivers you aren't accessing the mach32 acclerator
	at all so you are paying a big price for performance you won't use.
	Also I believe the 8514 emulation is 1024x768x256 .  If you want to
	use the 1280x1024x256 modes or any of the other hi-colour or true-colour
	modes your going to have to come up with your own driver as ATI is 
	having enough problems delivering working drivers for MSDOS and windows
	let alone OS/2 and unix.	

-----------------------------------------------------------------------------
If you're a horse, and someone gets on you, and falls off, and then gets right
back on you, I think you should buck him off right away.
                                         Deep Thoughts -- By Jack Handey
-----------------------------------------------------------------------------
Newsgroups: comp.unix.bsd
From: eoahmad@ntuix.ntu.ac.sg (Othman Ahmad)
Subject: Re: [386BSD] Creative Labs CD-ROM drivers - Any progress?
Organization: Nanyang Technological University - Singapore
X-Newsreader: TIN [version 1.1 PL8]
Date: Wed, 27 Jan 1993 01:45:25 GMT

Marc Unangst (mju@mudos.ann-arbor.mi.us) wrote:
: In article <1993Jan26.073432.16561@ntuix.ntu.ac.sg> eoahmad@ntuix.ntu.ac.sg (Othman Ahmad) writes:
: >Why do say we are stupid when the ATBus version is surely faster than the
: >SCSI version?


: However, I doubt there's going to be any noticable performance
: difference at all.  Keep in mind that with a CD-ROM drive, the
: bottleneck is getting the data off the CD, not getting the data from
: the CD-ROM drive to the host.  The CD<->drive transfer rate is going
: to be 150K/s (or 300K/s, if you have one of the fancy double-speed

My figures are actually from CD disk drives called lasermate which I was led
to believe is a panasonic. It comes with 2 versions, the ATBUS(16-bit), and
SCSI(S$80 more expensive).
	Reading the specs, I notice that the transfer rate for the SCSI is
about 30%, 150K/s vs 170K/s(?). The access time of the SCSI is 0.5s vs 0.38 for
the ATBUS version. The drives look similar so must be identical mechanically
so the SCSI must have incurred a lot of overhead. Remember that the ATBUS is
not IDE, so virtually the PC has full access to the internals of the CDROM
circuit board.

: drives), no matter what you do with the host adapter; 150K/s is much
: lower than the maximum transfer rate of even an 8-bit card using
: programmed I/O.
YOu got the point. In fact I posted these observations to alt.cd-rom but
no response. I believe people do not read the specs and compare.


--
Othman bin Ahmad, School of EEE,
Nanyang Technological University, Singapore 2263.
Internet Email: eoahmad@ntuix.ntu.ac.sg
Bitnet Email: eoahmad@ntuvax.bitnet

Newsgroups: comp.unix.bsd
From: micke@dynas.se (Mikael Hybsch)
Subject: Re: [386bsd] New patch00071 is slightly wrong
Organization: DynaSoft, Dynamic Software AB
Date: Thu, 28 Jan 1993 16:02:39 GMT

In <bIQKePhq40@astral.msk.su> "Andrew A. Chernov, Black Mage" <ache@astral.msk.su> writes:

>I just look into new patch00071 of clock.c and found small bug,
>it don't calculate leap year properly, produce error in 2000 year.

The rule "year % 4" will work until year 2100, because (2000 % 400) is 0.
Of course we still want our grand children to be able o use the correct time
when they play with 386bsd.

>! 	if (sec < 1970)
>! 		sec += 100;
>! 	leap = !(sec % 4); sec = ytos(sec); /* year    */

>Correct way to calculate leap year is:

>#define isleap(y) (((y) % 4) == 0 && ((y) % 100) != 0 || ((y) % 400) == 0)

>see for example /usr/include/tzfile.h
>-- 
>In-This-Life:  Andrew A. Chernov    |  "Hay mas dicha, mas contento
>Internet:      ache@astral.msk.su   |  "Que adorar una hermosura
>FIDOnet:       2:5020/23.34         |  "Brujuleada entre los lejos
>Organization:  The RELCOM Corp.     |  "De lo imposible?!"  (Calderon)

-- 
 Mikael Hybsch                        Email: micke@dynas.se
 DynaSoft, Dynamic Software AB        Phone: +46-8-615 84 00
 Hammarby Fabriksv 13, Box 92058      Fax:   +46-8-641 92 00
 S-120 06 STOCKHOLM, SWEDEN
Newsgroups: comp.unix.bsd
From: ac116@city.ac.uk (Tarkan)
Subject: [386BSD] how do i get gcc to work on 386BSD
Summary: how do you compile a compiler?????
Keywords: gcc 386BSD compile help
Organization: The City University
Distribution: comp
Date: 21 Jan 93 14:30:47 GMT

Can anyone help me get gcc working on my 386BSD Box,,
I've got gcc-2.3.3 source but Have no idea on how you are meant to 
install ,compile, or how to get a compiler to compile it,,
After reading all the Documentations
and could anyone suggest how i could compile gcc-2.3.3 using
a sparc 1 running gcc,,,,and can anyone recommend how to setup
the Makefile and The configure file to get to work painlessly

Tarkan


-- 
************************************************
* if you haven't guessed yet...                *
*  Tarkan....             at: ac116@city.ac.uk *
********************************auto*signature**
From: bkc@ernie.Princeton.EDU (Bruce Caruthers)
Newsgroups: comp.unix.bsd
Subject: [386BSD] Install w/ only 41 Meg?
Keywords: 386bsd
Date: 22 Jan 93 21:40:17 GMT
Organization: Princeton University
Originator: news@nimaster


	Hi.  Now that I've finally figured out how to get my system to
boot from the hard drive for 386bsd, and I have the binary distribution
on disk (I take it that the mread utility doesn't handle 720K disks in
a 1.44 drive too well?  I had to transfer them all to 1.2 disks, since
I only had four unused 1.44's), I am trying to extract it.
	I thought I had read somewhere, either on the net or in the
docs I printed out (can't find it now), that I could install on a 40 Meg
partition.  After having twenty minutes of errors from extract about
"device full" followed by a reboot after a message which flashed past
my screen in a blur before the reboot (as with just about every error
message I have noticed), I figure it just ain't so.
	Is there any way to do partial extracts at a time?  (Since it
checks the files first, it won't let me do just some at a time)  Is
there perhaps some way to manually extract the stuff from the
bin01.[0-5][0-9] files?  (The docs say it is a form of cpio compressed
format, so can I use cpio to do so, one or a few files at a time?)

	Slowly getting frustrated (and $aving up for the larger
additional drive),
				-bkc

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
bkc@Princeton.EDU   Bruce Caruthers '93   Princeton University   bkc@Sgi.COM
	"It is not death that a man should fear, but he should fear
	 never beginning to live."		-- Marcus Aurelius