HDTenEightyP/NetNews huggingface dataset:
From: root@gimli.cs.uct.ac.za (Sandi Donno)
Subject: Re: Microsoft busmouse on 386BSD?
Organization: Computer Science Department, University of Cape Town
Date: Sat, 19 Dec 1992 06:09:02 GMT

In <1992Dec18.162524.11962@lgc.com> danson@lgc.com (Doug Anson) writes:

>HI:

>I have downloaded from agate the mousedriver.tar.Z from /incoming. I installed
>it in my 0.1 pl58+ kernel. I actually have a Microsoft Busmouse and not a 
>logitech busmouse (which I believe the driver is made for). Well, the driver
>doesnt work with the MS mouse. 

I have placed my working ms-busmouse driver port in /usr/home/sandi on
ref.tfs.com. Or ftp it from gimli.cs.uct.ac.za in ~ftp/386bsd/local.
--
Sandi Donno
University of Cape Town, South AFrica
Newsgroups: comp.unix.bsd
From: scott@pita.cns.ucla.edu (Scott Burris)
Subject: Re: boot string; boot & root floppy set (was Re: Occasional system hangs)
Date: 14 Dec 92 17:07:45 PST

karl@NeoSoft.com (Karl Lehenbauer) writes:

>Another useful thing would be to have a "boot and root" floppy set, where
>booting would pull the kernel off of one floppy but then pause for you to
>insert a second floppy with the "real" root filesystem on it.  It would 
>free up about 400K on the floppy for more useful programs, if it wouldn't 
>be too hard to do.

Julian's boot blocks can already prompt you to insert a new floppy after 
loading the kernel.  There are a couple of changes I needed to make to
get this to work -- something to do with the boot code not properly
recognizing you are booting from floppy.  I can post diffs if there's
interest.
-- 
----------
Scott Burris
UCLA Campus Network Services
cnetslb@oac.ucla.edu (310) 206-4860 - OR - scott@pita.cns.ucla.edu
Newsgroups: comp.unix.bsd,alt.suit.att-bsdi
From: sayre@sbstaff2.cs.sunysb.edu (Johannes Sayre)
Subject: Re: AT&T/USL CD-ROM Review Process (Re: 386BSD + GNU + X11R5 on CDROM)
Followup-To: comp.unix.bsd, alt.suit.att-bsdi
Organization: State University of New York at Stony Brook
Date: Sun, 13 Dec 1992 16:54:18 GMT

In article <1992Dec13.021307.24664@lgc.com> danson@lgc.com (Doug Anson) writes:
>In article <1ge0aaINNm4d@neuro.usc.edu>, merlin@neuro.usc.edu (merlin) writes:

[...]

>... It seems to me that this action would automatically involve the 386bsd
>users in the current USL/BSDI lawsuit 

... which would suit some people just fine.  The success of UNIX, and the
particular way in which it succeeded, has made people in all sorts of fields 
and organizations insecure and/or resentful.  Bad advice will be generally
rampant in such times.

flame away.

sayre@cs.sunysb.edu
I speak for myself only.
From: mattb@sdd.hp.com (Matt Bonner)
Newsgroups: comp.unix.bsd
Subject: Re: [386bsd] need motif
Date: 18 Dec 1992 21:47:44 GMT
Organization: Hewlett-Packard, San Diego Division
Distribution: world
NNTP-Posting-Host: hpsdlg16.sdd.hp.com
Keywords: motif 386bsd

In article <BzDLsK.JLv@ns1.nodak.edu>, tjon@plains.NoDak.edu (Christopher C. Tjon) writes:
|> 
|> BTW, If there is enough interest I could begin to maintain an archive here
|> on plains.nodak.edu.  I am sure that this package will need some porting
|> to 386bsd.  I was planning to do it over the holidays.  Feed back is 
|> welcome
|> 

