HDTenEightyP/NetNews huggingface dataset:
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: Mon, 14 Dec 92 11:54:44 GMT

In article <1992Dec13.172900.451@ponds.uucp> rivers@ponds.uucp (Thomas David Rivers) writes:
>  Try it out yourself, inside of an X window, do a :
>
>     kill -1 `cat /var/run/syslog.pid`
>
>  and your keyboard will lock up.
>
>
>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...
>
The problem is that the pccons driver is used in two ways: first in 
the standard way through pcopen() etc., and second as a console device
through cnopen(). 
The cn???() calls simply call the corresponding pc???() routines, which 
is OK for open(), read() and write(), but not for close(), because
the close routine is only to be called when the LAST reference to 
the device was closed. But when the last reference to the console device
is closed (as happens when you kill or SIGHUP the syslogd), cnclose()
calls pcclose(), no matter if there are any references to the pccons
device (such as the keyboard input for your shell or X server).
pcclose() then thinks there is no more reference to it and disables
keyboard input.

One possible solution would be to modify pcclose() to only do the real
close operation if there are really no more files open on it (A sort of
reference count or reference bits for each device type is needed).

I don't know if any of the replacement pccons (or codrv) drivers fix this.


							Christoph
-- 
.signature: Connection timed out
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: Sun, 20 Dec 92 03:01:46 GMT

In article <BzIEv1.G7G@pix.com>, stripes@pix.com (Josh Osborne) writes:
|> In article <1992Dec18.235623.27538@fcom.cc.utah.edu> terry@cs.weber.edu (A Wizard of Earth C) writes:
|> [...]
|> >>If you have 6 1.5K files using 1K blocks,
|> >>   6 1k blocks will take each 1K from each file, and 
|> >>   3 1k blocks will take 0.5k from each file.
|> >>This was my understading from the famous FUFS paper.
|> >
|> >You can't split blocks between files.  A block is, by definition, the
|> >smallest possible allocation unit.  Thin about the case where you have
|> 
|> Under the FFS the fragment is the smallest allocation unit, and fragments are
|> only allocated at the end of a file.  The rest of the file is in blocks.
[ ... ]
|> I think the BSD FFS is normally configured with 8K blocks, and 1K fragments,
|> or 4K blocks and 512b fragments.  So the figures for 1.6K files you gave
|> are correct for the 4K/512b system, and low for the 8K/1K system.  However
|> I don't think anything prevents you from having a 1K/128b filesystem (except
|> the block device drivers for disks, and mabie the buffer cache).

Yup.  I mixed up frags and blocks.  The "df" command (original poster's topic)
reports in "512-blks" ... the source of my confusion.


					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: hasty@netcom.com (Amancio Hasty Jr)
Subject: [386bsd]epoch is available
Keywords: X windows, emacs
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Distribution: comp.unix.bsd
Date: Tue, 15 Dec 1992 23:49:47 GMT

Hi,

I just compiled epoch-4.2 over at ref and ftp the binary to 
sunvis.rtpnc.epa.gov:/pub/386bsd/incoming/epoch.Z

When I get a change I will compile epoch with optimization.

epoch is the emacs version for X-windows.

Please note that epoch only works under X-windows.

Credit:

cflatter@nrao.edu (Chris Flatters) provided the configuration files for
epoch.

Enjoy,
Amancio
-- 
Amancio Hasty           |  
Home: (415) 495-3046    |  ftp-site depository of all my work:
e-mail hasty@netcom.com	|  sunvis.rtpnc.epa.gov:/pub/386bsd/incoming
Newsgroups: comp.unix.bsd
From: rimkus@netcom.com (Mike Rimkus)
Subject: [XFree86 386BSD] can't xinit (help!)
Summary: X server dies swiftly, w/o message
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Date: Fri, 18 Dec 1992 10:33:52 GMT

When I run xinit, as root, I get two lines of version info then:
-----------------
Configured drivers:
  VGA256 (256 colour SVGA):
    et4000, et3000, pvga1, gvga, ati, tvga8900
XIO:  fatal IO error 32 (Broken pipe) on X server ":0.0"
-----------------
etc. The server doesn't give me a clue as to why it's failing. I'm fairly new
to X, so it may be something obvious.

The XFree86 docs make much fuss about getting proper Xconfig values, else
X won't work. I had placed a ModeDB line in Xconfig (Is there Xconfig
documentation, BTW?) that I got as output from "xclk -h 45 704". (My ATI Ultra
board has 45 & 33MHz crystals. My Gateway CrystalScan 1024NI accepts 48KHz
horzontal.) clock.exe from the Linux distribution didn't give me clock rates,
it just hung my machine. Do I need the clock.exe output to create some "Clocks"
line in the vga256 section of Xconfig?
Newsgroups: comp.unix.bsd
From: terry@cs.weber.edu (A Wizard of Earth C)
Subject: Re: [386BSD] How to compile isode?
Keywords: isode, 386BSD
Organization: Weber State University  (Ogden, UT)
Date: Sat, 12 Dec 92 06:40:35 GMT

