HDTenEightyP/NetNews huggingface dataset:
From: rivers@ponds.uucp (Thomas David Rivers)
Subject: More on pccons/XFree86 problems (keyboard hangs)
Keywords: 386BSD X11 XFree86 console pccons
Date: Sun, 13 Dec 1992 17:29:00 GMT



Well, after the response from my last posting relating the problems
about overnight keyboard hangs w/Xfree86 - I've tried/done several things:

  1) Acquired Holger's keycap-0.1.1  

  2) Grabbed that enhanced pccons.c which was posted recently.

  3) Acquired Julian's new scsi driver.

Ok, so - I thought I would spend the weekend installing the new scsi
driver, and try out both console drivers and see which worked best.

  Installing the SCSI driver wasn't too hard; (and runs *much* faster
than the stock as drivers) - but when I went to try the enhanced
pccons I got bitten by the 640K limit.  

  So, since I couldn't build a kernel with everything I wanted _and_
fit in 640 K without using the stock pccons.c, I decided to have a
go and figure out what was causing the keyboard to lock up overnight.

  I looked in /etc/daily, and saw it just mostly moved files around,
except for one thing; it sends a SIGHUP (1) to syslogd.  Apparently,
this is the culprit.

  Try it out yourself, inside of an X window, do a :

     kill -1 `cat /var/run/syslog.pid`

  and your keyboard will lock up.


  For now, I've commented out the kill in /etc/daily, since I don't
change the syslogd configuration file very often.  But I would like
to know if:

  1) Does the enhanced pccons suffer from this?

  2) Does Holger's codrvr (a.k.a.  keycap-0.1.1) suffer from this?

  3) Could someone detail the necessary steps for building a kernel
 and loading it about the 1meg line - and I could determine this for
 myself.

(Note that the lock-up doesn't occur if your not running X.)

I will probably try and examine the stock pccons.c to determine where
the problem can be corrected... but if someone has an idea/fix, feel
free to beat me to it...

	- Dave Rivers -
	(rivers@ponds.uucp (home))
	(sastdr@unx.sas.com (work))
From: cgd@eden.CS.Berkeley.EDU (Chris G. Demetriou)
Newsgroups: comp.unix.bsd
Subject: Re: Almost Free Symbolic Links (source code)
Date: 18 Dec 92 19:04:00 GMT
	<DERAADT.92Dec17125257@newt.newt.cuc.ab.ca>
Organization: Kernel Hackers 'r' Us
NNTP-Posting-Host: eden.cs.berkeley.edu
In-reply-to: deraadt@newt.cuc.ab.ca's message of 17 Dec 92 19:52:57 GMT

In article <DERAADT.92Dec17125257@newt.newt.cuc.ab.ca> deraadt@newt.cuc.ab.ca (Theo de Raadt) writes:
>Because it screws up the alignment all the way through the file. It's nice
>to know that going a multiple of st.st_blocksize into the file and reading
>a multiple of st.st_blocksize bytes is going to be faster.


generally, in implemention such a beast, files less than, say, 60 bytes
would be stored in the inode, using "spare space" left by unnecessary
block pointers...

if the file gets beyond 60 bytes, the entire thing gets bumped out of the
inode, so there is no alignment problem...

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,comp.os.linux
From: peter@ferranti.com (peter da silva)
Subject: Re: INTERNATIONALIZATION: JAPAN, FAR EAST
Keywords: Han Kanji Katakana Hirugana ISO10646 Unicode Codepages
Organization: Xenix Support, FICC
Date: Thu, 17 Dec 1992 14:48:55 GMT

In article <mathias.724467456@sune.stacken.kth.se> mathias@stacken.kth.se (Mathias Bage) writes:
>   Has anyone in this newsgroup ever heard of the Unicode/ISO10646
> (UCS) standard?

You know, if 386BSD could be made to support NET-UTF (the Plan 9 version
of the 10646 standard) that would be a major advantage over commercial
Unices...
-- 
Peter da Silva                                            `-_-'
Ferranti International Controls Corporation                'U` 
Sugar Land, TX  77487-5012 USA
+1 713 274 5180                            "Zure otsoa besarkatu al duzu gaur?"
From: paul@isl.cf.ac.uk (Paul Richards)
Newsgroups: comp.unix.bsd
Subject: bsd equivalent?
Date: 15 Dec 92 22:05:08 GMT
Organization: Intelligent Systems Lab, ELSYM, Universiity of Wales, College of 
              Cardiff.

Could someone give me a bsd equivalent to the following sysv code. As a
temp. fix I just used re_comp and re_exec but I'm not sure whether
there's some subleties that I've missed since I don't use sysv systems.

        compile(regex_str, regex_buf, &regex_buf[MAXPATHLEN],'\0');
        step(s, regex_buf);

I'm trying to port guide which is needed by some xview programs. Guide
uses an AT&T proprietary file regexp.h which contains source code for
compile and step, the package (xvnews) seems to work fine when I use
re_comp and re_exec but I may have missed some important difference.
Newsgroups: comp.unix.bsd
From: alm@netcom.com (Andrew Moore)
Subject: Re: tip & screen
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Date: Mon, 14 Dec 1992 01:10:53 GMT

In article <tlukka.724239227@snakemail.hut.fi> tlukka@lk-hp-8.hut.fi (Tuomas J. Lukka) writes:
>Has anyone hacked screen to work on 386BSD? I get it to compile
>but have not yet gotten it to actually work.

There is a port of screen in the etc01  distribution.  Last I tried, it
didn't work well with tip - e.g., scrolling on a remote was very
slow.  I didn't attempt to fix it...

>
>Also, what do I need to make tip work with sz etc, there was a patch,
>is it in the kit?

Use tip's CONNECT command (~C) (not mentioned in the 386BSD manual).
~C connects a local program's (e.g., sz's) standard i/o to the serial
port.  If you are using a version of sz that reads/writes stdio (e.g.,
zmodem-3.03 which is part of the etc01 distribution), this works fine.

