HDTenEightyP/NetNews huggingface dataset:
From: drew@ophelia.cs.colorado.edu (Drew Eckhardt)
Subject: Re: Adaptec & Swap space
Organization: University of Colorado at Boulder
Date: Thu, 16 Apr 1992 10:57:14 GMT

In article <29ED026F.19105@ics.uci.edu> bvickers@bonnie.ics.uci.edu (Brett J. Vickers) writes:
>I recently installed Linux 0.95c+, and I have been unable to set up
>swap space using either a separate partition or a swap file.  I'm
>using an Adaptec SCSI card and SCSI target 1 for my file system
>and the swap partition.  mkswap seems to work ok, but when I run swapon,
>I get the "Unable to find swap-space signature" error.
>
>Someone else who was using an Adaptec SCSI card posted that they
>were having similar problems, and this leads me to wonder if swap
>space and the Adaptec driver don't go together very well.
>
>Can anyone confirm my suspicions?

Obvious questions :

Are you using the SCSI kernel?  Stock .95c+ doesn't have the SCSI
support, the vmunix.Z from headrest.colorado.edu does.  You're 
a little hazy on this.

Do you have /dev entries for the SCSI disk(s)?  SCSI disks 
are major 8, minor where minor &0xf = partition #, 0
for the whole drive, minor >> 4 = disk number, starting at 
0, assigned dynamically in the order disks are found.

Statements  :
mkswap DOES NOT create a swap file.  It only writes the
swap signature, etc to a swap file or partition.
You have to use dd(1) to make a swap file.  

dd if=/dev/[hd sd as appropriate]0 bs=1024 count=[size in K] of=/swap

And then mkswap on that.

If you can read and write to the partitions, with something 
other than the mkswap program, it's a user problem.


Newsgroups: comp.os.linux
From: zhao@unixg.ubc.ca (Jiansheng Zhao)
Subject: can't compile selection/mouse driver
Organization: University of British Columbia, Vancouver, B.C., Canada
Date: Tue, 14 Apr 1992 22:42:40 GMT

I almost got everything work with linux0.95c+.
However, I still have trouble to compile selection to use a mouse.
gcc2.1 compiled new kernel all right. When compiling selection-1.0
I got the following error message:
stuff.c In function 'begsel' 
stuff.c:73: 'TIOCLINUX' undeclared
stuff.c:86 ... ... ...
Maybe there is a simple fix for trained eyes, but I have been pulling
my hair ,:).
Newsgroups: comp.os.linux
From: david@ods.com (David Engel)
Subject: Re: all kinds of questions
Organization: Optical Data Systems, Inc.
Date: Mon, 13 Apr 1992 20:51:38 GMT

cheetah@sage.cc.purdue.edu (Bowen Goletz) writes:
: Then more the tar.help file.  For some reason, stderr pipes aren't supported
: with bash.  You should be able to do a &| to pipe the output directly to
: more in the first place.

Actually, standard error pipes are supported by bash.  You just have to use
the traditional /bin/sh syntax like this:

	command1 2>&1 | command2

David
-- 
David Engel                        Optical Data Systems, Inc.
david@ods.com                      1101 E. Arapaho Road
(214) 234-6400                     Richardson, TX  75081
From: l00017@eeyore.stcloud.msus.edu (Networking Research)
Newsgroups: comp.os.linux
Subject: Re: Byte Unix Benchmarks.
Keywords: benchmark.tar.Z
Date: 8 Apr 92 10:38:27 GMT
Article-I.D.: msus1.1992Apr8.043830.347
Organization: Saint Cloud State University

In article <3249@inca.comlab.ox.ac.uk> jon@robots.ox.ac.uk (Jon Tombs) writes:
	[Info on the Byte Unix Benchmarks available for Linux]

	I though it might be interesting to compare numbers with that of
a different Unix running on the same hardware, so I ran the benchmarks on
my 486/33c running Mach386.

	[Sparc results deleted]

