HDTenEightyP/NetNews huggingface dataset:
From: jsp@math.ksu.edu (Jeff S. Pihl)
Newsgroups: comp.os.linux
Subject: Re: Why does scrolling sometimes mess up?
Date: 18 Aug 1992 04:57:22 -0500
Organization: Dept. of Mathematics, Kansas State University
NNTP-Posting-Host: hilbert.math.ksu.edu

rghuehn@sunee.uwaterloo.ca (Rob Huehn) writes:

>I have a problem with scrolling on the console screens that occasionally
>occurs after exiting from elvis.
>When it happens, only the bottom line of the screen gets updated, and
>blank lines get scrolled up the rest of the screen.

I have had the same problem.  Mine occurs after I use kermit and log on
to another machine and have it set the terminal type to vt100.  Kermit
does this just fine but vt100 only has 24 lines and the local terminal
information gets tweaked slightly.  The console window will scroll properly
using only 24 lines.  The problem is when you exit elvis, you get put on
the 25'th line and the scrolling goes to "&(*#%$@!".
Rebooting "fixes" the problem but I've found another approach.  If you
load emacs with a file longer than 25 lines and ^n past the end of
the file, when you exit emacs the terminal will behave properly.
Why??? I don't know.   Hope this helps.
-- 
jsp@hilbert.math.ksu.edu

"One stroke of genius is worth more than a lifetime of uninspired drudgery"
-- A.H.
From: steve@Nyongwa.CAM.ORG (Steve M. Robbins)
Newsgroups: comp.os.linux
Subject: Re: Why GNU cp is flakey under Linux
Date: 18 Aug 92 15:49:29 GMT
Organization: Chiral Symmetry Breakers of Montreal

In article <JRS.92Aug12190300@lepton.world.std.com> jrs@world.std.com (Rick Sladkey) writes:
>>>>>> On Wed, 12 Aug 1992 06:35:34 GMT, jwinstea@jarthur.claremont.edu
>>>>>> (Jim Winstead Jr.) said:
>
>Jim> Not necessarily true - GNU cp contains the optimization that it will
>Jim> use lseek() to 'write' holes in a file instead of writing out all the
>Jim> individual null bits.  This is what causes shoelace to break for some
>Jim> people.  I'm not sure what effect this has on copying to a floppy with
>Jim> the cp command - but I *know* dd is safe.
>
>An examination of the source code shows that GNU cp only performs this
>optimization if it thinks that the original file also had holes.  The
>way GNU cp determines this is by comparing the number of blocks used
>with the actual file size.  Furthermore, it only does this when it is
>compiled without ST_BLOCKS_MISSING defined.  Note that the kernel is
>created by build and does not have any holes.
>
>So if your cp is creating holes ROUTINELY then:
>
>* fstat is broken and returns incorrect values for st_blocks, or
>* you manually defined an incorrect value of DEV_BSIZE (i.e. too small)

I ran into this the other day, trying to recompile gnu's cp.  I don't have
DEV_BSIZE defined anywhere (it's quite possible I've goofed my /usr/include)
so I just defined it to be 1024.  

Looking at the code, though, I decided that it wouldn't make any difference 
what I did, because DEV_BSIZE is only used to guess if holes should be 
attempted, the actual holes are made using lseek().  Making it too large would
mean it would sometimes miss the chance to make holes, and making it too small
would mean it would make holes where none existed.  No harm either way that
I could see.   [except for shoelace apparently]

From the reply Linus made, it seems that the most proper thing to do would
be to replace DEV_BSIZE with sb.st_blocksize in cp.c, right?