If you are using a newer version of sz (e.g., rzsz-3.17, is the newest,
as far as I can tell), then patches are needed.   Version 3.17 is nice
because it now supports crash recovery.  But rz/sz-3.17 doesn't work
out of the package with tip because, rather than do serial i/o via the
standard input and output like in 3.03, it now attempts to open
/dev/tty instead.  The patch is simply to replace the open("/dev/tty",
2); in rbsb.c with dup(0);

I have some patches for this and to prevent subsequent writes to stdio
which I can post.  The patches seem to slow down zmodem on a Sun,
though, which I am still looking into.  (maybe to do with buffering?)
-Andrew Moore <alm@netcom.com>
Organization: Stanford Linear Accelerator Center
Date: Friday, 11 Dec 1992 14:49:17 PST
From: <CALT@SLACVM.SLAC.STANFORD.EDU>
Newsgroups: comp.unix.bsd
Subject: SLIP for 386bsd

Where can I get SLIP for 386bsd? Thanks!

Ching Shih
shih@cithex.bitnet
shih@cithex.caltech.edu
From: news@hrd769.brooks.af.mil (InterNet News)
Newsgroups: comp.unix.bsd
Subject: Re: INN on 386BSD ?
Date: 18 Dec 92 17:01:54 GMT
Organization: Armstrong Lab MIS, Brooks AFB TX
NNTP-Posting-Host: hrd769.brooks.af.mil

In article <BzGpBF.GwH@ns1.nodak.edu> zonjic@plains.NoDak.edu (Radivoje Zonjic (CE)) writes:
>
>Has anyone succeeded in compiling INN on 386BSD ? I would like to try
>it, so if anyone has any experience with INN on 386BSD please let
>me know by e-mail (and if possible, include configuration header
>file(s))...
>
>
>Thanks,
>Rade

  I recently (like yesterday) uploaded inn 1.6 (I think) to ref.tfs.com