>486 33c [Linux]
>Arithmetic Test (type = double)               2541.7     1891.6        0.7
>Dhrystone 2 without register variables       22366.3    19281.7        0.9
>Execl Throughput Test                           16.5       89.2        5.4
>File Copy  (30 seconds)                        179.0       44.0        0.2
>Pipe-based Context Switching Test             1318.5     3738.0        2.8
>Shell scripts (8 concurrent)                     4.0        5.0        1.3
>                                                                 =========
>     SUM of  6 items                                                  11.3
>     AVERAGE                                                           1.9


486/33C	Running Mach386
Arithmetic Test (type = double)               2541.7     1968.8        0.8
Dhrystone 2 without register variables       22366.3    23723.6        1.1
Execl Throughput Test                           16.5      176.2       10.7
File Copy  (30 seconds)                        179.0      155.0        0.9
Pipe-based Context Switching Test             1318.5     1558.5        1.2
Shell scripts (8 concurrent)                     4.0        6.0        1.5
                                                                 =========
     SUM of  6 items                                                  16.2
     AVERAGE                                                           2.7

Looking at this, the results would seem to indicate that Mach386 is faster,
contradicting something I myself said earlier.  However, these factors can
be influenced by things like hard disk speed (maybe I have a faster one?),
caching, and such.  But the thing I have never liked about the Byte benchmarks
is that they're too susceptable to being skewed by one factor.  For instance,
the Execl throughput test in the above example throws the overall factor off
by a lot.

Something that I find telling is the Pipe based context switching, where Linux
is nearly 2 1/2 times faster than Mach 386.  I'm willing to bet this is why
Linux feels faster.

Anybody else out ther got a 486/33c running SCO ODT, or one of the SVR4s
(i.e. Dell, Esix), or 386BSD (Jolitz), or BSD/386, or . . . who'd be willing
to contribute numbers from those OS's?

-Mark Holden
l00017@eeyore.stcloud.msus.edu
From: zhao@unixg.ubc.ca (Jiansheng Zhao)
Subject: 0.95a --> 0.95c+: advantages?
Keywords: linux, 0.95c+, upgrade
Organization: University of British Columbia, Vancouver, B.C., Canada
Date: Sun, 12 Apr 1992 14:40:37 GMT

Newsgroups: comp.os.linux
From: drew@caesar.cs.colorado.edu (Drew Eckhardt)
Subject: Re: Has anyone thought about threads?
Organization: University of Colorado at Boulder
Date: Tue, 7 Apr 1992 08:06:18 GMT

In article <1200@lysator.liu.se> nicolai@lysator.liu.se (Nicolai Wadstr|m) writes:
>Has anyone given any thoughts on implementing threads in linux?
>I know it's not a standard UNIX feature, but it's were nice to
>write programs with threads, it's often possible to gain a lot
>of performance in using threads.
>(I've done a lot of OS/2 programming and just love the idea of 
>threads!)

fork()ing is the same thing as creating a heavy weight thread.
lightweight threads can be implemented with minimal modifications. 

Interprocess communication can be accomplished with pipes,
or signals.

Hopefully, sysV shared memory and semaphores will be 
implemented too.

>The shared libraray support (when implemented), will it be like
>OS/2 DLL's? I mean a .lib or .dll file that is loaded upon runtime
>of the program?
>

Yes.  Note that Linux uses shared, statically linked libraries.
With some header field munging, and running ld(1) from user space, it would
be possible to do dynamically linked shared libraries.

Xref: sparky comp.os.linux:206 comp.sys.ibm.pc.hardware:13312
From: pejn@cc.uow.edu.au (Paul Nulsen)
Subject: HD timeout under 0.95c+ - what is the problem?
Summary: Is the HD timeout error an indication of faulty hardware
Keywords: HD timeout 0.95c+
Organization: University Of Wollongong
Date: Mon, 13 Apr 92 03:08:41 GMT


