HDTenEightyP/NetNews huggingface dataset:
From: wilker@hopf.math.purdue.edu (Clarence Wilkerson)
Newsgroups: comp.os.linux
Subject: Re: SLS is awesome and getting larger
Date: 26 Aug 92 16:50:46 GMT
Organization: Purdue University

1) I don't think the DAK drive is still available. My order was
    backkordered from May to August and then DAK cancelled it.
2) I think the really cheap ( less than $200 ) drives are closeouts
and surplus older models.

-- 
Clarence Wilkerson      \ Bitnet:       wilker%math.purdue.edu@purccvm
Prof. of Math. (topology)\ Internet:    wilker@math.purdue.edu
Dept. of Mathematics      \ messages:   (317) 494-1903, FAX 494-0548
Purdue University,         \ office:    (317) 494-1955 (voice/modem)
W. Lafayette, Indiana 47907 \ 
Newsgroups: comp.os.linux
From: zwerin@tortoise.cis.ohio-state.edu (Andrew Zwerin)
Subject: Applying patches
Organization: The Ohio State University Dept. of Computer and Info. Science
Date: Sun, 30 Aug 1992 23:06:11 GMT

I am having trouble patching the 0.97 kernel source code with the
0.97.patch1

The kernel source is in /usr/src/linux and the patch is in /usr/src.

Can someone tell me exactly how to apply the patch?  By the way is
there more then on version of patch?