in the packages directory.  It is the complete package, including the
most recent patches.  It works fine.

  Things to look out for...

  We use termios, which the Configure script messes up on.
  There is a define in config.h to make it work.  I think I fixed the
code in Configure to correctly look for a termios indicator.

  You may find that you are having problems with filexp.  The one that comes
with Configure has an error that I simply got bored trying to fix.  I use
the filexp that comes with the bsd386 base distribution, and commented out
the filexp create script segment (I think).
  The error message is some thing 'Unterminated string at line 28'.

  There were no 386bsd specifics, per se, but there were a couple of tense
moments getting it going in the first place.  If you have any trouble
with it, drop me an E-Mail (or contact me through comp.unix.bsd |-( )
and I will be glad to help anyone I can.

  Note that if anyone has trouble with it, everyone probably will.  I will
summarize and correct the problems as they arise.

TSgt Dave Burgess
NCOIC AL/MIS
Brooks AFB, TX
Newsgroups: comp.unix.bsd
From: dawes@physics.su.OZ.AU (David Dawes)
Subject: Re: [386BSD] XFree86 doesn't start
Keywords: X11,386BSD
Organization: School of Physics, University of Sydney, Australia
Date: Mon, 14 Dec 1992 01:13:48 GMT

In article <1992Dec12.085523.3828@aki.en.open.de> aki!wegmann (Frank Wegmann) writes:
>I'm posting this for a friend:
>
>I have problems running xfree86. When I try to run 'xinit' or 'X'
>my screen switches to graphics mode, displays some random dots in
>black and white and after a second or two I'll be back in text mode.
>
>Output of xinit >& err was:
>
>XFree86 Version 1.1 / X Window System
>(protocol Version 11, revision 0, vendor release 5000)
>Configured drivers:
>  VGA256 (256 colour SVGA):
>      et4000, et3000, pvga1, gvga, ati, tvga8900
>VGA256: et4000 (mem: 1024k numclocks: 16)
>VGA256:   clocks: 25 28 33 37 41 46 32 38 51 57 65 73 81 91 64 76
>Caught signal 11.  Server aborting

The server is catching a SIGSEGV

>XIO:  fatal IO error 32 (Broken pipe) on X server ":0.0"
>      after 0 requests (0 known processed) with 0 events remaining.
>      The connection was probably broken by a server shutdown or KillClient.
>
>Trying to start X with 'X' I got the same but an additional line:
>IOT trap (core dumped)

After trapping the SIGSEGV, the server cleans up and then calls abort() which
is producing that message (and the core).

>I've rebuild the kernel with the patches and tested the
>kernel included in the XFree86 package.

Is the server running suid-root?  Can you get a stack trace from the core
with gdb and send the details?

David
--
------------------------------------------------------------------------------
 David Dawes (dawes@physics.su.oz.au)    DoD#210      | Phone: +61 2 692 2639
 School of Physics, University of Sydney, Australia   | Fax:   +61 2 660 2903
------------------------------------------------------------------------------
Newsgroups: comp.unix.bsd
From: stripes@pix.com (Josh Osborne)
Subject: Re: Shared lib benchmarks, and experiences
Organization: Pix Technologies -- The company with no adult supervision
Distribution: usa
Date: Tue, 15 Dec 1992 17:54:50 GMT

In article <BzAEnE.GKq@ra.nrl.navy.mil> eric@tantalus.nrl.navy.mil (Eric Youngdale) writes:
[...]
>	Offhand, I do not see why the number of entry points represents a
>problem.  The general structure of a sharable library under linux is that we
>start with the jump table itself.  This is usually padded to some large size to
>accomodate future expansion.  [...]
> [...]   There is no
>reason a priori that we even need to use up the jump vector slots in any
>particular order.  We could use them randomly if we wanted to, although it
>would serve no useful purpose to do so.

Ahhh, the jump table order is user definable.  Good trick, that solves alot of
problems.

[... PIC disscusion...]

>	There was another objection that has been raised in the past by various
>people, and that is that in the 3/486 architecture there are relatively few
>machine registers compared to something like a VAX.  The PI code that I have
>seen GCC generate always seems to use up one register as a reference pointer of
>some kind or another, and when you reserve this register (usually ebx) for this
>purpose, it is not available to the compiler for other uses, and this could
>lead to poorer performance.  I have not seen any numbers to back this up,
>but the objection has been raised.

Well, you do have some segment registers free.  You wouls have to add a kernal 
call that allowed to you add entries in the segment descriptor table (and
verifys that they are valid segments), but once that's done you could use
"far calls" (or even change CS).  I'll admit it's ugly, but it would be almost
as fast as non-PIC code (segment loading takes a few cycles, and far calls/
segment overide takes a extra cycle or 2, all the k-calls would be done at
lib load time, and not be much of a problem).

[...]
-- 
           stripes@pix.com              "Security for Unix is like
      Josh_Osborne@Real_World,The          Multitasking for MS-DOS"
      "The dyslexic porgramer"                  - Kevin Lockwood
We all agree on the necessity of compromise.  We just can't agree on
when it's necessary to compromise.       - Larry Wall
Newsgroups: comp.unix.bsd
From: wcl@oakhill.sps.mot.com (Wayne Long)
Subject: Easy way to create unix man pages?
Keywords: unix manual hypertext
Organization: Motorola Inc., Austin, Texas
Date: Thu, 17 Dec 1992 16:52:57 GMT


I'm looking for a filter, utility, or editor that
will take normal, what-you-see-is-what-you get
text, and convert it into a unix man page with
minimal hassle.

I realize that some of the major sections and headings
would have to be delimeted in some way, but I'd like to
be able to do this editing with a normal text editor
(or framemaker or MacIntosh Word) in as minimally
cryptic way as possible.


Wayne

-- 
-------------------------------------------------------------------
Wayne Long                      Internet: wcl@risc.sps.mot.com
6501 William Cannon Drive West  UUCP: cs.texas.edu!oakhill!risc!wcl
Austin, Texas 78735-8598        Phone (512) 891-4649
From: garlick@ecst.csuchico.edu (Jim Garlick)
Newsgroups: comp.unix.bsd
Subject: BSD for Apollo DN3000
Date: 20 Dec 92 03:46:44 GMT
Organization: California State University, Chico
NNTP-Posting-Host: pitbull.ecst.csuchico.edu

Does anybody know if a BSD port of some type exists for Apollo DN3000's 
and/or who to contact about it?

Some are about to get orphaned around here.

Thanks!

Jim Garlick
CSU Chico

p.s. please respond via email to garlick@ecst.csuchico.edu
From: mattb@sdd.hp.com (Matt Bonner)
Newsgroups: comp.unix.bsd
Subject: Re: [386bsd] need motif
Date: 16 Dec 1992 18:01:14 GMT
Organization: Hewlett-Packard, San Diego Division
Distribution: world
NNTP-Posting-Host: hpsdlg16.sdd.hp.com
Keywords: motif 386bsd

In article <1274@zogwarg.etl.army.mil>, mike@zogwarg.etl.army.mil (Mike McDonnell) writes:
|> I need to buy motif to rehost some code under 386bsd.  Someone please
|> tell me about a distributor here in the US.  Prices too if possible.

This is from the comp.windows.x.motif FAQ, which you can get at (from the
FAQ):

Answer: A number of FAQ's (including this one) are available for anonymous ftp
at pit-manager.mit.edu, 18.172.1.27 under the directory pub/usenet.  (Motif is
under pub/usenet/comp.windows.x.motif)

Subject:  7)* Where can I get Motif?

    An OSF/Motif source license must be obtained from OSF before source can be