My system is a 33 MHz 80486 using the AMI bios. It has 8 Mbyte memory and a
200 Mbyte Seagate IDE disk. The disk seems to be fine under DOS (before
making the changes listed below).

I have the problem that others have reported of HD timeout errors under
Linux - and using the 0.95c+ kernel does not seem to improve matters. The
problem is so bad on my system that Linux is unusable, so I can't even try
to investigate the cause.

I have tried: slowing down the AT bus (to CLKI/6, which I guess means about
5.5 MHz); adding a wait state to the AT bus cycle; slowing down processor
accesses to main memory (adding wait states) and slowing the processor
speed. Each of these things improve matters a little, but the problem
remains.

Does anybody know: 1) what exactly is the cause of the HD timeout problem;
2) whether it indicates that my drive or IDE controller are faulty?

I have asked this question before and got no response. I would be grateful
for any sort of answer because I need to sort this out before the warranty
on the machine expires.

Thanks
Paul Nulsen
pejn@wampyr.cc.uow.edu.au
Newsgroups: comp.os.linux
From: david@ods.com (David Engel)
Subject: Re: tar files on floppy.
Organization: Optical Data Systems, Inc.
Date: Tue, 14 Apr 1992 22:13:09 GMT

rdc30@nmrdc1.nmrdc.nnmc.navy.mil (LCDR Michael E. Dobson) writes:
: I am just about finished with linking everything in 2.1shared-A.tar.Z with
: shared libs and symlinking into /usr/bin.  A word of caution, DON'T use
: shared libs or symlinks on anything in /bin or /etc if / and /usr are on
: different partitions.  They won't work until /usr is mounted.  Keep a good
: bootimage floppy and root floppy handy just in case.

If you copy the shared lib to /lib instead of symlinking it (done by the 
install script) you can use shared binaries in /bin and /etc.  You can also 
safely remove /usr/shared the next time you upgrade libraries.  It's still 
a good idea to have "emergency" boot and root floppies handy however.

David
-- 
David Engel                        Optical Data Systems, Inc.
david@ods.com                      1101 E. Arapaho Road
(214) 234-6400                     Richardson, TX  75081
Xref: sparky comp.os.linux:288 alt.os.linux:2386
From: sweh@spuddy.uucp (Stephen Harris)
Newsgroups: comp.os.linux,alt.os.linux
Subject: Re: Large disk partition
Date: 9 Apr 92 15:47:26 GMT
Organization: Spuddy's Public Usenet Domain

In article <1992Apr8.122049.20594@klaava.Helsinki.FI> torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) writes:
>There are other fdisks than the linux or dos ones - pfdisk etc is

Obviously, I have pfdisk (from the 95a root disk), but I didn't think this
could create extended partitions.  I'll recheck though.  Thanks.

>Is everybody this surprised when one of my patches happen to work? :^)

Dunno about other people, but I was amazed that I had managed to put enough
stuff together in such a way that the patch procedure worked for me!
This is my first experience at beta testing, so everything I do correct is
amazing :-)  Dunno why people make so much fuss about problems compiling
the kernel with gcc 1.40 :-)
-- 
                               Stephen Harris
               sweh@spuddy.uucp    ...!uknet!axion!spuddy!sweh

 * Meeeeow ! Call Spud the Cat on > +44 203 638780 < for free Usenet access *
From: drew@caesar.cs.colorado.edu (Drew Eckhardt)
Newsgroups: comp.os.linux
Subject: Re: Problems with serial port drivers??
Date: 13 Apr 92 18:46:43 GMT
Article-I.D.: colorado.1992Apr13.184643.20236
Organization: University of Colorado at Boulder