In article <915@unidoct.chemietechnik.uni-dortmund.de> sn@plato.chemietechnik.uni-dortmund.de (sn) writes:
>I haven't seen this question anywhere nor any patches or fixes for this
>problem:
>I cannot compile isode from the etc distribution in dir
>/usr/othersrc/contrib/isode
>I hacked around a little at compat/asprintf.c and compat/getpassword.c
>and got the libcompat.a library to compile but there seems to be an
>error, because I cannot compile e.g. Hack, Larn or Worms.

This isn't the libcompat that everything is looking for.  The libcompat
everything is looking for is pretty much obsolete.

>I keep getting 
>gtty / stty not defined
>Has anyone gotten this to work?

stty/gtty are macros.  They are no longer the correct mechanism for setting/
getting tty modes.

>Terry Lambert wrote in his patchkit, that if you applied all the patches,
>you could compile every game... Doesn't work for me.
>Any suggestions are welcome...

I made a fake libcompat (it's on ref.tfs.com) for the compilation of the
games.  This was a full package (including stty/gtty wrapper functions)
and thus inapropriate for a patch.  There were also a couple other functions
omitted from the C library.


					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: vax@ccwf.cc.utexas.edu (Vax)
Newsgroups: comp.unix.bsd
Subject: SCSI drivers, format, slip death
Keywords: BSD,  DOS
Date: 17 Dec 92 14:48:28 GMT
Organization: The University of Texas at Austin, Austin TX

My SCSI driver which I got from ref.tfs.com was an 11-part SCSI driver
shar file.  I applied it, and I no longer get SCSI sense errors, but
the no-rewind stuff doesn't work, nor does ANY of the tape devices
(save /dev/[r]as1a).  Any help?

Also, I couldn't find format(8) or fdformat(1) in here, how do I format
a floppy (this question makes me feel stupid).

Also, why does slip die when I start it from a perl script?  When my
xterm suddenly stops, I do a netstat -r from the console window and
it HANGS when typing the localhost-127.0.0.1-UH-2-5-lo0 line of protocol
Family 2...  is this normal?  Sorry if I'm wasting bandwidth.
-- 
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.
From: tinguely@plains.NoDak.edu (Mark Tinguely)
Newsgroups: comp.unix.bsd
Subject: Re: Occasional system hangs
Date: 11 Dec 92 22:29:51 GMT
Article-I.D.: ns1.Bz495r.Byn
Organization: North Dakota State University


 Did all of you with 16+ Megs of RAM apply the patch to restrict the size of
 bufpages (Terry Lambert's patchkit patch #2. The calculations for
 bufpages were being done interchangedly in pages and bytes, the fix
 did not correct the calculation problem, but limited the error of the
 calculation; without this correction, too much RAM is lost to bufpages).

 Besides, there are small memory leaks in the kernel; Programs that fork a lot,
 cause the system to hang (make and apparently news); Big programs like X
 also make hanging very likely; Even a couple simple looping mallocing
 processes can hang a system.

 I agree that a kernel fix is better than a symptom avoidance technique.
 The kernel change is massive. The VM allows over extention of the swap
 backstore (and this can lead to the system freeze -- all of the swap
 blocks are used or fragmented to a point a certain size block cannot be
 allocated, new request for VM -- page a new part of a program, use of an already
 malloced **but memory in swap backstore is not reserved until paged out**
 memory, forking (only small part is new on a fork), and exec-ing a new program
 will look for physical memory, but cannot get it until the dirty pages
 are put on swap backstore, but backstore is full ... system will work the
 drive a little but will eventually freeze.

--mark.
Newsgroups: comp.unix.bsd,comp.os.linux
From: goer@kimbark.uchicago.edu (Richard L. Goerwitz)
Subject: Re: Dumb Americans (was INTERNATIONALIZATION: JAPAN, FAR EAST)
Keywords: Han Kanji Katakana Hirugana ISO10646 Unicode Codepages
Reply-To: goer@midway.uchicago.edu
Organization: University of Chicago Computing Organizations
Date: Fri, 18 Dec 1992 23:58:09 GMT

messina@netcom.com (Tony Porczyk) writes:
>
>>One of the big criticisms leveled at US Engineers is that they are either
>>too dumb or lazy to build into their software support for non-Western
>>scripts.  Given that Linux originates in Europe, can we look forward to
>>better support for Unicode and ISO10646?  At least for "long" charac-
>>ter definitions?
>
>Yeah, that's probably why NT supports Unicode, it's those dumb US
>Engineers...  Could we lay off idiotic generalizations and stick to
>technical aspects of the software?  It's business that dictates what's
>included in the package.  If it makes economic sense, it will be there.

Don't be so quick to criticize.  The December issue of UNIX world has
a few funny stories about American gaffes in Europe, and I've personally
heard many stories from Europeans myself along the same lines.  I'd be
willing to bet that less than 5% of US software engineers even speak a
foreign language beyond the level of a few parlez vous.  One of the big
problems we have is precisely the attitude that you display, namely that
most localizations should be done on-site.  This is fine if multilingual
support is built into the basic distributions, but really stupid if it
isn't.

As for economic sense, I have the same feeling about American's in the
mid- and large-range computer business that I have about Detroit.  They
simply aren't as aware as they should be about what their customers
really want.  NT will be a welcome departure from the past, if in fact
it offers true multilingual support.  We'll see.

-- 

   -Richard L. Goerwitz              goer%midway@uchicago.bitnet
   goer@midway.uchicago.edu          rutgers!oddjob!ellis!goer
Newsgroups: comp.unix.bsd,comp.os.linux
From: pmacdona@sanjuan (Peter MacDonald)
Subject: Re: Dumb Americans (was INTERNATIONALIZATION: JAPAN, FAR EAST)
Keywords: Han Kanji Katakana Hirugana ISO10646 Unicode Codepages
Organization: University of Victoria, Victoria B.C. CANADA
Date: Sat, 19 Dec 92 17:08:41 GMT

In article <1992Dec19.132545.2241@inftec.be> mike@inftec.be (Mike Aerts) writes:
>In article <1992Dec18.043033.14254@midway.uchicago.edu> goer@midway.uchicago.edu writes:
>>One of the big criticism leveled at US Engineers is that they are either
..
>I think we ( the Belgians ) are champions too, we have 3 official
>languages for 10M people.
...

Here in Canada, we win a different contest.  2 official languages, isolated by
10,000 kilometers.   I spent 3 years learning french, but out here on the
west coast, French speaking individuals are about as common as lilies on the moon.
Needless to say, I am a little rusty.   Just as well, given the warm reception
that I saw given to some foriegn linguists on the net recently :-).

Peter
pmacdona@sanjuan.uvic.ca
From: veit@du9ds3.fb9dv.uni-duisburg.de (Holger Veit)
Newsgroups: comp.unix.bsd
Subject: Re: Shared lib benchmarks, and experiences
Date: 14 Dec 92 08:11:54 GMT
Organization: Uni-Duisburg FB9 Datenverarbeitung
Distribution: usa
Reply-To: veit@du9ds3.fb9dv.uni-duisburg.de
NNTP-Posting-Host: du9ds3.fb9dv.uni-duisburg.de

In <1gdnvrINNp80@life.ai.mit.edu> ericy@hal.gnu.ai.mit.edu (Eric Youngdale) writes:

>In article <veit.724064215@du9ds3> veit@du9ds3.fb9dv.uni-duisburg.de writes:
>>You see this from the Linux hacker's aspect only. There are many people
>>who cannot afford recompiling anything from scratch any time, but want
>>to have binaries. This is crucial in particular for X11. We already have
>>different versions of X11 out (without shared libraries), what we certainly
>>do not need are different versions of applications and libraries, such that
>>every new program brings in its special set of shared libs. You may distribute
>>object files, to be linked at the local system, but there are even people
>>out there who do not have the space of ~7MB for kernel sources and objects
>>available; they run into problems with for instance a XServer Link kit as well.

>	Perhaps you do not understand.  The way our libraries are made, you can
>just drop a new version into the /lib directory, and add a symlink, and you are
>ready to run the same binaries with the new sharable library.  There is no need
>to relink, and you can delete the old version of the sharable library any time
>you wish.

Oh, I think I do understand what is going on. The problem is, that I am not
talking about the way shared libs are implemented in Linux, but about the 
current hack that is regarded as "shared libraries" in 386bsd. Throwing in 
different methods here is IMO not a good idea in a general forum, since it
tends to confuse the, I will say here, "not so frequently reading user".
This does not mean that the Linux method will not be examined carefully, but
it is much too early to decide which is the best method. The unmodified
current version is at least surely not the best.

>-Eric

Holger
-- 
|  |   / Dr. Holger Veit         | INTERNET: veit@du9ds3.fb9dv.uni-duisburg.de
|__|  /  University of Duisburg  |
|  | /   Dept. of Electr. Eng.   |          "Understand me correctly:
|  |/    Inst. f. Dataprocessing |     I'm NOT the WIZARD OF OS" (Holger)
From: andrew@werple.apana.org.au (Andrew Herbert)
Newsgroups: comp.unix.bsd
Subject: Re: Occasional system hangs
Date: 14 Dec 1992 12:52:54 +1100
Organization: werple public-access unix, Melbourne
NNTP-Posting-Host: werple.apana.org.au

Mark Tinguely <tinguely@plains.NoDak.edu> wrote:

> Did all of you with 16+ Megs of RAM apply the patch to restrict the size of
> bufpages (Terry Lambert's patchkit patch #2.

Yup.  I'm also currently using 4MB of kernel memory to avoid the kmem_map
exhaustion problems I was still getting even after applying the patch.  Works
well, despite being somewhat wasteful!  I've applied all the relevant beta
patchkit fixes (thanks Terry!), plus most (reasonable looking :) fixes posted
to comp.unix.bsd.  Plus a few from bde@runx.oz.au to prevent hangs and
panics in the pty and 387 handlers respectively.  And a fix for an ICMP
redirect problem that caused 3 out of the 6 panics that have occurred since
I installed ddb and started tracking them down about a week ago (just about
to post that one...).

> Besides, there are small memory leaks in the kernel; Programs that fork a lot,
> cause the system to hang (make and apparently news); Big programs like X

FYI, INN doesn't fork much at all.  It is big though - here is what ps -alxw
has to say about it:

  UID   PID  PPID CPU PRI NI   VSZ  RSS WCHAN  STAT TT       TIME COMMAND
  200    75     1   0  28  0  4828 2928 -      Rs   ??   13:43.31 in.innd -p4

Are these small memory leaks you mention pages being lost in the VM code, or
kernel malloc()/free() related?  Since Julian's fix for the raw socket problem
that was hogging malloc(x, MBUF) space when ping or traceroute were run, I
haven't noticed any significant malloc leaks.

> I agree that a kernel fix is better than a symptom avoidance technique.
> The kernel change is massive. The VM allows over extention of the swap
> backstore (and this can lead to the system freeze -- all of the swap
...
> are put on swap backstore, but backstore is full ... system will work the
> drive a little but will eventually freeze.

Thanks for the explanation - it clarified a number of things for me.

So would you agree that adding enough RAM to avoid paging/swapping most of
the time would help avoid this problem?

cheers,
Andrew
andrew@werple.apana.org.au, andrewh@cs.monash.edu.au
From: toepfer@du9ds4.fb9dv.uni-duisburg.de (Hansjoerg Toepfer)
Newsgroups: comp.unix.bsd
Subject: [386bsd] help: bad144 on second drive
Date: 18 Dec 92 09:48:35 GMT
Organization: Universitaet Duisburg GH
NNTP-Posting-Host: du9ds4.fb9dv.uni-duisburg.de

Hello,

I am running the norwegian (barsoom) wd driver on my two RLL drives.
I have problems in using bad144 for bad block handling.
When I do a "bad144 wd1 0" to initalize the bad block table on the
second drive I get a an error message which sounds like:
	label: Invalid argument
	can't write disklabel

I labled the second drive (Segate ST 277-1) with a big a: partition beginning
at cylinder 0 and leaving two cylinders left at the end.
I also tried the enhanced bad144 version posted some time ago (same results).
So, what am I doing wrong ?

Thanks for your attention,

Hanjo
--------------------------------------------------------------------------------
     __  __  _________  Hansjoerg Toepfer                Tel.: +49-203-3792583
    / / / / /__   ___/  University of Duisburg           FAX : +49-203-370439
   / /_/ /     / /      FB 9 / DV (Data Processing)
  / __  /     / /       Bismarckstr. 81
 / / / /     / /        D-4100 Duisburg 1, Germany
/_/ /_/     /_/         e-mail: toepfer@du9ds4.fb9dv.uni-duisburg.de
--------------------------------------------------------------------------------

Newsgroups: comp.unix.bsd,alt.suit.att-bsdi
From: bogstad@gauss.cs.jhu.edu (Bill Bogstad)
Subject: Re: AT&T/USL CD-ROM Review Process
Organization: Johns Hopkins Computer Science Department, Baltimore, MD
Date: Sun, 13 Dec 1992 18:32:40 GMT

In article <1992Dec13.165418.5021@sbcs.sunysb.edu> sayre@sbstaff2.cs.sunysb.edu (Johannes Sayre) writes:
>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.

	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.

				Bill Bogstad
From: boe@first.gmd.de (Bernd Oestmann)
Newsgroups: comp.unix.bsd
Subject: Re: 386BSD - Bug in UFS file system + proposed fix
Date: 17 Dec 92 18:42:21 GMT

hackney@moxie.hou.tx.us (Greg Hackney) writes:
>A very minor symptom is you can't read some LOCAL files, although
>there is public read permission, i.e. a file that looks like:

This is *not* a bug, it's a feature!

------------------------+-----------------------
Bernd Oestmann		| Mail:	boe@first.gmd.de
GMD-FIRST		| Tel:	+49 30 6704-5973
Rudower Chaussee 5	| Fax:	+49 30 6704-5610
D-1199 Berlin	 	|
Germany			|
Newsgroups: comp.unix.bsd
From: cgd@eden.CS.Berkeley.EDU (Chris G. Demetriou)
Newsgroups: comp.unix.bsd
Subject: Re: Dumb Question: Why 512 byte block?
Date: 19 Dec 92 00:07:39
Organization: Kernel Hackers 'r' Us
	<1992Dec18.030833.7395@fcom.cc.utah.edu> <1gt736INNjje@menudo.uh.edu>
	<1992Dec18.235623.27538@fcom.cc.utah.edu>
NNTP-Posting-Host: eden.cs.berkeley.edu
In-reply-to: terry@cs.weber.edu's message of 18 Dec 92 23:56:23 GMT

In article <1992Dec18.235623.27538@fcom.cc.utah.edu> terry@cs.weber.edu (A Wizard of Earth C) writes:
>>I did not think that Fast Unix File System works this way.
>>If you have 6 1.5K files using 1K blocks,
>>   6 1k blocks will take each 1K from each file, and 
>>   3 1k blocks will take 0.5k from each file.
>>This was my understading from the famous FUFS paper.
>
>You can't split blocks between files.  A block is, by definition, the
>smallest possible allocation unit.  Thin about the case where you have
>a 1 byte file and a 1 block - 1 byte file; what would you do when
>adding one or two characters to the first (1 Byte)?  TReallocate?  Shift
>and reallocate for the last byte of the second file?

sorry.  you guys *both* sound confused.  first of all, i've never
seen a FFS with 1k blocks; the most "standard" configuration
is 4k or 8k blocks, with 8 fragments.

this yields fragments of (obviously) 512bytes and 1k.

you can't split *fragments* between one file.
you *can* split blocks between one file, but this tends not to happen,
because the FFS doesn't do this unless it's necessary.

so:  if you have 6 1.5k files, and the following filesystem setups,
you get the following results:

8k blocks, 8frags/block:  6 blocks assigned, but major fragmentation...
			  (actually, only 12 frags are used.  if your
			  filesystem is near full, < 6 blocks will be
			  assigned).

			  total space "actually used": 12k

8k blocks, 4frags/block:  6 blocks assigned, but major fragmentation...
			  (actually, only 6 frags are used.  if your
			  filesystem is near full, < 6 blocks will be
			  assigned).

			  total space "actually used": 12k

4k blocks, 8frags/block:  6 blocks assigned, but major fragmentation...
			  (actually, only 18 frags are used.  if your
			  filesystem is near full, < 6 blocks will be
			  assigned).

			  total space "actually used": 9k

4k blocks, 4frags/block:  6 blocks assigned, fragmentation "not too bad"...
			  (actually, 12 frags are used.  if your
			  filesystem is near full, < 6 blocks will be
			  assigned).

			  total space "actually used": 12k



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