thanks,
andy
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: Benchmarking under Linux (was Re: New 486 Suggestions?
Date: 4 Sep 92 10:07:06 GMT
Organization: University of Helsinki

In article <1992Aug31.210041.21832@novell.com> bboerner@novell.com (Brendan B. Boerner) writes:
>
>This has me wondering: does anyone have any benchmarking or performance
>metric programs for Linux?  I've got a 386/16Mhz w/a tad under 5MB of
>RAM and it takes me somewhere between 3-4hours to build the kernel.  On
>my girlfriend's machine, a 486/33 w/8MB RAM, it takes under 10
>minutes.  I'd like to get an idea of where I could improve
>performance.

RAM space is the first thing to look for: gcc eats memory like mad, and
swapping is slow especially with the older kernels.  I hope my changes
to the swap-algorithms in 0.97.pl3 will help people with slow machines:
it does seem to help even on my 8MB machine (kernel compilation time
when running X+some xterms fell from 18 minutes to 15).  The main change
was to use a page-used counter instead of just a swp bitmap, which
allows fork() to be speeded up /a lot/ when swapping. 

But processor speed can be very important under linux: not just for the
obvious user-level speedup, but due to better response to disk-drive
interrupts and the like.  Faster machines may simply read the disk at
the full 1:1 interleave - with slower systems, it's possible that the HD
driver doesn't keep up, and you get the dreaded 1-block/rotation
syndrome, which really hurts when swapping.  This problem is probably
especially notable on 386SX machines: the 386 interrupt handling is
inherently slow, but if the memory badwidth is further reduced by the
16-bit bus, interrupt response is probably ever worse.

		Linus
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: 0.97p2
Date: 28 Aug 92 23:05:26 GMT
Organization: University of Helsinki

In article <1992Aug28.123817.20350@csd.uch.gr> kermits@pasifae.cc.uch.gr (Aggelos Keromyths) writes:
>I just tried 0.97p2 from the disk drive and it seemed to me a lot
> slower than 0.97 (no patch at all!!!)....When i did an `ls` it
> started reading the drive,then stopped,then again reading and finally
> presented the directory...but it was SLOW....
>What could be the problem ?

Hmm.  I'd like to hear more about the problem - especially if you can
pinpoint it more closely (ie having used 0.97, 0.97.pl1 and now pl2) to
a specific patch.  As most people said 0.97.pl1 was fast, I'm assuming
it's specific to patch2, but I'd like to have some confirmation before I
start looking into the problem. 

If it's patch2, the problem is probably the changed mm code: having
different page tables for each process might be costlier than I thought. 
The old (pre-0.97.pl2) mm was very simple and efficient - TLB flushes
happened reasonably seldom.  With the new mm, the TLB gets flushed at
every task-switch (not due to any explicit flushing code, but just
because that's how the 386 does things when tasks have different cr3's). 

I can optimize things a bit - it's reasonably easy to fake away some of
the TLB flushes by simply forcing the idle task to always use the same
cr3 as the last task did (as the idle task runs only in kernel memory,
and kernel memory is the same for all processes).  So, I'd be interested
to hear if this simple patch speeds linux up at all:

 - in linux/kernel/sched.c: schedule() - change

	cli();
	switch_to(next);

   to

	cli();
+ 	if (!next)
+ 		task[0]->tss.cr3 = current->tss.cr3
	switch_to(next);

   ie just add the one if-statement.

If the above makes a difference, I'd like to hear it, and I'll put it in
the standard kernel.

I'd also like to know what kind of machines the slowdown is most
noticeable on: assuming it's the mm changes I'd guess it's non-cached
machines (possibly SX-machines) for which a TLB flush will result in a
noticeable performance-loss.  So if you notice a slowdown, please mail
me that kind of info as well. 

		Linus
Newsgroups: comp.os.linux
From: arumble@extro.ucc.su.OZ.AU (Anthony Rumble)
Subject: Re: Dialups: Locking DTE speed and Carrier Loss ???
Organization: Sydney University Computing Service, Sydney, NSW, Australia
Date: Thu, 3 Sep 1992 00:02:20 GMT

guest@chopin.Physics.McGill.CA (Muhep Guest account) writes:

>James L. Paul writes
>> I'm using 0.97.1 and GCC 2.2.2 with uugetty from the getty_ps package.
>> 
>[ ... ]
>> Now on to more Linux-specific... With the original getty (from the root
>> image) a carrier loss situation gets handled properly. I.E., the 
>> processes
>> get killed and getty is respawned. This getty does not handle multiple
>> connect speeds as well, and does not have a uugetty option, so I'm no
>> longer using it, in favor of uugetty as I said above. BUT...
>> 
>> Now when carrier is lost without logging out, the processes no longer
>> get killed. Yes, I have the -HUPCL in all the /etc/gettydefs entries.
>                              ^^^^^^

>If this is not a typo, that's your problem.  Using -HUPCL turns *OFF*  
>sending SIGHUP on close.  Take out the minus sign.  (Or use SANE, which
>includes HUPCL).

I am running my own Modem Server (Very similar to uugetty)..

ANd I have been having a range of problems.. 
One being that people calling with MNP modems (I don't have a MNP modem)
when the MNP modem sends its MNP init sequence it locks up the port
and the Modem Server Exits... Does anyone have the exact string..
Or an idea of what is sent from the Originating modem in the MNP
init sequence?? There might be something like a Ctl-D.. Altho
this should not affect the server..

More of a concern, is the fact that sometimes when people drop carrier
it exits, and sometimes it doesn't.. (Yes HUPCL is set) I cannot
work out why it doesn't..

What I have decided to do, is make the modem server fork to the login
and check the line CD every minute or something and send a SIGTERM or
SIGHUP to the forked process if CD is lost..

(Could also implement time limits this way..)

-- 
Anthony Rumble
aka SmilieZ
"Anything is possible.. If there is enuf money in it"
Newsgroups: comp.os.linux
From: healyzh@iat.holonet.net (Zane H. Healy)
Subject: Major Device number for Sound Blaster
Organization: HoloNet (BBS: 510-704-1058)
Date: Sat, 29 Aug 1992 19:59:47 GMT

I have applied the patches for SoundBlaster support and as far as I can
tell it work's, BUT I need the MajorDevice number.  The doc'sonly seem to
give the minor device numbers.  Also is it block or character?

      Thanks,
           Zane

Newsgroups: comp.os.linux
From: congo@nork.auc.dk (Kenneth Wellin)
Newsgroups: comp.os.linux
Subject: Numbers for pboot.exe (SCSI) (/dev/sdb1 etc.)
Date: 1 Sep 92 21:20:50 GMT
Distribution: comp
Organization: NKEDBBF Micro-systems



I am installing Linux on my 386 with to Seagate 157N SCSI hard drives.
I have looked in several docs without getting the information i was 
searching.
I need to know what the dev. numbers is for the SCSI drives.
I have know the numbers for IDE-drives, but not for SCSI.
The numbers i need is the numbers used to modifie the bootdisk, so that 
it looks for root on the SCSI drive.(Ie. the numbers uesd in the program
PBOOT.EXE.)
I am installing Linux on my second SCSI drive, on the 3. partition.
(That is /dev/sdb3.)

I do hope that someone can tell me what to do!

Friendlist,

Nyrup.






--
--------------------------------------------------------------------
Kenneth Wellin                 email: 
Sigrid Undsetsvej 246B               At university:  kkw@iesd.auc.dk
DK-9220 Aalborg                      At home:  congo@nork.auc.dk
Denmark
                               
Phone: +45 98151805



     Don't do today OR tomorrow, what you can avoid ever doing
Newsgroups: comp.os.linux
From: data@cs1.bradley.edu (Mark Hall)
Subject: Re: Minimum requirements for linux - just to run single user
Keywords: Minimum requirements
Organization: Digilog Technologies : Music/Midi software that works for you.
Date:  2 Sep 92 10:15:38 GMT

In <1992Sep1.135811@tiger1.prime.com> cummings@tiger1.prime.com (Kevin J. Cummings) writes:

>Er, Ah, is it a SigmaSigma step chip?  or does it have the infamous task switching
>bug in it?  If its a REALLY old 386, you may not be able to use it.

I am not aware of a task switching bug...:)  I've run Desqview with no
problems.  I just don't like it. :)  SigmaSigma step chip?  I am not familiar
with that.

>> ram.  (Ok...You can stop laughing now... :)  Should I assume that ...
>Whose laughing?  My Dad has my old 16MHz 386 DX with 1MB of RAM.  640K conventional
>and 384K extended?  Do you have ANY extended memory?  Or is it configured as
>BIOS shadow RAM?

No.  I have NO extended.  Just conventional 640 K.  Really sucks.

>> Linux?  I'm hoping to be able to upgrade to at least 2 megs sometime, but am
>In order to upgrade a 1MB 386 to 2MB, you have to be able to add in 4 banks of
>256K memory.  386 memory must be 32 bits wide unless you have an SX system,
>in which case it must be 16 bits wide.  Since most memory banks are 8 bits wide,
>you either need space for another 4 banks on your motherboard or on a 32bit
>memory card.  If you only have space for 4 memory banks, then you will need
>to upgrade them from 256K chips to 1M chips, increasing your memory from 1MB to
>4MB.

Not sure what my chips are.  I'll probably just buy a 32bit expansion card.
There's no room on the motherboard for expansion (my motherboard is just a
bus) and the memory is a card...Stupid...Same for Processors, and I/O stuff.