In article <16739@plains.NoDak.edu> jnelson@plains.NoDak.edu (Jim Nelson) writes:
>In article <54335@hydra.gatech.EDU> gt0178a@prism.gatech.EDU (Jim Burns) writes:
>>in article <LILJEBER.92Apr11124027@kruuna.Helsinki.FI>, liljeber@kruuna.Helsinki.FI (Mika Pekka Liljeberg) says:
>>> using the same IRQ line simultaneously. Isn't it possible to poll all the
>>> UARTS on the IRQ line in the interrupt handler? Ie. you'd need a slightly
>>
>>You're not *supposed* to be able to do this. The ISA interrupts are level
>>triggered, which I believe means that after the ICU latches the first
>>interrupt, a 2nd one won't still be active after the first one is serviced.
>>You might try polling all devices on any interrupt, not just poll for the
>>*first* device that needs service. Don't know how successful that would be.
>>The MCA interrupts are level triggered, so this is not supposed to be a
>>problem there.
>

100% false with ISA.  ISA interrupts are edge triggered.  It has nothing
to do with the ICU not letting you have multiple interrupts.  The ISA 
IRQ lines are tristated, and if more than one is enabled at a time,
they short each other out.  Not as bad as it sounds, but it doesn't 
work.  

You are correct about MCA though - it uses level active IRQ lines,
and they are open collector. 
 
Newsgroups: comp.os.linux,alt.os.linux
From: joel@wam.umd.edu (Joel M. Hoffman)
Subject:  Remote dumb terminal loses char's with kermit
Organization: University of Maryland at College Park
Date: Sun, 12 Apr 1992 02:04:57 GMT

I just tried hooking up an old '286 I have to my Linux machine ('386 at
25MHz, 6M, 0.95c [b?]).  I hooked up the machines with Laplink cable, ran

	 getty 19200 /dev/ttys2 &

on Linux, and tried kermit on the remote machine.  But kermit kept
losing characters.  Even at 9600 I had problems.  And this is with a
null cable via two serial ports.  My only guess is that Linux isn't
watching for Xon/Xoff.  Is this possible?  Anyone have any other
suggestions??

-Joel
(joel@wam.umd.edu)

Newsgroups: comp.os.linux
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: Another bug?
Date: 10 Apr 92 20:39:16 GMT
Organization: University of Helsinki

In article <1992Apr9.200244.28901@wam.umd.edu> joel@wam.umd.edu (Joel M. Hoffman) writes:
>In article <1992Apr8.090321.7673@klaava.Helsinki.FI> torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) writes:
>>Well, only one known bug so far, but a couple of problems. I thought I'd
>>mention them before anyone else does, and we'll call them "features" :^)
>
>More than once, I've gotten a message about mis-linked processes.  I
>usually get it when I'm compiling from one VC and using Kermit
>interactively on another, but most of the time I'm compiling and using
>Kermit....

The mis-linked process problem seems to be linked with swapping: I've
never seen it, and most (all?) that have reported it have only 2M ram -
it seems to be a race-condition in the exit code, that breaks while
swapping heavily.  I think that running gcc and kermit on a 2M system
should be enough to swap quite a bit... 

I have fixed some of the exit-code in 0.95c+ - I'd be very interested to
hear if this problem is gone with the new kernel.  The exit-code was
"interesting" - I think tytso optimized the sibling linking a bit too
much, and it broke when paging meant that the kernel sleeps in some new
circumstances.  I might be totally off base - apologies to tytso if I
am. 

			Linus
Newsgroups: comp.os.linux
From: mper@uipsuxb.ps.uiuc.edu (Michael Pereckas)
Subject: Ghostscript
Summary: it works
Keywords: ghostscript port
Organization: University of Illinois at Urbana
Date: Wed, 15 Apr 1992 04:22:47 GMT

