HDTenEightyP/NetNews huggingface dataset:
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: 0.97 patchlevel 5 available
Date: 13 Sep 92 08:59:01 GMT
Organization: University of Helsinki

In article <1992Sep12.214957.620@cambria.columbus.oh.us> bjones@cambria.columbus.oh.us (Bill Jones) writes:
>
>Well I rushed out and got 0.97.5, compiled it and installed it.  All of a
>sudden I began to get HD timeout errors (something I haven't seen since
>0.12).  Switched back to 0.97.4 and they all went away!?

Argghh.  It's probably the outb_p() changes - that is the only thing in
the HD driver that changed.  Look into linux/kernel/blk_drv/hd.c - if
you get pl5 by getting the full source, it doesn't define REALLY_SLOW_IO
any more, as I hoped it would be unnecessary.  It looks like

  #undef REALLY_SLOW_IO
  #include <asm/system.h>
  #include <asm/io.h>
  #include <asm/segment.h>

and you should probably change the "undef" to "define".  I'll change it
back for the next version - it seems the REALLY_SLOW_IO define is still
needed on some machines. 

If the above doesn't help (it should), you might also take a look at the
actual delay instruction used to slow down IO. This can be found in
linux/include/asm/io.h, and looks something like this:

  #ifdef SLOW_IO_BY_JUMPING
  #define __SLOW_DOWN_IO __asm__ __volatile__("jmp 1f\n1:\tjmp 1f\n1:")
  #else
  #define __SLOW_DOWN_IO __asm__ __volatile__("inb $0x80,%%al":::"ax")
  #endif

  #ifdef REALLY_SLOW_IO
  #define SLOW_DOWN_IO { __SLOW_DOWN_IO; __SLOW_DOWN_IO; __SLOW_DOWN_IO; __SLOW_DOWN_IO; }
  #else
  #define SLOW_DOWN_IO __SLOW_DOWN_IO
  #endif

You might change the default slow-down instruction from

	__asm__ __volatile__("inb $0x80,%%al":::"ax")

to

	__asm__ __volatile__("outb %al,$0x80")

Whatever you do, I'd be very interested to hear what you did, and if it
worked, so that I can get it fixed for the next version.

Also, there seems to be some problem with the extended fs patches:
either Remy's patches or the changes I made to the inode setup.  So pl5
still seems to have some irritating bugs.  I'll try to find it. 

		Linus
From: tdunbar@vttcf.cc.vt.edu (Thomas Dunbar)
Newsgroups: comp.os.linux
Subject: Re: 0.97 patchlevel 5 available
Date: 13 Sep 92 11:55:21 GMT
Organization: Virginia Tech, Blacksburg, VA


patch 5 works fine on mine (386sx/16, 8M ram, 130M maxtor) so perhaps it's
timings again..if u slow the speed, do u still have the problem?
Newsgroups: comp.os.linux
From: "Louis J. LaBash, Jr." <A200%SIUEMUS.BITNET@mitvma.mit.edu>
Subject: Re shar shell archive {unshar src}
Reply-To: A200%SIUEMUS.BITNET@mitvma.mit.edu
Organization: The Internet
Date: Wed, 9 Sep 1992 15:31:45 GMT

Hi,
Saw your request for a pointer to an UNSHAR, it is available from
wuarchive.wustl.edu  [128.252.135.4]   via anonymous ftp in
mirrors/unix-c/file-mgmt/unshar.tar-z .  Washington University
is a SIMTEL mirror.
 -ljl-
 ---------------------------------------------------------
      /* No group wants equality; only supremacy. */
                          -ljl-
      A200@SIUEMUS.BITNET   |   labashl@vax3.siue.edu
      Louis J. LaBash, Jr., Southern Ill. Univ. @ Edw.
         MS 1052, Edwardsville, IL 62026-1052 USA
Newsgroups: comp.os.linux
From: badger@phylo.life.uiuc.edu (Jonathan Badger)
Subject: Diamond Product clarification requested
Organization: University of Illinois at Urbana
Date: Thu, 10 Sep 1992 13:45:54 GMT
Keywords: Diamond X

I am the proud(?) owner of a Diamond Stealth Card. I understand the legal
problems that could ensue by dissembling the BIOS, etc. However, right now
can I use my Stealth in any resolution in X (even normal VGA)?