>> 	D*mn. Mem swap error (or something like that).

>Sounds like 1MB is too little memory.  I have heard of people running in 2MB

Yeah...I found out in the FAQ (somebody was nice enough to mail it to me...:)
Thanks! that it requires 2M just to boot.  ALso, several people have made
suggestions on the amount of memory and HD space to make available to linux.
I've got a rough idea of the system I need to do that...:)

>on 386SX processors.  Just be sure to configure a swap partition (4-8MB) to
>get you running.  As long as there is sufficient memory to run the kernel in,
>swap space will look like paged virtual memory to your system, and it will
>manage it for you.  I have 4MB ram, and 10MB swap.  I haven't run out of memory
>yet.  I suspect you could run with 2M ram and 4 MB swap, but it would be slow.
>(Lots of disk accesses I suspect.)

Probably.  Couldn't be worse than on our AT&T 3b2 (ugh! :)

Mark
--
---
	Looking for a good time?  Like to work with a variety of shows?
		join ACBU Tech:  We work sound and lights for *ALL*
			occasions.  Call x3063 for details.

-----  Mark Hall  -----  data@bucs1.bradley.edu  ----- 1:232/28  1:2250/9 -----
From: caitlin@milton.u.washington.edu (Caitlin  Mitchell)
Newsgroups: comp.os.linux
Subject: Clocks.exe
Date: 25 Aug 92 23:53:44 GMT
Article-I.D.: u.1992Aug25.235344.21003
Organization: University of Washington, Seattle