I have successfully compiled Ghostscript 2.4 with gcc 2.1.
It was a fairly easy compile.  A few things needet changing, but I
managed and I'm a lousy programmer and I don't know C.  My system was
to comment things out and hope for the best in most cases.  Anyway, it
seems to work, and I've printed actual documents on my Alps Allegro 24,
which is Epson compatible.  I have in the past had no success getting
the MS-DOS port to print anything but the included test files without
crashing with some scarry error messages, so I conclude the Linux is 
useful, for that alone, plus with Linux I can do other work while the
printer grinds away at a typical 10-15 min per page, which is the usual
speed for this printer in graphics mode, and not the fault of GS.

I'm not prepared to provide diffs for the GS sources now, and my binary
only supports the epson driver and uses shared libs, so I'm not going
to upload it.  I'm also not building another one, since it takes several
hours on my 2MByte system.  I will try to answer questions by e-mail,
however.

Thanks to all who made Linux possible!

Michael Pereckas

Newsgroups: comp.os.linux
From: chojnows@osiris (Brian Chojnowski)
Subject: Re: ESDI drives
Organization: University of Illinois at Urbana
Date: Thu, 16 Apr 1992 18:46:32 GMT

Duhh, I just assumed that since the doc didnt specify to mkdir /user, that
mount would. That solved the problem. Thank You.

	Brian Chojnowski
	chojnows@osiris.cso.uiuc.edu
From: etxlli@eos.ericsson.se (Lars Lindner)
Newsgroups: comp.os.linux
Subject: Summary: tar files on floppy.
Date: 15 Apr 92 11:15:54 GMT
Organization: Ericsson Telecom AB

Here's a summary of the answers a got to the question:

>>When I have both boot and root images installed on HD and i want to
>>install more SW downloaded as .tar.Z files, in what way will i get
>>them on a floppy to be able to install them on my linux machine?

Iain>The best solution is to use mtools but you need to be able to solve your
Iain>problem before you install mtools so here goes....
Iain>
Iain>On many archive sites (Dos) you will find tar programs for dos (as well ans
Iain>uncompress programs). The 2 I use are the Toad Hall shareware tar util and
Iain>u16.exe as an uncompressor. The uncompressor is not strictly necessary but it
Iain>helps.
Iain>
Iain>Get your .tar.Z files to dos. If you need to you should split them under Unix
Iain>(uncompress and make new tars) but if needbe you can do it under dos. Then,
Iain>take your dos tar utility and create a tar file containing your .tar.Z file.
Iain>Rawrite this new tar to a floppy and boot up linux. Once in Linux type
Iain>
Iain>tar xvf /dev/PS0 (for drive A).
Iain>
Iain>This should get you the .tar.Z file into Linux and it's att straightfoward
Iain>from there. I's strongly recommend that you get and install mtools if you are
Iain>using dos as well on the same machine.
Iain>
Iain>Iain

According to both Juergen Henke and Mike Dobson
you can also "rawrite" your .tar.Z files directly to the floppy
and use one of the folflowing lines to untar the file.

          tar xvZf /dev/PS0
   or     tar xvpz </dev/PS0





Thanks to all who have taken time to answer my question.


Lars Lindner

Lars.Lindner@eos.ericsson.se
Newsgroups: comp.os.linux
From: ulan@ee.ualberta.ca (Dale Ulan)
Subject: re: compiling kernel .95c+
Reply-To: ulan@ee.ualberta.ca (Dale Ulan)
Organization: University of Alberta Electrical Engineering
Date: Sat, 11 Apr 1992 15:34:42 GMT


Compiling the kernel with GCC1.40 does not seem to work any more.

Yesterday, I wrote about problems with compilation of 0.95c+ 
under GCC1.40.

Last night I switched to GCC2.1, and the kernel compiled fine
(just very slowly... I've only got 2 meg of RAM).
The only problem I had was with the include files from /usr/include
for build.c
I ended up commenting out a whole bunch of lines from stdlib.h,
starting with mblen and ending with wcstombs.
(parse errors in that area).  (at 3am it's easier than trying to
fix the include files :-) )

In any case, it now works, so perhaps the GCC1.40 provision could 
be taken out of the makefile...