>Here is the relevant code from GNU cp.c:
>
>+-----
>| #ifndef ST_BLOCKS_MISSING
>|   if (S_ISREG (sb.st_mode))
>|     {
>|       /* Find out whether the file contains any sparse blocks. */
>|
>|       if (fstat (source_desc, &sb))
>| 	  {
>| 	    error (0, errno, "%s", src_path);
>| 	    return_val = -1;
>| 	    goto ret;
>| 	  }
>|
>|      /* If the file has fewer blocks than would normally
>| 	  be needed for a file of its size, then
>| 	  at least one of the blocks in the file is a hole. */
>|         if (S_ISREG (sb.st_mode) &&
>| 	    sb.st_size - (sb.st_blocks * DEV_BSIZE) >= DEV_BSIZE)
>| 	  make_holes = 1;
>|     }
>| #endif
>+-----
>--
>Rick Sladkey
>jrs@world.std.com
-- 
Steve Robbins  --  steve@nyongwa.cam.org
The World is rather sick and twisted.  Why should I be any different?
Newsgroups: comp.os.linux
From: tm@netcom.com (Toshiyasu Morita)
Subject: Re: AMD386 vs. Intel386 & external cache problems
Date: Thu, 13 Aug 92 07:00:27 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Keywords: AMD 386 Intel cache

I've had an AMD 386/40 since August of last year, and initially I had really
bad problems with my system. After I put a surge suppressor on the system
the system crashes disappeared. I have no idea why an AMD386/40 would
be more susceptible to power transients but I think that was the problem.

The sympton I was having was non-Linux: my system would lock up inadvertently
in the middle of (usually) modeming sessions, with the the keyboard totally
dead. The only thing that would restart the system was a hard reset.

I run Linux on my system now without any problems whatsoever, and I do 
use it quite heavily sometimes - sometimes I'll run two huge gcc compiles
while I'm modeming.

Toshi Morita
From: gt0449a@prism.gatech.EDU (Rob Coleman)
Newsgroups: comp.os.linux
Subject: 16550A
Date: 23 Aug 92 16:31:10 GMT
Organization: Georgia Institute of Technology

Does anyone else have problems with Linux not correctly "shutting down"
the 16550?  Ever since the kernel has supported a 16550, I have had to
hard reset the computer after running linux, or it seems that the
computer "forgets" that the port that contains the 16550, exists.  When I
soft reboot from linux (after doing a shutdown), the CMOS screen shows
one less serial port (in my case, None), and programs such as OS/2
refuse to install the COM drivers because they don't see the serial
port.  (I have no term program running under Linux at the time)

I had this problem with beta versions OS/2 early on where it would
exhibit the same behavior (and still will if I reboot OS/2 while
running a term program), but a normal shutdown (in the final release of
OS/2) "correctly closes" the port (ie. the computer is aware of the
ports existence when the CMOS screen comes up).