Secondly, I notice that Microsoft Windows 3.1 has a 800x600 16 color driver
that claims to be compatible with all SVGA cards -- doesn't this mean all
cards (including the Stealth) must be the same at this resolution?
Newsgroups: comp.os.linux
From: pen@lysator.liu.se (Peter Eriksson)
Subject: AF_UNIX sockets - anyone working on them?
Keywords: AF_UNIX sockets
Organization: Lysator Academic Computer Society, Linkoping University, Sweden
Date: Sun, 13 Sep 1992 18:56:45 GMT

Is there anyone working on fixing the missing stuff in the AF_UNIX
socket routines?

(I'd especially like to get SOCK_DGRAM and recvfrom() working - the
BSD syslogd uses them...)

/Peter

--
Peter Eriksson                                              pen@lysator.liu.se
Lysator Academic Computer Society                 ...!uunet!lysator.liu.se!pen
University of Linkoping, Sweden                           I'm bored. Flame me.
From: eric@tantalus.dell.com (Eric Youngdale)
Newsgroups: comp.os.linux
Subject: Re: 0.97pl4 breaks SCSI extended partition code
Date: 9 Sep 92 05:52:44 GMT
Organization: Naval Research Laboratory

In article <1992Sep9.000644.1996@galileo.cc.rochester.edu> ctne_ltd@uhura.cc.rochester.edu (Chris Newbold) writes:
>Okay. This looks like a generic problem with the SCSI extended partition code.
>I have seen several senarios which result in the problems described above.
>
>	1. Adding the CD-ROM filesystem extentions did it for me.
>	2. Compiling the kernel under GCC v2.2.2d did it for some
>	3. Now, looks like pl4 has blown it in this case.
>
>I was trying to work with Eric (the author of the CD-ROM stuff) to find
>out what goes wrong, but my disk controller flaked out and I haven't
>had a machine for the last week...

	I found another guinea pig, and it appears as if we are closing in
on the solution.  What I do know is that make_request in ll_rw_blk.c returns
because it believes that the read is beyond the end of the partition.
Specifically, the problem shows up in the following segment:

	count = bh->b_size >> 9;
	sector = bh->b_blocknr * count;
	if (blk_size[major])
		if (blk_size[major][MINOR(bh->b_dev)] < (sector + count)>>1) {
			bh->b_dirt = bh->b_uptodate = 0;
			return;
		}

As of yet, I do not know whether the blk_size array is incorrect or if sector
or count is corrupt, or whether we are not converting something somewhere.
I hope that within a day that we will have enough information to squash this
bug. 

-Eric


--
Eric Youngdale
eric@tantalus.nrl.navy.mil
Newsgroups: comp.os.linux
From: mdiehl@triton.unm.edu (J. Michael Diehl)
Subject: Binaries for Dos Emu.
Date: Tue, 15 Sep 92 08:12:58 GMT
Organization: University of New Mexico, Albuquerque

I'd like to play around with this, but am STILL using floppies, so could some
kind soul please send me the binaries to the dos emulation package?  Thanx in
advance.

+-------------------------+----------------------------------------------------+
|  J. Michael Diehl  ;-]  |  I thought I was wrong once.  But, I was mistaken. |
|                         +----------------------------------------------------+
|  mdiehl@hydra.unm.edu   | "Life is stranger than fiction, because fiction    |
|  Thunder@forum          |                has to make sense!"                 |
|  Thunder@Tiny*          |                                                    |
|  (505) 272-HaHa         |                                                    |
+-------------------------+----------------------------------------------------+
Newsgroups: comp.os.linux
From: dje@cygnus.com (Doug Evans)
Subject: Re: GCC 2.2.2d bug
Organization: Cygnus Support
Date: Sat, 05 Sep 1992 01:33:20 GMT
X-Newsreader: Tin 1.1 PL5

Pieter Immelman (pi@oliver.sun.ac.za) wrote:
: I have found that gcc is generating the wrong code for the following
: code fragment:
: 
:   int p = 10;
:   p = p++;

My, albeit limited, reading of the standard says that the behaviour
is "unspecified" - the implementor can choose what happens.

ANSI introduced the concept of "sequence points" to aid in pinning down
exactly when various things occur. In this particular case, the standard
says the increment "shall occur between the previous and next sequence point."
So gcc is perfectly free to increment {p} after the assignment.