obtained from the Open Software Foundation. Call the Direct Channel Desk at OSF
at 617-621-7300 or email direct@osf.org for ordering information.  In addition
to the full Motif source, "option C" allows you to purchase source for the
window manager mwm to run on X terminals.

The basic answer is that since I don't think anyone is selling Motif
binaries for 386bsd (can anyone correct me on this?) you have to buy a 
source license through OSF.  Depending on what you are doing it will 
either be $2000 or $15,000, last I heard.

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
From: baloo@nx01.mik.uky.edu (kevin s coupal)
Newsgroups: comp.unix.bsd
Subject: Is there any FTP sites for Tiny BSD diskettes?
Summary: hi
Keywords: bsd tiny
Date: 12 Dec 92 17:06:46 GMT
Organization: University Of Kentucky, Dept. of Math Sciences
X-Path: nx01.mik.uky.edu!baloo

I'm looking for a fast way to get 386BSD set up.  Is there any ftp sites
that have the Tiney BSD diskette?  I just thought that would be much
faster than mailing off for it.  if not does anyone have a copy they
can send me?  
Kevin Coupal
Baloo@mik.uky.edu
:w!
From: Guy_Dawson@transarc.com
Newsgroups: comp.unix.bsd
Subject: Re: Dumb Question: Why 512 byte block?
Date: 18 Dec 92 05:59:55 GMT
Article-I.D.: transarc.sfATJvL0BwwOIJBUcl
Organization: Carnegie Mellon, Pittsburgh, PA

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