Is there code that needs to be added to Shutdown that would relinquish
control of the port?
Thanks..
-- 
Rob Coleman ][ gt0449a@prism.gatech.edu        ][  "I think I'm going bald!"
Comp. Sci.  ][ Georgia Institute of Technology ][        -Rush/COS
Newsgroups: comp.os.linux,comp.sys.ibm.pc.hardware
From: rajat@watson.ibm.com (Rajat Datta)
Subject: Re: Need help with programming ET4000
Date: Thu, 20 Aug 1992 20:32:16 GMT
Disclaimer: This posting represents the poster's views, not necessarily those of IBM
Organization: IBM T.J. Watson Research Center
Keywords: ET4000 SVGA

I have modified the vga.c program in vgalib 1.0 to work on et4000's in
extended mode.  If you, and anyone else, is interested in my changes,
please send me a note and I'll mail it to you (I can't mail till
tomorrow cuz it's on my home machine and not here at work).  I still
can't change the clock value on my et4000 based card (have no idea how
it's done), so am stuck with 800x600-16 mode since I boot Linux in
100x40 mode (Linux changes the clock value via a bios call).  If
anyone can tell me how to change the clock value, I would very much
appreciate it.

I do recommend getting vgalib 1.0 (it's available on tsx-11.mit.edu
under the Linux tree).  It's an excellent package and certainly enough
for doing vga-only graphics (boot in Linux in 80*25 mode).

Index 0x33 at at 0x3d4 increases the display start address size by 2
bits.  The upper and lower halves of the address are at index 0x0c and
0x0d (I believe; I'm typing this from memory).  Taken together this
gives you a 18bit pointer into the display memory.  The maximum
display memory can be 256K by 4 planes (total 1 Mbyte; 2**18 is 256k).
This lets you set from where in the memory to get the display image
from.  Properly done this lets you scroll down an image very quickly.
Or, you have four pages (in 800x600-16 mode) and you can display one
frame of animation, while you're filling in the next frames in the
other pages, and then switch the display page without moving 60000
*4 bytes (800*600/8 * 4 planes).
-- 
rajat (rajat@watson.ibm.com)
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: A technical question on CONTEXT (TASK) SWITCHING by the Kernel
Keywords: task switch, context switch, task state segment, kernel
Date: 21 Aug 92 07:25:48 GMT
Organization: University of Helsinki

In article <1992Aug20.164928.24749@ramsey.cs.laurentian.ca> ron@ramsey.cs.laurentian.ca (Ron Prediger [Velociraptor]) writes:
>Here is another technical question about the Linux kernel.  Context
>switching in particular.

Ok, more answers...

>        #define switch_to(n) {\
>        struct {long a,b;} __tmp;\

This just fools gcc to get 8 bytes of space on the stack, so that we
don't have to get them anywhere else..

>        __asm__("cmpl %%ecx,_current\n\t"\
>                "je 1f\n\t

%ecx is set up with the task we want to switch to when we enter the
inline assembly statement, so this is obviosuly testing whether we are
trying to switch to the current task, in which case nothing is done. 
Besides being an obvious optimization, I don't think the 386 allows a
tss-jump to the current task (but not having my books around me, I can't
check). 

>                "movw %%dx, %1\n\t"\

This just moves %dx (which contains the tss-selector) into the word at
__tmp+4. So ___tmp looks like this:

__tmp+0: undefined long
__tmp+4: tss-selector word
__tmp+6: undefined word

>                "xchgl %%ecx,_current\n\t"\

This exchanges %ecx and 'current' - %ecx will contain the task we are
now executing in, and 'current' will contain the task we are just about
to jump to.

>                "ljmp %0\n\t"\

This does the actual task switch: we do an indirect long-jump to __tmp.
This is also the reason we updated just the word at __tmp+4: a long jump
to a new tss-selector will ignore all other values. It will
automatically jump to the place indicated by the tss segment.

>                "cmpl %%ecx,_last_task_used_math\n\t"\

Yes, this looks illogical: we just did an unconditional jump, and this
should never be reached.  Right? Wrong.  The ljmp will return once some
other task does it's own ljmp to this task.  Now %ecx contains the
current task, so we check if this is the task that used the math
coprocessor last... 

>                "jne 1f\n\t"\
>                "clts\n"\

...in which case we can clear the TS flag, giving better
math-performance. Due to these three lines, linux never saves math state
unnecessarily.

>                "1:"\
>                "::"m" (*&__tmp.a),"m" (*&__tmp.b), \

This just sets up %0 - pointing to '__tmp', and %1, pointing to
'__tmp+4'.

>                "d" (_TSS(n)), "c" ((long) task[n]) \

%dx contains the tss-descriptor for the task we want to switch to, and
%ecx contains the task-pointer of the task we want to switch to.

>                :"cx");\

And this just tells gcc that %ecx is changed by the inline-asm.

That's it: 8 lines of assembly does the linux context switch with
math-state optimizations.  Note that newer sources should have a cli-sti
pair around the "xchg %%ecx,_current ; ljmp %0", so that 'current' is
always up-to-date, even when running under interrupts.

		Linus
Newsgroups: comp.os.linux
From: hooft@fys.ruu.nl (Rob Hooft)
Subject: Ghostscript 2.5 has an S3 driver in it's DOS implementation?
Keywords: S3 X11 X386 SVGA
Organization: Physics Department, University of Utrecht,  The Netherlands
Date: Fri, 21 Aug 1992 07:38:23 GMT

I do not know who of you all is interested in writing an S3 driver for
X386, but I just read something in the DOCS for the new ghostscript that
it is supposed to use the S3 accelerator in its DOS implementation.
May be you all could use this as a source for the long-wanted S3 
documentation?

-- 
Rob Hooft, Bijvoet Center for Biomolecular Research, 
Chemistry department University of Utrecht, the Netherlands
hooft@hutruu54.bitnet hooft@chem.ruu.nl hooft@fys.ruu.nl hooft@cc.ruu.nl
Newsgroups: comp.os.linux
From: butler@cs.tulane.edu (Larry Butler)
Subject: Can't compile xloadimage with gcc 2.2.2d
Organization: Computer Science Dept., Tulane Univ., New Orleans, LA
Date: Thu, 20 Aug 1992 02:01:14 GMT
Nntp-Posting-Host-[nntpd-17108]: rex

When I try to compile xloadimage with gcc 2.2.2d I get:
ld: No such file or directory for libXext.a

Any ideas?

Larry    (butler@cs.tulane.edu)
From: ted@nmsu.edu (Ted Dunning)
Newsgroups: comp.os.linux
Subject: Re: shared libs - can everyone be happy with this?
Date: 20 Aug 92 17:34:04 GMT
	<1992Aug17.152210.23427@riacs.edu> <1992Aug18.023010.6841@colorado.edu>
Reply-To: ted@nmsu.edu
Organization: Computing Research Lab



writable code segments or executable data segments are _very_
important to programs that would like to do dynamic loading.

of these two options, the second is preferable.
--

There ain't nothin' in this world that's worth being a snot over.
	Larry Wall
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: Linux Standards (was: Stabilizing Linux)
Date: 16 Aug 92 07:33:40 GMT
Organization: University of Helsinki

In article <danielce.713926038@munagin> danielce@mullian.ee.mu.OZ.AU (Daniel AMP Carosone) writes:
>
>May one presume that if Linus has any objections to what someone is
>doing with his work (and, by proxy, the work others have contributed)
>he will make them known and clear? If he does have some objection, and
>that is not heeded, he is free to change the terms of the License for
>later releases if he deems it necessary.

Well, I've answered this by email and earlier in the newsgroup, but I
guess it won't hurt to say it once more: I have no objection whatsoever
to any commercial use of linux that abides by the copyright.  Not only
because I wouldn't have a legal leg to stand on, but simply because
there isn't any point in it.  I'm not making any money off linux, so I
cannot lose anything by letting others do it - it's not as if they were
competing in the same market-place. 

Also, if people sell linux, it certainly won't hurt the "free" status of
linux: it won't make all the free releases go away.  So there isn't
really anything to get excited about - a commersial linux won't hurt the
linux users in the slightest, and might make linux available to people
that otherwise didn't have the possibility of getting it. 

The earliest versions of linux had a more restrictive copyright: any
commercial activity was prohibited by it.  That was mostly due to (a) an
overreaction to the price I had to pay for minix ($169 may not be much,
but it's still more than I can afford: I'm still paying monthly
installments on my machine) and (b) protection: linux wasn't well-known
then, and I didn't think it was ready for commercial use anyway. 

(a) is silly, (b) went away with 0.12 - the copyright essentially
changed when I got the first query about selling linux (with just a
small delay to make sure there were no objections from people that had
made patches available.  There weren't). 

And as to the price: it doesn't really matter.  If somebody wants to
make linux availabe for $ 995.95 ("special price just for you, amigo"),
I'd certainly be interested to hear how well it sells, but it won't
bother me.  And bickering over whether $60 is too much is silly: people
buy it if they feel it's worth it.  Actually, a nicely priced product
may sell better than a cheap one: it's illogical, but some people feel
that a product cannot be very good if it's cheap.

		Linus
Newsgroups: comp.os.linux
From: dlw1@cec1.wustl.edu (David Lee Williams)
Subject: SLS Installation Question
Organization: Washington University, St. Louis Mo.
Date: Wed, 19 Aug 1992 15:27:57 GMT

Hello,

I'm new to Linux and I would like to say THANKS to all who have contributed
to it.  I have not yet run it, other than booting my machine to see if it
works (surprise! it does), but from what I have seen and heard so far, I
can't wait to get it up and running.

That brings me to my question.  After following c.o.l. for several weeks and
after searching the network to find all that I needed, I came accross SLS.
This is wonderful; everything I need all in one place.  Anyway, I  
downloaded all of the disks (1 and 2 on 5 1/4" because my boot drive is 5 1/4,
and 3-15 on 3 1/2" because it was convenient).  I began the installation, and
came to the following problem:

	After booting with disks 1 and 2 and running fdisk and mkfs,
	this tells the installation script to install to partition 2
	of the hard drive (which is what I want).  The problem is that,
	since I booted on the 5 1/4" drive, the installation script
	expects me to install from there.

Is there any way to tell the installation script to install to /dev/hda2
5 1/4 ?


(Please forgive me, I have been developing for Unix and X for a while,
but I do not do any sysadmin)


Thanks in advance.

David Williams
williams@aicenter.mdc.com
From: jliddle@rs6000.cmp.ilstu.edu (Jean Liddle)
Newsgroups: comp.os.linux
Subject: Re: header woes with 2.2.2d
Date: 19 Aug 92 01:44:13 GMT
Organization: Illinois State University

In article <1992Aug18.175526.18087@serval.net.wsu.edu> hlu@phys1.physics.wsu.edu (Hongjiu Lu) writes:
>jliddle@rs6000.cmp.ilstu.edu (Jean Liddle) wrote
>-------------
>Well, my hopes of flawless compilation of the ps package under 2.2.2d
>have been dashed.  I followed the instructions in the FAQ, README, and
>
> [ ... ]
>-------------
>
>I am afraid if you can compile `ps' with gcc 2.2.2 and 0.97 patch 1. You will
>have trouble with gcc 2.2.2d since to compile `ps' with gcc 2.2.2 and 0.97
>patch 1, you must have done something to the header files which will break
>gcc 2.2.2d.
>
[H.J.'s Solution deleted]

Thanks everyone for the help.  It turns out that Krishna Balasubra
gave me the simplest solution.

Apparently, by removing the #definition of _LINUX_TYPES_ from 
command.c all of the include problems go away.  Deleting this one
line solved everything!  After that, ps, w, who, etc. all compiled
without any problems.

Again, many thanks to everybody!

Jean.
-- 
Jean Liddle                                 | == Bill Clinton for President ==
Computer Science, Illinois State University | 
e-mail:  jliddle@ilstu.edu                  | - Carol Mosley Braun for Senat -
From: jds@cs.umd.edu (James da Silva)
Newsgroups: comp.os.linux
Subject: Re: SLS: Free Linux Distribution.
Date: 14 Aug 92 02:55:48 GMT
Organization: University of Maryland, Department of Computer Science

erc@unislc.uucp (Ed Carp) writes:
>Peter MacDonald (pmacdona@sanjuan) wrote:
>
>: Linux is already available from a distribution service (commercial 
>: found at the end since none of you will want to use it).
>
>I don't think that c.o.l is the place to be putting advertisments for
>commercial ventures, which is what this is.  Take it to the biz. groups.

Sounds to me like Peter is providing a good service that might expand the
linux community to the less well-connected, and it was appropriate for him
to let the linux group know about it.  What's your gripe, exactly?

> ... and NSFnet (and other gateways) get unhappy about commercial
>advertisments on non-commercial newsgroups.

Ha, ha.  That's a good joke, Ed.  

But a bit far removed from reality, I'm afraid.
Jaime
............................................................................
: Stand on my shoulders, : jds@cs.umd.edu  :		      James da Silva
: not on my toes.	 : uunet!mimsy!jds : Systems Design & Analysis Group
Newsgroups: comp.os.linux
Subject: 0.97.1+ Slows down, why?
From: ace3@quads.uchicago.edu (Tony 'LLama' Acero)
Date: Sat, 22 Aug 1992 23:11:50 GMT
Reply-To: ace3@midway.uchicago.edu
Followup-To: comp.os.linux
Organization: University of Chicago Computing Organizations

First off, my configuration:
486/33 w 10MB RAM, no swap
mouse, ATI VGA wonder (early version), 2 65MB RLL hard disks

Kernel: 0.97.1 + grow_buffers patch + selection 1.3
+ ext FS (latest version, no problems!)
+ msdos FS ALPA 7 (no problems!)
and gcc v2.2.2d


If you'll all recall, about a week ago I mentioned that if I did a
make clean; make dep; make all
in /usr/src/linux the kernel would get built in a 
little over 12 minutes (a personal best :-).

If, however, I did it over and over again (a torture test :-)
subsequent runs would be slower and slower and finally the system
would die.

I have since compiled GnuChess -- when I run Gnuchess immediately
after a reboot, Gnu searches +4000 nodes/sec
If I recompile the kernel (as above) and run Gnu again its search
speed is down to 200-400 nodes/sec -- down by at least a factor of
10x!

This is a data point, not a complaint!  Any suggestions as to what
might be going on (ie what I've done wrong :-) would be most welcome.

Since I don't usually have dire need to recompile the kernel during a
day's work, the system is quite responsive in general -- it's been 
working flawlessly with my Gateway Telepath at 14400 baud even with 
a kernel recompile in another VC.

Thanks a million Linus!

tony acero
From: hlu@phys1.physics.wsu.edu (Hongjiu Lu)
Newsgroups: comp.os.linux
Subject: Re: Diamond Speed Star SVGA card
Date: 15 Aug 92 05:11:58 GMT
Organization: Washington State University

I think you can add a few real mode codes before the kernel is loaded. If
it is true, you just need to know what code is sent to VBIOS to set the
clock.

-- 
H.J.
Gcc/libc maintainer for Linux.
In article <1992Aug14.174805@hammer.Prime.COM>, cummings@hammer.Prime.COM (Kevin Cummings) writes:
|> In article <1992Aug14.171832.23483@usenet.ins.cwru.edu>, mal11@po.CWRU.Edu (Matthew A. Lewis) writes:
|> > anyone got this to work with X under Linux????
|> 
|> Yes, but not me, I don't have one.
|> 
|> > And also, is it true that the Diamond Stealth card won't work 'cuz
|> > it has that new S3 chip???
|> 
|> Yeup, that's also true.  I do own one of these, but I haven't tried.
|> I've been trying to figure out how Diamond selects the clocks for the
|> different video modes.  No luck yet.  If I have time this weekend, I'll
|> play around with DEBUG under DOS, and try and see what the bleep the VBIOS
|> is doing for mode selection.
|> 
|> =================================================================
|> Kevin J. Cummings                       PrimeService
|> 20 Briarwood Road                       A Computervision Company
|> Framingham, Mass.                       500 Old Connecticut Path
|> 					Framingham, Mass.
|> Work:  cummings@primerd.Prime.COM
|> Home:  cummings@kjc386.framingham.ma.us
|> 
|> Std. Disclaimer: "Mr. McKittrick, after careful consideration,
|> 		  I've come to the conclusion that your new
|> 		  defense system SUCKS..."   --  War Games
|> =================================================================