Where can I find clocks.exe so I can figure out what the clocks on my
video card are?

Thanks, 

Caitlin
From: ujlh@pool.info.sunyit.edu (James Henrickson)
Newsgroups: comp.os.linux
Subject: Re: ATI graphics ULTRA? Will it work?
Date: 2 Sep 92 17:37:59 GMT
Organization: State University of New York -- Institute of Technology

In article <dhirvela.715290013@icaen.uiowa.edu> dhirvela@icaen.uiowa.edu (Dave Hirvela) writes:
>djr48312@uxa.cso.uiuc.edu (X X) writes:
>
>>WIll the ATi graphics ULTRA work with linux?  Any onr know if the mosue
>>will work?  Is the card compatible with Xwindows?
>
>
>Yes, it sure will, I'm using it right now.  To run x you need the 8514/a
>x server (at least I think you do, I'm still working on getting the binaries
>on my system) and then you can use the accellerated modes.
>
>Get the file Xlinux8514.T.Z, it's on the major site, got mine from the
>finland site...

I have repeatedly seen people asking about particular ATI cards.  The problem
is that ATI has so many different models!  Perhaps we should add a list of
ATI cards to the X FAQ showing which particular models DO work?  Diamond is
starting to get confusing, also, since they are using non-ET4000 chips on
some of their cards and even some of the Diamond ET4000 cards aren't working
with X.

Please don't send me mail about this, I have a video card that works with
X.  It is a Diamond SpeedStar, just a plain old pre-highcolor SpeedStar
but it isn't the SpeedStar Plus, either.  (See what I mean about confusing?)


-- 
Jim H.
*
* James L. Henrickson
* ujlh@sunyit.edu        "Some day I might have a real .signature!"
From: zlsiial@uts.mcc.ac.uk (A. V. Le Blanc)
Newsgroups: comp.os.linux
Subject: Re: Using patch
Date: 29 Aug 92 12:41:14 GMT
Reply-To: LeBlanc@mcc.ac.uk (A. V. LeBlanc)
Organization: Computing Centre, University of Manchester

In article <1992Aug29.032618.21762@athena.mit.edu> hammond@kwhpc.caseng.com (Kevin W. Hammond) writes:
>I applied patch 1 to 0.97 this morning, but had to manually answer Yes to each
>file it desired to patch.  Is there a way for patch to do this automatically?
>
>The command I used was:
>
>	patch < patch1
>
>I was in the /usr/src/linux directory.

Go to the /usr/src directory and type

      patch -c -p0 <patch1

(assuming patch1 is in /usr/src instead of /usr/src/linux).  This means
'run patch to apply context diffs, regarding all of the given pathnames
as significant, using patch1 as input'.

Alternatively, go to the /usr/src/linux directory and type

     patch -c -p1 <patch1

(assuming patch1 is in /usr/src/linux).  This means 'run patch to apply
context diffs, regarding all of the given pathnames as significant
except for one element, using patch1 as input'.

If you haven't installed from the MCC interim version of Linux, the
man pages are available (unformatted) in mcc-interim/0.97p2/source_files
in the file manpages.tar.Z.  These include the man page for patch.

     -- Owen
     LeBlanc@mcc.ac.uk