And, of course, programs that depend upon unspecified behaviour are
nonportable. Etc. etc. etc.

--
Doug Evans        | With views like these ...
dje@cygnus.com    |                           who needs disclaimers.
Newsgroups: comp.os.linux
From: jes@grendel.demon.co.uk (Jim Segrave)
Distribution: world
Subject: fdformat loops
X-Mailer: cppnews $Revision: 1.14 $
Organization: None
Date: Sun, 6 Sep 1992 18:45:54 +0000


In article <1992Sep6.133604.26927@afterlife.ncsc.mil> jepstei@afterlife.ncsc.mil (John Epstein) writes:
> 
> setfdprm /dev/fd0 1200/1200
> fdformat /dev/fd0
> looped on "floppy 0: data CRC error: track 77, head 1, sector 1"
> 
> CTRL-C was no help, pulled bad disk out of drive --- got 6 errors
> reading non-existent disk
> 
> This was a little hard on the floppy drive.
> 
> Have not yet read the source to fix the problem.
> 
> John

1.2M drives only have tracks 0..76. 

--
Jim Segrave (Segrave Software Services)     jes@grendel.demon.co.uk

Newsgroups: comp.os.linux
From: hans@mo.hobby.nl (Hans Oey)
Subject: Re: 0.97 patchlevel 3 available
Date: Sun, 6 Sep 1992 17:40:44 GMT
Organization: Makkee & Oey

torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) writes:

[...]
>The swap-page handling resulted in a reduction of swap-file (or
>partition) size to a maximum of 16MB per file.  It's nothing inherent to
>the code, but it eased some algorithms, so I didn't bother coding around
>it.  After all, 16MB is enough for most people, and if you want more,
>you can have up to 128 swapfiles of 16MB each.  If I get enough
>hate-mail about it, I might just try to find the energy to correct it. 
>Maybe. 
Sure, 16 Mb is enough. Jeez, why would people ever need
more then 640 Kb? Swap partitions give far better
performance. Should we use up to 128 partitions?
Please remove this limitation on Linux. Would a beer or
two help you to find the energy?
--
Hans Oey
hans@mo.hobby.nl
From: davidsen@ariel.crd.GE.COM (william E Davidsen)
Newsgroups: comp.os.linux
Subject: Re: 0.97 patchlevel 3 available
Date: 8 Sep 92 18:10:11 GMT
Reply-To: davidsen@crd.ge.com (bill davidsen)
Organization: GE Corporate R&D Center, Schenectady NY

In article <1992Sep5.184606.11361@klaava.Helsinki.FI>, torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) writes:

|  - I edited the minix fs pretty heavily to remove a couple of race-
|    conditions.  The same races still exist in the extended fs, as I
|    didn't have time to edit that yet.  The minix-fs took precedence as I
|    know that better, and extfs isn't "official" yet anyway. 

  Sure would be nice to get this fixed.

| The swap-page handling resulted in a reduction of swap-file (or
| partition) size to a maximum of 16MB per file.  It's nothing inherent to
| the code, but it eased some algorithms, so I didn't bother coding around
| it.  After all, 16MB is enough for most people, and if you want more,
| you can have up to 128 swapfiles of 16MB each.  If I get enough
| hate-mail about it, I might just try to find the energy to correct it. 
| Maybe. 

  Hate mail, no, but I think this should be fixed at some point.