I tried reading the kernel code, but I guess I'm not much of a kernel
hacker, what I was wondering was about the 'mismatched parent link'
and the 'os' and 'ys' warnings.... and why they happen.... or am I
the only one that gets those?

----
Dale Ulan    ulan@ee.ualberta.ca

Xref: sparky comp.os.linux:550 alt.os.linux:2571
From: dingbat@diku.dk (Niels Skov Olsen)
Newsgroups: comp.os.linux,alt.os.linux
Subject: Re: Keyboard dies when I hit Caps-Lock (+SCSI)
Date: 16 Apr 92 21:05:20 GMT
Organization: Department of Computer Science, U of Copenhagen

joel@wam.umd.edu (Joel M. Hoffman) writes:

>In article <1992Apr13.224913.15109@odin.diku.dk> dingbat@diku.dk (Niels Skov Olsen) writes:
>>drew@caesar.cs.colorado.edu (Drew Eckhardt) writes:
>>
>>[My keyboard locks up when Caps-Lock is hit both in scsi-version
>>at sc.tamu.edu (DK and US keyb.) and in the scsi0.95c+ version at
>>headrest.woz.coloradu.edu.]
>>
>>[scsi devices now use major 8]
>>
>>>The keyboard : 
>>
>>>Does the keyboard lock up, period, do numlock, CAD still work,
>>>or not?
>>
>>Ok I checked it more thoroughly.
>>
>>Following keys gives TOTAL lock up but with Linux stil running:
>>	Pause
>>	Scroll Lock (gives a task-info)
>>	Caps Lock
>>	Num Lock

>Are you sure the keyboard is locked up?  On my system, many of those
>keys provide a ``hidden feature.''  They convert everything into
>control sequences until Linux is rebooted.  So, `a' becomes C-a (which
>looks invisible), `c' becomes C-c, etc.  BTW, you can still logout, as
>`d' become C-d, and if you have a ``sync'' in your history (bash), you
>can use `p' (which becomes C-p) to retrieve it.

Yes I am sure. I have just tried and I have no alternative but to
hit the reset button. And then right after such a lock up the 
escape button will not make the AMI bios skip memory test. This
indicates to me that perhaps the keyboard IRQ is being masked when
servicing keypresses and that the ICU's are not restored properly. I
have not yet had the time to aquire kernel insight, so I am on very
thin ice here.

BTW, I had a report from Australia about a similar problem.

Niels
From: duty@ariel.ucs.unimelb.edu.au (Duty Programmer)
Newsgroups: comp.os.linux
Subject: Re: Linux Drivers and Kernel question.
Date: 7 Apr 92 00:04:33 GMT
Reply-To: rab@tauon.ph.unimelb.EDU.AU
Organization: School of Physics, University of Melbourne

In article <hapj04k@lynx.unm.edu>, techs@triton.unm.edu (Erik Fichtner) writes:
|> *someone* out there with enough space to produce one good working binary.. 
|> X isn't something you need to have the source online for, IMHO... once it's 
|> working, leave it alone..  (No, i'm obviously not an X junkie.. i just need
|> xv and some other graphics manipulation tools and that's it. virtual consoles
|> are faster than point-and-click)  
|>  

Yes, but there's just no substitute to having everything visible on the screen
at the same time. Certainly there is no need for people to compile X individually.

What I've been wondering is this: I suspect many of us would love to have X running
on isolated PCs: is it possible to cut out all the X networking stuff ? Would this
reduce the size of the server by very much ? Then we could have 2 X binaries to ftp ...

rab
-- 
------------------------------------------------------------------------
Richard Brown                     | E-mail: rab@tauon.ph.unimelb.EDU.AU
School of Physics                 | Phone : +61 3 344 5081
University of Melbourne           | Fax   : +61 3 347 4783
Parkville Victoria AUSTRALIA 3052 | Telex : AA35185