I think this was due the the fact the the VAX on which BSD was developed
for a long time based most things on 512byte pages - espically its
virtual memory system,

-------------------------------------------------------------------------------
-
Guy Dawson - guyd@hoskyns.co.uk or todays return address!
        Hoskyns Group Plc, 190 City Road, London, EC1V 2QH
	Tel (UK) 071 251 2128

By me, for me.
From: babraham@unpcs1.cs.unp.ac.za (Bobby Abraham)
Newsgroups: comp.unix.bsd
Subject: [386bsd] Damaged bootstrap
Date: Tue, 15 Dec 1992 14:39:31 GMT
Organization: Dept. Computer Science, UNP
Distribution: world
NNTP-Posting-Host: pc030.cc.unp.ac.za
Keywords: 386bsd

My machine won't boot 386bsd now.  It was working fine and I took it down
real carefully.

The fixit disk allows me to mount /dev/wd0a and everything look fine
including /386bsd
How do I use disklabel to rewrite the bootstrap code ?

I have a Seagate IDE 107MB drive.

- thanks
-------------------------------------------------------------------
Bobby Abraham
Dept. of Computer Science
University of Natal, Pietermaritzburg
email - babraham@unpcs1.cs.unp.ac.za
        abraham@unpsun1.cc.unp.ac.za
-------------------------------------------------------------------
Newsgroups: comp.unix.bsd,comp.os.linux
From: wgsteven@cayley.uwaterloo.ca (Warren Stevens)
Subject: Re: 386BSD + LINIX + GNU + X11R5 on CDROM - let us know what you want!
Organization: University of Waterloo
Date: Sat, 12 Dec 1992 20:48:22 GMT

With regards to all this information on CD, can someone tell me when
the CD is expected to be produced, who i can get info from, and all
that other stuff?

Thanks,

Warren
From: mhiroshi@tansei.cc.u-tokyo.ac.jp (H. Murakami)
Newsgroups: comp.unix.bsd
Subject: [386BSD] Huge virtual space I need badly.
Date: 16 Dec 92 19:19:44 GMT
Organization: Hokkaido Univ. However I am subject to tansei for JUNET.


I need the huge virtual space for 386BSD.

I found that the current limitation is as little as 32MB.

I would like to use as large as 1GB of virtual memory for one 
process or program to do the large FEM computations. 
( I allocated 2GB of HDD for that. Don't tell me that I should not 
  do the pagings.  The algorithm is quite efficient to suppress the 
  paging to minimal. )

I tried to change the parameters in the header files to 
reconfigure the kernel.  However, it seems my change is not 
correct enough.  I guess I do not know enough to do the right 
modifications.  With huge size of pages, probably many part of
the sourcecode of the kernel need to be modified, I guess.