As long as multiple swap file work those users who need huge swap space
can have it by creating a /swap (or some such) partition and creating
multiple swap files within it. It's ugly, but I see no reason why a
feature used only by a few people should be pretty as long as it works.
If you couldn't do it at all I'd complain, but I can live with this if
my image size gets so big it doesn't fit in 16+16 I'll live with a
little inconvenience. Of course having more memory work would be nice,
too, but it raises all sorts of problems. Maybe memory >16M could be
used for swap of some such.
From: baron@clifton.hobby.nl (Wim `Blue Baron' van Dorst)
Newsgroups: comp.os.linux
Distribution: world
Subject: Re: Help with X11 clock/monitor settings
Organization: Minix Hobbynet Host
Date: Sat,  5 Sep 1992 18:42:10 MDT

hammond@kwhpc.caseng.com (Kevin W. Hammond) writes:
> The problem I seem to be faced with is the horizontal and vertical timings 
> for my monitor.

Read the XConfig.Notes, available from the official X386 FTP site, e.g.,
ftp.win.tue.nl (I got it there). It is an excellent description on how 
to do the horizontal/vertical timings in Xconfig.

Note that you must have a supported videocard, because ever so good entries
in Xconfig then can't help you (Personal experience).

Met vriendelijke groeten, Wim `Blue Baron' van Dorst
---------------------------------------------------------------------
Blue Baron = Wim van Dorst, Voice (+31) 074-443937, (+31) 02152-42319
(-:       baron@clifton.hobby.nl          tgcpwd@urc.tue.nl       :-)
---------------------------------------------------------------------
From: copernicus@digund.uucp (Copernicus) 
Newsgroups: comp.os.linux
Subject: Re: Linux support BBS- wh
Date: 8 Sep 92 15:53:00 GMT
Distribution: world
Organization: Digital Underground - PRIVATE
Reply-To: copernicus@digund.uucp (Copernicus) 

PLUG ALERT!!!   PLUG ALERT!!!

SHC:>Currently UNIX USER is running 2400 baud MNP/V.42 modems.  I hope
SHC:>to expand to suppport V.32 in the near future.  Unfortunately,
SHC:>we're starting to believe we're going to have to charge for
SHC:>BBS access as things expand (particularly since we'd like to go
SHC:>to multiple lines).  This will probably be on the order of
SHC:>$20 /year flat fee.

SHC:>Our BBS also provides Internet mail and USENET news (a limited
SHC:>number of groups, including comp.os.linux)

SHC:>Call in and give us a try.  We're in the process of putting up
SHC:>MCC 0.97p2 Linux.  Some of it is there, the rest will be by the weekend.

I dont mean to start a BBS war,  but would like to add mine in there.

Digital Underground is a IBM PC (286/12) utilizing a Hayes Ultra 144 and
a Micropolis 1528 (1350mg).  I do not demand a fee/charge but do not
discourage donations :> !

We also get a (close to) full usenet feed with Internet mail avaible to
authorized users.

Give us a call if you need anything.  I usually update my Linux/386BSD
archives about 2 times a week (depending on network load!)

Chris Nalley / Digital Underground / 812-941-9427
---
 . SLMR 2.1 . Digital Underground - A Copernician Corporation
                                            
Newsgroups: comp.os.linux
From: smace@nyx.cs.du.edu (Scott Mace)
Subject: Massive speed increase with more memory
Summary:  Increase of speed by adding 4 more megs of ram (8 total)
Keywords:  speed, increase, RAM, kernel, compiling
Organization: Nyx, Public Access Unix @ U. of Denver Math/CS dept.
Date: Sat, 5 Sep 92 00:23:14 GMT


I just upgraded my system memory for a total of 8 megs and the
performance increase was phenominal.  Everything works faster.
I had 4 megs before, and if took over an hour to compile 0.97.2 kernel
with gcc2.2.2d, now in takes a whopping 15 minutes.  Also, X stuff
runs alot faster.

If you are thinking about upping your memory, do it!


--
*********************************************************************
*    Scott Mace                internet:    smace@nyx.cs.du.edu      *
*                                          emace@tenet.edu          *
*********************************************************************
Newsgroups: comp.os.linux
From: dennisf@miles.com (Dennis Flaherty)
Subject: 0.97.5 problems with termcap, extfs, ps
Organization: Miles, Inc.  Diagnostics Divis.
Date: Tue, 15 Sep 1992 13:08:50 GMT


Hello,

I finally have my own 486/33, running Linux 0.97pl5.  Before I start
hacking at it, I'd like to know if anyone has found or fixed any of
the following, or how I may have incorrectly installed something:

1) This is an ancient one: if a process whose tty is in cbreak is
   suspended and then continued, the cursor's cbreak mode is not
   restored, and the screen isn't redrawn.  (Elvis 1.5)

2) When running Elvis 1.5, if I insert a space, the tty inserts two
   spaces, even though Elvis only inserts the one.  I didn't have 
   this problem before the new /etc/termcap (on the root image).

3) Less 177 doesn't work with the new /etc/termcap's con entries,
   although it works with the vt100 entries.

4) In an extended filesystem, I can't rename a directory with mv.

5) The ps-0.97.2 package doesn't seem to work with the 0.97.5 kernel.
   But you probably knew that.