Well, I stand corrected, I guess there is a version of Motif available,
although 1.1.2 is fairly old at this point.  I think 1.2.1 came out
recently or will be out soon.  Unfortunately, the licensing got much
steeper as of 1.2.  Which leads to my feedback.

I would be quite interested in a PD version of Motif, but I'm also 
curious what version of Motif they are claiming compliance with.
Both the documentation and the functionality of the code have
changed and continue to change.  Not to mention the correctness of
OSF/Motif...

Thanks,
Matt
-- 
Matt Bonner                  |  Email: mattb@sdd.hp.com
Hewlett-Packard Company      |  Snail: 16399 West Bernardo Drive
Ink-jet Components Division  |         San Diego, CA  92127-1899
Newsgroups: comp.unix.bsd,comp.os.linux
From: wade@nb.rockwell.com (Wade Guthrie)
Subject: Re: 386BSD + LINIX + GNU + X11R5 on CDROM - let us know what you want!
Organization: Rockwell International
Date: Fri, 11 Dec 1992 22:52:41 GMT


In article <1992Dec2.055049.24923@tfs.com>, julian@tfs.com (Julian Elischer) writes:
> In article <ByM6vo.C8C@ux1.cso.uiuc.edu> Jeff-Randall@uiuc.edu (Jeff Randall) writes:
> >
> >>The CD will be will be mastered in ISO 9660 format (all filenames 8.3)

Hoooray!!!!

> >Perhaps using the rockridge extensions would be a better Idea than a 
> >non-standard program hacked up just for this CD.. I believe that the
> >Linux CD-ROM driver already handles them and it would be likely that
> >the 386BSD driver would eventually support it as well... if it doesn't
> >already... 

The Linux cd-rom drivers may support this already, but if you don't already
HAVE Linux up and running on your system, the point is moot.  I would not
like to see the Rockridge extensions, 'cause then I wouldn't be able to 
load Linux from the CD on a system that currently has only DOS.

Wade Guthrie
wade@nb.rockwell.com
From: vax@ccwf.cc.utexas.edu (Vax)
Newsgroups: comp.unix.bsd
Subject: [386BSD] perl SLIP script - help
Keywords: perl slip slattach question stty
Date: 14 Dec 92 12:11:48 GMT
Organization: The University of Texas at Austin, Austin TX