Newsgroups: comp.os.linux
From: "Carl M. Fongheiser" <RAILCUB@delphi.com>
Subject: Future Domain 1670 support?
Reply-To: RAILCUB@delphi.com
Organization: The Internet
Date: Wed, 2 Sep 1992 00:45:25 GMT

Is the Future Domain 1670 SCSI controller supported by the 0.97 boot image?
Previous messages have led me to believe so (so I ordered one!), but perusal
of fdomain.c from the 0.97 source leads me to believe otherwise, because
USE_FIFO is set to 1, and the 1670 doesn't have the FIFO.  I'd like to know
before I start making major changes to my system configuration, not to mention
being able to send it back before I start playing with jumpers, etc.

				Thanks!
				Carl Fongheiser
				railcub@delphi.com
				c.fongheiser@genie.geis.com
Newsgroups: comp.os.linux
From: balasub@organ.cis.ohio-state.edu (Krishna Balasubramanian)
Subject: Re: questions: vi problem, make dep, filenames, libraries
Originator: balasub@organ.cis.ohio-state.edu
Keywords: GCC
Organization: Ohio State Computer Science
Date: Fri, 4 Sep 1992 16:18:34 GMT


	First, my vi is not working. I get the following error message.
	"This termcap entry lacks the :up=: capability"
	I imagine this is just an initializtion problem. What do I need to change?

The vi problem is termcap related ... you may have an old
vi binary or an old /etc/termcap. You should get the termcap
from the latest root disk.

	Second, I finished the GCC install script and it told me to do
	a make dep with the kernel Makefile. What does make dep mean? Will
	this recompile the kernel for me? How do I implement the patches in this?

go to /usr/src/linux or whatever and do
make dep
or is it make depend?
This will add lines to the bottom of every Makefile on how the source
files depend on varios header etc. You can then edit config.h and then
type make to build the kernel.
To apply patches you need a program called patch. read the man page
for patch on any unix system.

	Next, what are the limitations on filename lengths and is there a way
	to change it????

The standard linux/minix fs suppors 14char file names. You can get 
efsprog.tar.Z and make yourself an extended file system if you like longer names.
The short names is not a problem unless you have file names which
begin with the same 14 characters or programs like compress which look
for a specific .Z extension at the end. GNU tar for example does not care.

	Finally, after installing GCC I have all these libraries laying
	around. Which ones do I need? It seems that /lib and /usr/lib are the
	same. What is the deal?? 
	Also, do I also have g++ now??? There is a g++-include directory.

/lib contains shared images ... files that are loaded by all the
binaries compiled with shared libraries. These binaries will not 
run without these files. You can use ldd to determine what
shared libraries a binary depends on.

You can find out the gcc standard library search patch by compiling
hello.c with the -v switch. 
gcc -v hello.c.
Also try gcc -v -jump hello.c, gcc -v -static hello.c, gcc -V 2.1 -v hello.c
Some of these may give informative errors.

The gcc static libraries and debugging/profiling libraries live
in /usr/lib/gcc-lib/i386-linux/$version/.
The gcc shared libs live in the `shared` subdirectory of this,
and the jump table versions live in the `jump` subdirectory.

You have a working g++ in /usr/bin.

Read gcc.1 gcc.ps.
Also available from standard gnu gcc archive sites are the
info files for binutils, gcc, libg++, gas, make etc ....
Read these rather than rely on hokey sources like me.

krishna


Newsgroups: comp.os.linux
From: ede@kadabra.osf.org (Ted Ede)
Subject: scsi disk partitioning and bootstrap questions
Organization: Open Software Foundation
Date: Fri, 28 Aug 1992 20:32:37 GMT


A couple of questions:

1) fdisk 'x'pert mode disks allows up to 63 sectors per track.  some
larger disks ( > 1GB) have more than 63 sectors per track.  Is this
limit hard or can it be changed?

2) I'd like to use shoelace or lilo.  when I partition my disk I took
the first 8 cyls for root and the next 12 for swap.

when I print the partition table it looks like
		Boot	Begin 	Start	End	Blocks	Type