Bringing up gcc 2.2.2d was a LOT less painful than I thought it would
be, judging from the c.o.l discussions.  It helps to be starting all
over.  The install script was Really well done.  Thanx!

Dennis
-- 
Dennis T. Flaherty     dennisf@Miles.com
Miles, Inc.            dflahert@chekov.helios.nd.edu
Diagnostics Division
My doctor says Mylanta, but my boss says Alka-Seltzer!
From: marcel@duteca.et.tudelft.nl (Marcel J.E. Mol)
Newsgroups: comp.os.linux
Subject: Hard Disk light stays on.
Date: 10 Sep 92 21:18:34 GMT
Organization: Delft University of Technology, Dept. of Electrical Engineering

I recently installed linux on my system, and it works great.
Except for one thing: I have a two disk system, and the disk activity 
led doesn't go out when there is no disk activity.
Useful info: Linux 0.97.4
	     Disk 1: Seagate ST3283A (master)
	     Disk 2: Maxtor 7080A (slave)
The disk activity led is driven by the controller, both disks
use the same led.

Linux is in an extended partition on the seagate disk. 
When running plain MSDOS there is no problem: the light is only
on when there is disk activity.

When I remove the Maxtor drive the problem is also gone. I tried 
to change a few jumper settings (jumper 16: Idle Mode Latch, and 
jumper 11: I/O Channel Ready) but this does not help.

It is not really a problem in the sense of crashing systems, but
I have some mixed feelings about it and want to know what's happening.
Any clues?

BTW: does anybody know the exact meaning of 'Idle Mode Latch' and
'I/O Channel Ready'? And also what is the impact of changing 
jumper 18 'ECC bytes' (4 bytes or 7 bytes)?

-Marcel.
-- 
#########################################
# Marcel J.E. Mol                       ######################################
# Delft University of Technology          Pink Elephant B.V.                 #
# The Netherlands                         Voorburg                           #
# inet: marcel@duteca.et.tudelft.nl       Tel: 070-3694231                   #
#                      	  (Tel private: 070-3361515)                         #
##############################################################################
From: khamer@sumax.seattleu.edu (Little Kenny Hamer)
Newsgroups: comp.os.linux
Subject: termcap, debuggers, and other stuff
Date: 8 Sep 92 18:18:57 GMT
Organization: Seattle University, Seattle WA


Yep, it's me again, your constanly confused Linux novice.

I'm working on getting Xfractint to compile. It wants, among other things,
curses (which I just got and compiled) and termcap.  Do I have the termcap
library?  Does it come on the mcc-interim release?  If not, where do I get
it?  If so, where do I find it on my filesystem?  