Has anyone succesfully using the 386BSD with larger virtual 
space per process than just 32MB ?

What is the logical limit of the virtual memory size per process
of the currect implementation of the 386BSD system ? I would like
to know.

Oh please, if anyone know the right way to expand the limitation,
please post the direction.

Than you.

	Hiroshi Murakami
	mhiroshi@tansei.cc.u-tokyo.ac.jp
Newsgroups: comp.unix.bsd
From: murray@its.uct.ac.za (Mark Murray)
Subject: [386bsd] Who has got working lpt drivers for 386bsd?
Keywords: printer 386bsd lpt driver
Organization: University of Cape Town, Information Technology Services
Date: Mon, 14 Dec 1992 11:26:57 GMT

Hello, all

A while back the qustion of lpt drivers got discussed in this group.
I now need to get a printer going on my box, and would like to get the most 
recent and most stable code. Could some kind soul please poinr me in the 
right direction?

Thanks, Mark

--
Mark Murray  (ITS/MURRAY)        \+/ Internet: murray@ucthpx.uct.ac.za
User support services            +X+ Voice:    +27 21 650 3025
Information Technology Services, /+\ This .sig is umop ap!sdn
University of Cape Town, Rondebosch 7700, South Africa
Newsgroups: comp.unix.bsd,alt.suit.att-bsdi
Subject: Re: AT&T/USL CD-ROM Review Process
From: rmk@rmkhome.UUCP (Rick Kelly)
Organization: The Man With Ten Cats
Date: Wed, 16 Dec 1992 03:16:50 GMT
Reply-To: rmk@rmkhome.UUCP (Rick Kelly)

In article <1992Dec14.162111.29882@crd.ge.com> davidsen@crd.ge.com (bill davidsen) writes:
>In article <1992Dec13.183240.23944@blaze.cs.jhu.edu>, bogstad@gauss.cs.jhu.edu (Bill Bogstad) writes:
>
>| 	I'ld like to know why people think that USL won't sue the Jolitzes
>| if they win against BSDI.  Is there something magically wrong that BSDI did
>| that the Jolitzes didn't.  (Okay, BSDI charges money.)  Still, I'ld like
>| 386BSD and the other freeware Unix clones to succeed to the extent that I
>| can purchase support for them.  I'm quite happy to hack on my own system for
>| fun, but when I go to work it would be nice to be able to use the same
>| system.  Until I can safely trade some of my employers money for less
>| hacking on the company time clock, I won't be able to do this.  I can
>| understand that this might not be the primary goal of either Jolitz (386BSD)
>| or Linus (Linux); but I would hope that neither one of them would mind their
>| software being used for something besides hacking.  I predict that if it
>| appears even remotely that 386BSD or Linux are starting to encroach on the
>| commercial Unix market; USL will take any and all legal steps possible to
>| stop their further distribution.
>
>  Note that AT&T signed off on Coherent, even though the authors had
>obviously seen AT&T code. If AT&T has reason to believe that there is
>AT&T code in NET2, or paraphrased routines, or program structures, they
>have the right and obligation to sue. Linux was clearly written from
>scratch, as opposed to having been written based on AT&T code ant then
>"cleansed." I don't think there's much comparison.

Actually, Dennis Ritchie looked at Coherent and waved his hand over it.
Things were a little more informal in those days.  However, AT&T did
tell some competitors of MWC that Coherent was tainted before DR saw
the code.  This caused MWC to lose a large contract.

>  For those who aren't up on legal positions, if the officers of a
>company don't protect the assets of the company (like code and trade
>secrets) the stockholders have the right to sue the officers to recover
>lost profits. As in sue them personally. Without making any judgement on
>the merits of the case, I can't imagine the owner of the code NOT
>protecting it.

Really.

-- 

Rick Kelly	rmk@rmkhome.UUCP	unixland!rmkhome!rmk	rmk@frog.UUCP
Newsgroups: comp.unix.bsd