I had extreme difficulty getting that perl script to work, but I
finally did it.  It really saves me alot of trouble; before I had
to hand-type the inet address it gave to me!
In any case, I have the slight problem that the network connection
wil be lost after a short while!  Anyone fixed this problem?
It appears that my slattach process simply disappears... possibly
due to a bug?
I have to manually slattach ifconfig and route add default to get
it to work again (the modem doesn't actually hang up).
Also, the stty command didn't like min and time... any idea why?
-- 
Protect our endangered bandwidth - reply by email.  NO BIG SIGS!
VaX#n8 vax@ccwf.cc.utexas.edu - finger for more info if you even care.
Newsgroups: comp.unix.bsd
From: news@hrd769.brooks.af.mil (InterNet News)
Newsgroups: comp.unix.bsd
Subject: Re: [386BSD] Disklabel for MAXTOR LXT340S
Date: 19 Dec 92 17:50:53 GMT
Organization: Armstrong Lab MIS, Brooks AFB TX
NNTP-Posting-Host: hrd769.brooks.af.mil

In article <PCG.92Dec18223754@decb.aber.ac.uk> pcg@aber.ac.uk (Piercarlo Grandi) writes:
>Therefore the best bet is to give a bogus geometry, of which the default
>Adaptec supplied one is one of the most convenient, being N cylinders of
>1MB each, which makes partitioning easier, and abandon all hopes of
>doing lowe level optimizations as those done in the BSD filesystem code,
>that try to minimize things like rotational latency, which are actually
>handled by the LXT340 OS.

  Note to Ultrastor 24F users with Maxtor 340:

  When using the 24F in ISA mode (because none of us can get the 
specs for the controller :-(), it is necessary to use the geometry
reported by the controller at boot up.  This configuration is neither
the physical geometry nor the N * 1Meg geometry, but some third
strange geometry.  Using any other seems to mess the 340S up rather
badly (resulting in inode losses and files overwriting each other).
With the geometry exception, this article goes a long way to explain
some of the unusual behaviors of the 340S and the Ultrastor card.
A public Thank You for an informative article.

>
>A couple of years ago we had a discussion on this; somebody recently
>posted in this newsgroup a patch along the line sof that discussion that
>just makes the BSD filesystem code try to keep block sequentially
>contiguous if the parameters indicate it is a SCSI disk, with no fancier
>layout policy (which are of dubious value anyhow).
>--

  I think the purpose of the patch was to not do anything (basically) to
an SCSI file system, since there is no real way of know what the file
system on the disk REALLY looks like.  I looked at it and will be 
incorporating it over the holidays, even though I am using the SCSI disk
as if it were an ESDI/IDE drive.

>Piercarlo Grandi, Dept of CS, PC/UW@Aberystwyth <pcg@aber.ac.uk>

TSgt Dave Burgess
NCOIC AL/MIS
Brooks AFB, TX
From: ferrick@acsu.buffalo.edu (Patrick K. Ferrick)
Newsgroups: comp.unix.bsd
Subject: Re: tape drive advice needed...Me too!
Date: 12 Dec 92 01:21:27 GMT
Organization: UB


Setup:  AMD 386/40, 4Mb
        1542B + Maxtor 213Mb SCSI (ID=0) + Wangtek 5150ES (ID=1)
        120Mb Rodime IDE as boot disk

Problem:  disk is found at bootup, nothing about the tape
          unable to get anything going with the tape drive

(if you have a disktab for the Maxtor I'd be interested in that also!!!)

What do I have to do to get the 5150ES going?  Should it appear as as1 on
boot?  Or do I have to do change something for this to be possible?  If
you are reading this on Friday night (12/11) and can help, please send me
email!  I'm snowed in with a working 386bsd and tons of source on tape, 
with a so-far non-working SCSI tape drive!  Aaaaargh!

Thanks a lot,
pat
Newsgroups: comp.unix.bsd
From: terry@cs.weber.edu (A Wizard of Earth C)
Subject: Re: [386bsd] 16550 and rtscts patch
Organization: Weber State University  (Ogden, UT)
Date: Mon, 14 Dec 92 17:18:34 GMT

In article <Bz25Io.L40@ucunix.san.uc.edu> pmartin@eniac.san.uc.edu (Paul Martin) writes:
>
>I applied the rtscts flow control patch to the com driver that was
>posted here sometime back.  Now I cannot send anything to the modem.  The
>modem does not receive the characters, and the command:
>echo ats0=1 > /dev/com2
>seems to hang until I shut off the modem.  This worked before the patch.
>I am using 16550's.  By the way, the mouse on com1 still works fine.
>
>Any Ideas?

I haven't had a chance to look at the patch yet (I did save it off);
I suspect that the problem is that the inverse level is being looked at
(ie: only with the RTS deasserted can you send).  The other possibility
is that the CTS assert/RTS require order is munged, and your modem needs
your serial prot to assert before it can assert, and your serial port
needs the same (ie: starvation deadlock).

In general, it can be said that *nobody* does CTS/RTS as "expected", and
unless you have a Bell 103 dataset, you can't expect it to work quite
right without a lot of tweaking.

The other possibility is that *many* modems will not assert RTS until
they have carrier; this is fine for dial-in to a UNIX box, but dial out
expects to be able to dialog with the modem without DCD *or* RTS
present.  If you are using a "calling unit" version of the device, this
problem should be taken care of for you on dial out (although I can't
vouch for whether or not the patch only applies to "calling unit"
devices AFTER DCD has been asserted.

I assume since you can "shut off" your modem that it's external.  If you
have a breakout box, you may want to watch the signal levels to/from
the modem to confirm your problem.


					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: cgd@eden.CS.Berkeley.EDU (Chris G. Demetriou)
Newsgroups: comp.unix.bsd
Subject: MH 6.7.2 [UCI] ported to 386bsd
Date: 14 Dec 92 22:29:27
Organization: Kernel Hackers 'r' Us
Distribution: world
NNTP-Posting-Host: eden.cs.berkeley.edu

i've managed to do a port of MH 6.7.2 [UCI] to 386bsd 0.1.

it's available from
ref.tfs.com:/usr/othersrc/public/mh-6.7.2/mh-6.7.2.tar.Z

if you'd just like to install the binaries, get
ref.tfs.com:/usr/othersrc/public/mh-6.7.2/mh-6.7.2-bindist.tar.Z


if you use this package, i'd advise you send mail to
386bsd_mh_users-request@ref.tfs.com
to get on the
386bsd_mh_users@ref.tfs.com mailing list...

i'll be announcing bug fixes on that list, and i'm sure that people
will find bugs; it was a pretty ugly port... 8-)

Chris
--
Chris G. Demetriou                                    cgd@cs.berkeley.edu

"Sometimes it is better to have twenty million instructions by
        Friday than twenty million instructions per second." -- Wes Clark
Newsgroups: comp.unix.bsd
From: dfox@quack.sac.ca.us (David Fox)
Subject: Re: Need help with AT&T UNIX PC and DOS
Organization: The Duck Pond public unix: +1 408 249 9630, log in as 'guest'.
Date: 19 Dec 1992 21:15:39 UTC

In article <1992Dec18.162224.1@evax12.eng.fsu.edu> tsai@evax12.eng.fsu.edu writes:
>     We have several AT&T UNIX PCs (PC7300) in our lab.  They have been
>rarely used.  Recently, the chairperson wants them to run DOS and DOS
>applications such as MATLAB.  Is anyone familier with the way to make it
>work ?  Any help or advice is greatly appreciated.

(puke)

Matlab in DOS is a joke.  Why would anyone want to do this in DOS
instead of Unix?


Newsgroups: comp.unix.bsd
From: terry@cs.weber.edu (A Wizard of Earth C)
Subject: Re: Dumb Question: Why 512 byte block?
Organization: University of Utah Computer Center
Date: Fri, 18 Dec 92 03:08:33 GMT

In article <1992Dec18.005050.20594@decuac.dec.com>, darryl@vfofu1.dco.dec.com (Darryl Wagoner) writes:
|> Why is everything in 1/2 k block instead the BSD standard of 1024 byte blocks?
|> Yes, I know there is a '-k' switch, but it seems to me it should be
|> the otherway around.

Think of disk blocks as the curve-fitting algoritm they taught you when you
first learned integral calculus:  the smaller your slices, the closer you
come to approximating the area under the curve.

If I have a set of 6 512 byte files, I will use up 3K of disk for them;
similarly, if I had a blocking factor of 1K, I would use of 6K (since the
smallest fragment usable by a file is now 1K.

If I have 6 1.5K files, this translates to 9K of disk(512B) or 12K of disk(1K).
Obviously, if I have 6 1.6K files, both blocking factors take up 512K.

The offset into the disk is a _block_offset_; what this means is that you
will start looking for data at the offet*blocking_size when given an address,
and that reads/write into kernel cache are done (usually) in block_size
increments.  A device accessed this way is a blocked device.

When you store a lot of little files on the disk, small blocks are wasteful
of disk space (for instance, 1024 empty files take 512K vs 1M of disk for
the smaller blocking factor).

When you store a few large files on the disk, it is better to eat the 0 to
1K-1B penalty for each file (as opposed to the 0 to 511B for the small
blocking factor) in trade for increased speed of access for the drive.

Since the typical 386BSD installation is a *large* number of files, it makes
sense to trade speed of access for storage space.

If you are planning on attaching a large drive, you will want to up the
blocking factor when you mkfs it, unless you make multiple partitions, since
there is a limiting calculation which will prevent >1G drives from working
well at a 512B block size.  Other than that, most modern drives, and most
modern controllers supporting scatter/gather operations in hardware tend to
lessen the impact of blocking on the drives (although significant speedups
can be had by mucking with cylinder group sizes).

Some modern file systems allow you to dynamically change blocking factor,
and even interleave, as you are writing the disk; for these file systems,
there is usually a utility called "tunefs" to adjust things for all subsequent
writes.


					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: chmr@fstgds01.tu-graz.ac.at (Christoph Robitschko)
Subject: Re: More on pccons/XFree86 problems (keyboard hangs)
Keywords: 386BSD X11 XFree86 console pccons
Organization: Technical University of Graz, Austria
Date: Tue, 15 Dec 92 08:38:01 GMT

In article <veit.724353177@du9ds3> veit@du9ds3.fb9dv.uni-duisburg.de writes:
>Ok, my second followup. I have just checked my system with codrv and I didn't
>succeed in reproducing this effect :-). Since I do not do reference counting
>in codrv, there must be a different reason. I found that pcclose in *not*
>called on 'kill -1 syslogd'. This is because usually the pccons device is
>normally not used at all (e.g. by csh or x386/keyboard input), so the vnode
>refcount for /dev/console is quite accurate.

The pccons device is normally used by getty (via /dev/vga).
And the reason why pcclose is not called on 'kill -1 syslogd' is most
probably another process which has /dev/console open. It *is* called
on my system (checked with the kernel debugger).
BTW, I can easily reproduce this bug *outside* of X windows, by killing
all processes which potentially have /dev/console open (This is not
difficult, since I only have update and syslogd running).
The console the locks up and there is *no keyboard echo* on the screen.
The system is usable again after there is some output to the pccons device.
I.e., try:
	(sleep 30; echo nixnix > /dev/vga) &
	kill syslogd (and possibly others)

>But then, what *might* be the reason, despite the fact that codrv uses a
>real /dev/kbd instead of a /dev/console switched into scancode mode?
>I had a "keyboard hang" with an earlier, unpublished version of codrv, in this 
>case, however, with a crashing or  'xterm -C'. The not so obvious reason is
>that closing a pty that happens to have the TIOCCONS attribute does not
>invalidate the constty pointer. So constty-> points to an invalid
>struct tty, which has been marked as closed. So it is not directly the 
>keyboard that hangs, but the csh which has this (invalid) tty open, waits on
>'ttopen' (see this with ps -axl on a connected terminal). The mandatory
>fix for this is the following:
>
[patch deleted]
This patch is certainly mandatory, but I doubt that it fixes the keyboard
hang, because not only the input to the shell is blocked, but also
there is no keyboard echo on the screen.

But I am glad thatyour codrv does not have that problem.

>Holger

							Christoph
-- 
.signature: Protocol wrong type for socket
Newsgroups: comp.unix.bsd
From: hackney@moxie.hou.tx.us (Greg Hackney)
Subject: Re: 386BSD install program - where is it?
Organization: Home
Date: Thu, 17 Dec 1992 13:48:32 GMT

gab10@griffincd.amdahl.com (Gary A Browning) writes:

>> Where is the source code located for the 'install' program that's on
>> the
>> 386BSD dist.fs floppy?

>The source for it was never released.

I wonder why? It sure would be nice to have to make a customized
installation process!
--
Greg
From: amurai@specgw.spec.co.jp (Atsushi MURAI)
Newsgroups: comp.unix.bsd
Subject: Re: INTERNATIONALIZATION: JAPAN, FAR EAST
Date: 16 Dec 92 00:38:48 GMT
Organization: System Planning and Engineering Corp., Tokyo, Japan
X-Newsreader: Tin 1.1 PL5

Dear Terry and Netters,

     I got your open email and I think I should explain current our
enviroment for handling Kanji rather than just "Yes" or "No". But
unfortunatly, I don't have enough time to do right now. Please wait it
until comming weekend ;-) ( During this season in Japan, we have a lot
of (too much) partys that are called "Bou Nen Kai - The party lets us
forget bad thing in this year).

Best Regards,

Atsushi Murai


-- 
$@B<0f!!=_(J (Atsushi Murai)                              Junet : amurai@spec.co.jp
SPEC                                                  Voice : (03)3833-5341
System Planning and Engineering Corp.
Newsgroups: comp.unix.bsd
From: serini@ghost.dsi.unimi.it (Piero Serini)
Subject: Re: [386bsd] patch kit problems (bad patch kit ?)
Organization: Computer Science Dep. - Milan University
Date: Thu, 17 Dec 1992 00:40:09 GMT
Distribution: global

g89s9112@hippo.ru.ac.za (Dirk Sturzebecher) writes:

>Hi all,
>I have the original src and bin distribution. I put the patchkit into
>/usr/src/patches and did run the mkpatchdirs. Then when I run the
>patches command. It goes all OK until it starts installing the patches.
>patch001 install fails ! Do I have a defect kit, or have I left out some
>crutial step ?

>Cheers, Dirk

>-- 
>-----------------------------------------------------------------------
>Dirk Sturzebecher				g89s9112@alpha.ru.ac.za
>Rhodes University Grahamstown			South Africa

$ cd /
$ ln -s /usr/src/patches patches

Then if patches command still hangs, read the /patches/tmp/*
log files: they are a log of all steps followed to install
and deinstall the crashing patch. You should be able to find
and correct the error.
An example: patch xx refused to install on my system: I checked
out the log files, and found it did a chown root.wheel on a file.
Since I have not group wheel any more, it hangs.

Have luck
Piero


------------------------------------------ Piero Serini -----------------
Piero Serini	                  E-mail: serini@ghost.dsi.unimi.it   
Computer Science Dept.            or: piero@strider.st.dsi.unimi.it
Univ. Statale - Milano - ITALY      ** mail me your .signature **
-------------------------------------------------------------------------
From: jkp@cs.HUT.FI (Jyrki Kuoppala)
Subject: Re: AT&T/USL CD-ROM Review Process
Reply-To: jkp@cs.HUT.FI (Jyrki Kuoppala)
Organization: Helsinki University of Technology, Finland
Date: Tue, 15 Dec 1992 22:33:17 GMT

In article <1992Dec14.165913.6896@fcom.cc.utah.edu>, terry@cs (A Wizard of Earth C) writes:
>Second, Linux is arguably more like SVR3 (and by extension SVR4) than
>386BSD; this, I believe, puts it in more danger of censure.  The thing
>that has protected Linux so far is its international (non-US) origin.
>This is not something USL has to worry about forever, it's simply an
>inconvenience to prosecution, not a barrier.  If a judgement were given
>regarding copyright infringement by Linux against USL's materials, it
>wouldn't matter that the judgement occurred in the US; Linus' government
>would be forced by the Berne convention to uphold the judgement.

Is this really so?  I don't think so, but what do I know.  First, I
think Berne is much more limited than the current trend of the U.S.
application of copyright laws to just about anything.  Second, as
Linux's country of origin is Finland I think it would be the Finnish
laws that would apply, not U.S.

>I think a company pressing a CDROM in the US would provide a convenient
>(and less expensive for USL) target of prosecution for such infringment,
>and thus perhaps provide a vehicle for establishing an anti-Linux
>judgement.  A CDROM publisher is a hell of a lot more likely to plead
>_nolo_contendre_ (no contest) in return for limited damage claims.

But how would this stop distribution of Linux?  Perhaps in USA, but
elsewhere?

//Jyrki
Newsgroups: comp.unix.bsd