Also, I have heard talk of gdb.  How do I get that?  It would be very
useful for tracking down errors. (OF COURSE, THAT"S WHAT IT'S FOR!)

any help would be appreciated!

thanks,
  Ken
Xref: sparky comp.os.linux:10357 comp.sys.ibm.pc.hardware:23875 comp.os.ms-windows.misc:2890 comp.sys.ibm.pc.misc:12441
From: baron@clifton.hobby.nl (Wim `Blue Baron' van Dorst)
Newsgroups: comp.os.linux,comp.sys.ibm.pc.hardware,comp.os.ms-windows.misc,comp.sys.ibm.pc.misc
Distribution: world
Subject: Re: The great Video SAGA...
Organization: Minix Hobbynet Host
Date: Tue,  8 Sep 1992 20:29:54 MDT

rwb@Turing.ORG (Robert W. Bingler) writes:
> 	I am in need of some particular advice on video cards.  I am looking at getting an ET4000 chipset based board.  The problem is which one would be the best choice.  I am looking for a inexpensive(cheap) card with hopefully the hicolor option.  I have seen a few major brand of cards such as these, Orchid ...
> 	I am looking for any advantages/disadvantages over these "name brand"
> to that of clone cards.  Also, I want as fast as possible.  Please send me any
> comments on comparisons of these cards:
> 	Orchid Prodesigner IIs   Tseng Labs	generic clones

Without any comparison: I have a Tseng Labs ET-4000D, and it works fine
for X. I had a Oak Technology 067-512k, and it does not work with X

> Probably one of the most important factors is price.  I have seen the Orchid
> at around $150, Tsseng @ $110, clones @ $100.

Price is slightly more than what I paid for Tseng, but roughly ok.

-b-b-
---------------------------------------------------------------------
Blue Baron = Wim van Dorst, Voice (+31) 074-443937, (+31) 02152-42319
(-:       baron@clifton.hobby.nl          tgcpwd@urc.tue.nl       :-)
---------------------------------------------------------------------
From: eric@tantalus.dell.com (Eric Youngdale)
Newsgroups: comp.os.linux
Subject: Re: 0.97pl4 breaks SCSI extended partition code
Date: 9 Sep 92 22:34:21 GMT
Organization: Naval Research Laboratory

In article <716098399snx@prism.demon.co.uk> david@prism.demon.co.uk (David Metcalfe) writes:
>I have now confirmed that my problem occurs in exactly the same
>place.  The values of the key variables with pl4 (the one that fails)
>are
>
>blk_size[major][MINOR(bh->b_dev)] = 0
>sector = 0
>count = 2
>
>When I repeat the same exercise with pl2 (which works), the values of
>the variables on the first pass through the routine are
>
>blk_size[major][MINOR(bh->b_dev)] = 507905
>sector = 0
>count = 2
>
>So the problem would appear to be with the blk_size array.  I will
>leave someone else to work out what the problem is because I'm not
>really a kernel hacker :-)

	OK, I think I see what the problem is, and why this is not working.
I suggest the following patch.  I already gave this patch to Chris Newbold,
and it looks correct enough for me to release to the public.

	Basically this corrects a problem where linux has difficulty reading
the partition table for an extended partition.  If you are not having this
problem, I do not see much point in trying this.

	Basically the problem is that the sd_sizes array is normally
initialized after the partition tables have been read.  Normally
blk_size[MAJOR] should be 0 until  the sizes array is ready, but for
scsi disks blk_size[8] was being initialized prematurely, leading to the
problem in make_request  (As long as blk_size[MAJOR] == 0, testing
of sd_sizes is inhibited).

-Eric

*** sd.c.~1~	Tue Jul 28 19:31:23 1992
--- sd.c	Wed Sep  9 17:18:37 1992
***************
*** 38,44 ****
  				
  int NR_SD=0;
  Scsi_Disk rscsi_disks[MAX_SD];
! static int sd_sizes[MAX_SD << 4];
  static int this_count;
  static int the_result;
  
--- 38,44 ----
  				
  int NR_SD=0;
  Scsi_Disk rscsi_disks[MAX_SD];
! static int sd_sizes[MAX_SD << 4] = {0, };
  static int this_count;
  static int the_result;
  
***************
*** 56,64 ****
  static void sd_geninit (void) {
  	int i;
  	for (i = 0; i < NR_SD; ++i)
! 		sd_sizes[i << 4] = 
! 		(sd[i << 4].nr_sects = rscsi_disks[i].capacity) >>
! 		(BLOCK_SIZE_BITS - 9);
  	sd_gendisk.nr_real = NR_SD;
  }
  
--- 56,62 ----
  static void sd_geninit (void) {
  	int i;
  	for (i = 0; i < NR_SD; ++i)
! 	  sd[i << 4].nr_sects = rscsi_disks[i].capacity;
  	sd_gendisk.nr_real = NR_SD;
  }
  
***************
*** 414,420 ****
  		}
  
  	blk_dev[MAJOR_NR].request_fn = DEVICE_REQUEST;
- 	blk_size[MAJOR_NR] = sd_sizes;	
  	blkdev_fops[MAJOR_NR] = &sd_fops; 
  	sd_gendisk.next = gendisk_head;
  	gendisk_head = &sd_gendisk;
--- 412,417 ----
--
Eric Youngdale
eric@tantalus.nrl.navy.mil
Newsgroups: comp.os.linux
From: hlu@poly2.eecs.wsu.edu (H.J. Lu)
Subject: Urgent request
Keywords: gcc, libc.a, sh
Organization: Washington State University
Date: Fri, 11 Sep 92 18:54:07 GMT

I am going to release a new gcc/libc.a this weekend. It will have
jump table 4.1. X11 v2.0 will use it. To install it, you have to
run 0.97 pl 4. Please upgrade your kernel to 0.97 pl 4 now. And
also you have to have a real sh. zsh is not that compatible. You have
to have bash linked to sh.


H.J.