/dev/sd1a		2	2	16800	8399	MINIX/fs
/dev/sd1b		1	16801	42000	12600	MINIX/swap

I assume the the 'Begin' of 2 for /dev/sd1a is skipping the boot
block?  I'm also guessing that I can't use this partition for lilo or
shoelace?  Can I just make the root partition something other than the
first partition, e.g. exchange root and swap and then use lilo?  Or must
I leave one cylinder at the beginning of the disk empty and start root
at the second cylinder.  As this disk is not my boot disk, do I need
a boot block at all?

3)  Which should I use, Lilo or Shoelace?  Why?  Will either
get me a faster boot than using autocon and bootlin?


I don't think any of these are in the FAQ.  But I may have missed something.
Does anyone else have problems finding things in the FAQ?  It would be
nice if the FAQ questions were numbered and a list of them were placed
at the front of the FAQ.

As not to whine without offering help,  I'd be happy to help organize the
FAQ if desired.

cheers,
ted
Newsgroups: comp.os.linux
From: minyard@crchh453.bnr.ca (Corey Minyard)
Subject: Problems with domain sockets in porting lpr
Keywords: domain sockets, linux
Reply-To: minyard@bnr.ca
Organization: BNR
Date: Thu, 27 Aug 1992 16:59:12 GMT

I have ported plp (a public lpr spooling package) to linux but I have
experienced a problem with domain sockets.  If I do the following:

   struct sockaddr_un   saddr;
   int                  s;

   s = socket(AF_UNIX, SOCK_STREAM, 0);
   if (s < 0)
   {
      error
   }
   else
   {
      saddr.sun_family = AF_UNIX;
      strcpy(saddr.sun_path, filename);
      
      if (bind(s, &saddr, sizeof(saddr)) < 0)
      {
         error...

The bind will fail.  I turned on socket debugging and found it was getting
an invalid length.  It turns out if you pass "sizeof(saddr)" to bind
(or connect) if fails.  I looked in the kernel, and that is what it was
coded to do.

Is this behavior correct?  I changed the size to be 

   sizeof(saddr.sun_family) + strlen(filename)

and it worked just fine.  The documentation I have on domain sockets
mentions nothing about this.

----------------------------------------------------------------------

Corey Minyard
minyard@bnr.ca
From: davidsen@ariel.crd.GE.COM (william E Davidsen)
Newsgroups: comp.os.linux
Subject: Re: 16550A
Date: 27 Aug 92 14:08:13 GMT
Reply-To: davidsen@crd.ge.com (bill davidsen)
Organization: GE Corporate R&D Center, Schenectady NY

In article <1992Aug25.215550.26919@athena.mit.edu>, tytso@ATHENA.MIT.EDU (Theodore Ts'o) writes:

| If it's the problem I think it is, it would seem to me to be awfully
| non-robust of DOS not to be able to deal with a 16550A that has had FIFO
| enabled.  You'd either MS-DOS or the BIOS would send the FIFO disable
| sequence to a UART before trying to use it.

  I suspect it is. I'm not even sure DOS shuts off the interrupts, which
could cause other problems.

-- 
bill davidsen, GE Corp. R&D Center; Box 8; Schenectady NY 12345
    I admit that when I was in school I wrote COBOL. But I didn't compile.
From: lm@slovax.Eng.Sun.COM (Larry McVoy)
Newsgroups: comp.os.linux
Subject: Re: GNU kids on the block?   (sorry... couldn't resist)
Date: 26 Aug 1992 09:03:55 GMT
Organization: Sun Microsystems, Inc.  Mt. View, Ca.
NNTP-Posting-Host: slovax

sef@kithrup.COM (Sean Eric Fagan) writes:
: There are a lot of people who do not want or need the complexity that comes
: with a multi-server.

Count me among them.  Micro kernels are a crock.  OS technology should be
simple and small, all the fun stuff is happening in user land these days.
---
Larry McVoy			(415) 336-7627			 lm@sun.com
Newsgroups: comp.os.linux