HDTenEightyP/NetNews huggingface dataset:
From: hlu@eecs.wsu.edu (H.J. Lu)
Newsgroups: comp.os.linux
Subject: ANSWER: (Re: GCC report segmentation fault and dump core.)
Date: 7 Oct 92 17:01:59 GMT
Article-I.D.: serval.1992Oct7.170159.11640
Organization: School of EECS, Washington State University

In article <1992Oct7.082419.10458@nntp.hut.fi>, mjalava@lk-hp-10.hut.fi (Mika Matti Jalava) writes:
|> In article <BvpEpB.1xK@usenet.ucs.indiana.edu> tqhoang@silver.ucs.indiana.edu (Toan Hoang ~{) writes:
|> 
|> >WHen ever I tried to compile a C
|> >code, it would give me a segmentation fault and dump core, even running the
|> >gcc alone will do so.
|> 
|> You might suffer from the file corruption problem. The newer kernels
|> are not very reliable with some hard disks and files may get corrupted
|> when written to the disk. Try installing again. It may not work even
|> then, I had to install the biggest parts of the compiler on a floppy
|> to be able to compile the kernel with HD_DELAY set in hd.c. That
|> helped a little.
|> 

[...]

I have seen quite a few people getting segmentation fault and dump core
when they run something under Linux. I may have the answer for the
problem.

If you have a fast CPU (> 25 MHz), please check your RAM. If the speed
of RAM is slower than 60ns, you may be in big trouble. Don't tell me
it runs well under DOS. Linux is a protected mode OS. My 386sx-16
without cache uses 80ns RAM. For a fast CPU, anything slower than 60ns
may not work very reliably. You have a few choices:

1. Get fast RAM. (should always work)
2. Get a big cache for CPU, like > 256k. (may work)
3. Increase wait state of your RAM. (may work)
4. Turn off turbo. (should always work)


H.J.
Newsgroups: comp.os.linux
From: ruhtra@turing.toronto.edu (Arthur Tateishi)
Subject: Re: CMS Jumbo tape drives
Organization: CSRI, University of Toronto
Date: 7 Oct 92 14:17:55 GMT

In article <84524@bcsaic.boeing.com> paula@atc.boeing.com writes:
>In article 15904@umd5.umd.edu, colbert@astro.umd.edu (Edward J.M. Colbert) writes:
>>If Linux has a problem interfacing with the CMS Jumbo tape drives because
>>of the floppy-driver interface, then how about a program that runs from
>>DOS that read the Linux filesytem?  Of course it means that you still have
>>have DOS around (although you could run from floppy), but at least you 
>>could USE the tape drive.
>
>The only real problem Linux has with QIC-40/80 tape drives is that
>nobody has taken on the task of modifying the floppy driver to
>understand QIC-40/80.

I seem to remember hearing (could be mostly hearsay) that LapLink or some
such thing could use a DOS device driver to remotely mount a hard disk.
Further, you can do a backup to CMS Jumbo tapes from this remotely
mounted disk.

There's also stuff like PC-NFS that do similar magic of creating a remote
file system via ethernet using a DOS device driver.

Therefore, I was wondering if the quickest and easiest approach would
be to implement a DOS device driver that could "mount" a Linux file
system and do the backup via it. Of course, I could very easily be all
wet because filename conflicts when mapping to DOS's brain dead 8+3
filenames will cause their own share of problems.

Meanwhile, being the hypocrite I am, I'm going to continue hacking on
the X11 server for ATI VGA Wonder cards (pre v5)

arthur
-- 
"The first fact to face is that UNIX was not developed with security, in any
reliable sense, in mind; this fact alone guarantees a vast number of holes."
    -- "On the Security of UNIX", Dennis M. Ritchie
Arthur Tateishi                 ruhtra@turing.utoronto.ca
From: Joe.Klemmer@f615.n109.z1.fidonet.org (Joe Klemmer)
Newsgroups: comp.os.linux
Subject: Questions...what else
Date: Mon, 12 Oct 1992 10:19:04 -0800

TF=>2)  Could someone recommend a dial-up BBS with VERY up-to-date
Linux
TF=>files...I have called 3 from the linux bbs list and they were all
TF=>still at 0.96 and 0.97 with very little utils etc.  This gets
TF=>expensive to call so I want to find a good system.

        The BBSs will probably be slightly behind the ftp sites due to
having to scrounge for the files.  I know that When Gravity Fails (in
the 202 area code) has a very good up to date file selection.  It
really
would be nice if the BBSs could get more help from those with ftp
abilities.

___
 X SLMR 2.1a X Regardless of what you might think, this is not a
tagline

 * Origin: Enlightened Board (703) 370-9528 (1:109/615)
From: hanson@pogo.fnal.gov (Steve Hanson)
Newsgroups: comp.os.linux
Subject: Re: Backing Up Linux
Date: 7 Oct 92 20:48:09 GMT
Organization: FERMILAB, Batavia, IL
NNTP-Posting-Host: pogo.fnal.gov
Keywords: backups, disk, multi-volume, tar

Hi-
	There IS a document for GNU tar that was provided with - oh ,
gee, I think 1.10.  It is now somewhat out of date.  Anyway, I 
believe that if you want to tar out to multi-volume floppies
you want to do something like this

tar cvMbf 15 /dev/fd0 .

The block size should be the number of sectors in a track on 
your floppy (that is, 15 for 5.25", 18 for 3.5".)  Otherwise
the write fails in the middle of a block and all hell breaks
loose.  I haven't actually TRIED this on Linux, but I do 
read floppies on Linux all the time that were made this way
on a Sun.  

Also, you can't use the -Z compression option along with the
-M multi-volume option.  Please also note that case is important
with the options.

-- 
Steve Hanson - FERMILAB, Batavia, Il.
hanson@pogo.fnal.gov or hanson@fnal.fnal.gov

Newsgroups: comp.os.linux
From: almesber@nessie.cs.id.ethz.ch (Werner Almesberger)
Subject: Re: Booting off hard drive
Keywords: boot
Organization: Swiss Federal Institute of Technology (ETH), Zurich, CH
Date: Wed, 14 Oct 1992 18:06:36 GMT

In article <1992Oct10.231956.7917@cs.tulane.edu> kranz@cs.tulane.edu (Barry Kranz) writes:
> cd /mnt/etc/lilo

> rm map boot.????

I wouldn't do that. LILO overwrites old files automatically if needed and
boot sectors are small enough that you can afford to have some obsolete
ones sitting around.

Deleting an existing and valid map file before running the map installer
may also make your system unbootable if you reboot after the map
creation has begun but before it has been successfully completed,
because the map installer may overwrite blocks of the (deleted) old map
file in the process.

> ./lilo -r /mnt -b /dev/hdxx -i boot.b -v -v -v /vmlinux
>
> That was the end of the instructions.  It was now supposed to boot from hdxx.

I think your problem is caused by "-i boot.b" in conjunction with "-r".
-r does a chroot system call, which changes LILO's view of the entire
file system. Unfortunately, -i boot.b uses a relative path, which is
unaffected by chroot. LILO therefore picks boot.b from the floppy disk.
(It should boot if you insert the floppy you were using at that time,
though.)

  ./lilo -r /mnt -b /dev/hdxx -i /etc/lilo/boot.b -v -v -v /vmlinux
				 ^^^^^^^^^^
... should have the desired effect.

I'll add a chdir("/") or chdir(LILO_DIR) in the next version of LILO so
that one will at least get an error in this situation.

Just as a general reminder: putting the invocation of the map installer
(/etc/lilo/lilo) into a file /etc/lilo/install may save you some grief
at the next kernel update, because you then only have to run
/etc/lilo/install instead of remembering what options and parameters
you were using. Example:

#!/bin/sh
$ROOT/etc/lilo/lilo -b /dev/hdxx -i /etc/lilo/boot.b -v -v -v $* \
  /vmlinux

($ROOT to make it easier to run /etc/lilo/install from a boot floppy
and $* to pass additional options if needed.)

- Werner
-- 
   _________________________________________________________________________
  / Werner Almesberger, ETH Zuerich, CH      almesber@nessie.cs.id.ethz.ch /
 / IFW A44  Tel. +41 1 254 7213                 almesberger@rzvax.ethz.ch /
/_BITNET:_ALMESBER@CZHETH5A__HEPNET/CHADNET:_[20579::]57414::ALMESBERGER_/
Newsgroups: comp.os.linux
From: jes@grendel.demon.co.uk (Jim Segrave)
ReplyTo: jes@grendel.demon.co.uk
Subject: ! on the command line?
Distribution: world
X-Mailer: cppnews $Revision: 1.18 $
Organization: None
Date: Sun, 11 Oct 1992 18:54:10 +0000

I'm running -/97 patch 6 with bash. I was playing around with a script
file with sed and trying to enter a !cmd -

file * | sed '/text/!d'

to list only those files which are text files of some sort.
Bash terminated the command line input before the closing quote, giving
an error message about no event d. I thought bash wouldn't look inside
quoted strings? Is there any way (short of putting the sed expression in
a file) of getting bash to not attempt to expand the '!' ?
I tried escaping it with backslash, which worked, but then sed
complained that it saw an unknown command - implying that the backslash
was (correctly I think) not stripped by the shell's command line parser.

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

Newsgroups: comp.os.linux
From: djr48312@uxa.cso.uiuc.edu (X X)
Subject: Modem dialup for linux?
Organization: University of Illinois at Urbana
Date: Sat, 10 Oct 1992 06:50:40 GMT

I edited the inittab file like the faq says but I cannot get 
modem dialups.  What exactly must I do?
From: jepstei@afterlife.ncsc.mil (John Epstein)
Newsgroups: comp.os.linux
Subject: WHY:  Xfree86-1.1 .xinitrc default changed
Date: 14 Oct 92 05:21:14 GMT
Organization: The Great Beyond

The default .xinitrc in Xfree86-1.1 package for linux
has twm & followed by several xterms with &
and ends with xterm -login (without &).

This results in twm menu "Exit" killing twm without
killing the xterms or quiting X.

In fact, twm can be run from any of the still active xterms.

Executing the twm menu "Kill" in the xterm -login DOES quit X.

This is the expected behavior for the new .xinitrc considering
what is backgrounded and what is last and not in backgroud.

QUESTION:  Why was .xinitrc changed from having the twm (without &)
as the LAST item in .xinitrc?

Now, if the xterm -login "hangs", it can only be closed.  Killing it
will quit X.  

Now, "Exit" only kills twm and doesn't exit.

I plan on going back to a more "normal" .xinitrc was curious as to
why the change was made.

John
From: talley@ashleigh.Kodak.COM (Brian K. Talley)
Newsgroups: comp.os.linux
Subject: SLS 0.98 good, but...
Date: 12 Oct 92 16:33:14 GMT
Followup-To: comp.os.linux
Organization: Eastman Kodak Co., Rochester, NY


Many thanks to the folks at Softlanding for the 0.98 release!  I installed it
quickly and painlessly. :)  I do, however, have some questions.

First, I *sometimes* see the following message at bootup:

        Floppy drive(s): fd0 is 1.44M
        floppy: FDC version 0x90

and *sometimes* I see:

        Floppy drive(s): fd0 is 1.44M
        floppy: weird interrupt ignored
        floppy: FDC failed to return version byte

Anyone know what this might be due to?  It doesn't seem to impede the drive
performance or usage at all, but this message doesn't look too hot.

Also, DOS emulation doesn't seem to work (which isn't a bad thing, imho, but
someone here at work wanted to see DOS emulated under Linux). I recompiled dos
and libemu, and everything went fine. I also created /usr/dos and moved hdimage
to /usr/dos.  I have a known working DOS 3.3 diskette, but when I try to boot,
all it does is clear the screen, read the floppy for a second or two, say
"booted" and hang.  No prompt.  No other messages.  I have to kill the process
from another vc.  Ideas?

One last thing...I found that my Xega wouldn't work under 0.98. Naturally, I
tried relinking it, but I now find that I have too little memory, and I can't
relink it. Anyway, the problem when I type startx is this:

        failed to set default font path '/usr/lib/X11/fonts/misc'
        Fatal server error: could not open default font 'fixed'
        giving up

/usr/lib/X11 points to /usr/X386/lib/X11.  All fonts are in place. Protections
are set properly. I set ``FontPath'' and ``FONTPATH'' to /usr/lib/X11/fonts.
If this is a known problem, is there a known cure?  I'm trying to put off
spending more money on this system as long as I can. Have I run out of time? :}

Please reply via email.

Thanks,

--Brian
__________
Brian Talley, Systems Consultant, Eastman Kodak Research Labs, Rochester, NY
talley@acadia.kodak.com
Newsgroups: comp.os.linux
From: ruhtra@turing.toronto.edu (Arthur Tateishi)
Subject: Re: Kernel Panic
Organization: CSRI, University of Toronto
Date: 7 Oct 92 14:22:48 GMT

In article <1992Oct7.095715.18400@athena.mit.edu> chchen@stat.fsu.edu writes:
>I am posting this message for my new friend Olli who has same
>kernel panic problem due to an odd number of RAMs on board (mine is
>5 mb and his 6 ):
>--------------------------------------------------------------
>From opp@otsoni.tkk.tele.fi Wed Oct  7 04:37:42 1992
>Subject: Re: Kernel Panic
>
>In article <1992Oct6.055750.8976@athena.mit.edu> you write:
>|>After I installed 4 256k SIMMs to make my system 5 mb RAM, I've been
>|>having kernel panic problems...
>
>I am having problems after adding 2 more megs to make 6 Megs of RAM.
>Linux does not boot at all !!!
>Have You had any success after posting ? Have You heard anyone using 5 or
>6 Megs succesfully ? Do we have anything in common which could cause
>the problem ?
I have a friend that is successfully using Linux with a 386SX-25 w/ 9MB
of RAM (1MB on board + 2 4MB simms).
AMI BIOS and one of IDE or ST-02.


-- 
"The first fact to face is that UNIX was not developed with security, in any
reliable sense, in mind; this fact alone guarantees a vast number of holes."
    -- "On the Security of UNIX", Dennis M. Ritchie
Arthur Tateishi                 ruhtra@turing.utoronto.ca
Newsgroups: comp.os.linux
From: jwinstea@fenris.claremont.edu (Jim Winstead Jr.)
Subject: Re: Use of zip instead of compress
Organization: Harvey Mudd College, WIBSTR
Date: Wed, 14 Oct 1992 20:01:45 GMT

In article <1bhpofINN7sl@uwm.edu> rick@ee.uwm.edu (Rick "The Compression Crusader" Miller) writes:
>Okay, it has come up again.  The "Gosh!  There sure is a *difference*!!"
>compression algorithm debate.  I'll just add my 'too sense' up front...
>
>[un]compress	Pro:  This is (currently) the de-facto UNIX *STANDARD*.
>		      Hey, it's not bad... it's just not that great.
>		Con:  Only does one file.  Archiving requires 'tar'.
>
>[un]zip		Pro:  Good compression (better than 'compress').
>		      Archives multiple files/directories into one file.

I don't see why compress working on single files and zip working on
multiple files is a pro for zip and a con for compress.  You will get
better compression if you make a .tar.zip file rather than just a
straight .zip, almost guaranteed.

>		Con:  <GUILT MODE ON> Phil Katz (the "PK" of PKWare) won't
>			be making any money by this use of his invention. 

Um, the InfoZIP has released the code to a PKware-compatible
compressor that they independently developed.  I feel no guilt about
it whatsoever - PK lost the non-DOS market by not pursuing it.  (It's
also hard to call it his invention - he combined various algorithms
and such that were already out there (at least for 1.10), not develop
some new whiz-bang algorithm.)

>		???:  This is somewhat of a DOS standard. (Pro?/Con? :-)

The con is that it doesn't readily support Linux file system-isms like
permissions and owners/groups.

>lha		Pro:  Very good compression (better than 'zip').

Um, I think the newest InfoZIP zip/unzip beats LHA on compression.
Anyone have some statistics?  (Sorry, comp.compression was one of the
casualties in my .newsrc when I realized I read way too much news.  :)

Some you forgot:

freeze	(drop-in replacement for compress, though not compatible.  A
	little on the slow side.)

zoo	(very standard, portable, freely available, good compression)

yabba	(drop-in replacement for compress, though not comptabile.  A
	little on the slow side.  Sound familiar?  :)

hpack	(shareware, not very portable when I looked at it, but it did
	have some interesting possibilities.)

Others.  There are some compression algorithms out there that get very
impressive compression at the sacrifice of speed.  The DDJ Compression
Contest could provide the building blocks for new and better
compression programs.
-- 
                                    +      Jim Winstead Jr. (CSci '95)
                                    |      Harvey Mudd College, WIBSTR
                                    |   jwinstea@jarthur.Claremont.EDU
                                    + or jwinstea@fenris.Claremont.EDU
From: hlu@eecs.wsu.edu (H.J. Lu)
Newsgroups: comp.os.linux
Subject: Re: Problems w OPTI-495WB 486er
Date: 7 Oct 92 17:04:29 GMT
Article-I.D.: serval.1992Oct7.170429.11783
Organization: School of EECS, Washington State University

In article <21696@sbsvax.cs.uni-sb.de>, rzhwj@sbusol.rz.uni-sb.de (Wolfgang Johannes) writes:
|> I have problems in booting LINUX on my OPTI-495WB 486er with 
|> Ami Bios.
|> 
|> I 've tested Linux on my 386/33 and all runs well.
|> 
|> Can someone tell me where to find the error. 
|> 
|> bye
|> rzhwj@rz.uni-sb.de
|> 

Did you turn of the shadow RAM?

H.J.
Newsgroups: comp.os.linux
From: hlu@eecs.wsu.edu (H.J. Lu)
Subject: ANNOUNCE: libdisk is on tsx-11.
Organization: School of EECS, Washington State University
Date: Fri, 9 Oct 92 04:06:53 GMT

People are having some trouble to install the Linux C library 4.1. I just made
a Linux C library 4.1 disk. Please try it and tell me what you get.

It is just a repacked Linux C library 4.1. Nothing is new.

---------
This is the Linux C library 4.1. It has 2 minix disks. It can
fit in either 5.25" or 3.5" floppy.

It is on tsx-11.mit.edu under pub/linux/GCC/libdisk


A. Disk 1 (41lib1.Z)

It has the shared images and a few libraries.


B. Disk 2 (41lib2.Z)

It has the header files and the rest of the libraries. The files in
/usr/g++-include/gen are in compressed format. Please do

cd /usr/g++-include/gen
uncompress *.Z

if you ever need them.

To install them on your hard drive.

1. uncompress base[1|2|3].Z.
2. rawrite or dd it to a floppy disk.

Now you have made a copy of the Linux C library 4.1 on floppy. To copy
it to your hd, you should mount the floppy first and copy the disk.
That is

mount /dev/fd[0|1] /mnt
cd /mnt
for d in bin dev etc usr
do
  if [ -d $d ]; then
    cp -av $d /
  fi
done

Note: This may overwrite some files on your hard disk.

There are two shared math images. The hard version, libmh.so.4.0,
is for 387 only. The soft version, libms.so.4.0, uses those 387
instructions emulated inside the kernel. The default shared math
image, libm.so.4.0, is linked with the soft version. You should
relink it to the hard version after you have installed it on
your hard drive if you have a 387, by doing

cd /lib
rm libm.so.4.0
ln -s libmh.so.4.0 libm.so.4.0
 
Also, the static math library is linked to soft math library by
default. If you have a 387, you should do

cd /usr/lib
rm libm.a
ln -s libhard.a libm.a

The header files are not complete. You have to make two symbolic links
from linux/include of Linux kernel source, which must be 0.97 pl 6 or
above, to /usr/include. Suppose your kernel source is under /usr/src,
you should do

ln -s /usr/src/linux/include/asm /usr/include
ln -s /usr/src/linux/include/linux /usr/include


Starting from this release, I used a new structure for libraries.
The different versions of library, i.e., static, jump table and
classic shared library, are in the same directory, /usr/lib. The
static version is libfoo.a. The jump table version is libfoo.sa and
classic version is libfoo.ca. The new `ld', which is in the third
disk of the Linux Base System, searches for the jump table library
by default. You can overwrite it by adding -static or -nojump to
`ld' or 'gcc'. The jump table and classic versions are not
compatible with each other. The static library is used as the last
resort.
 
Thanks.

H.J.
hlu@eecs.wsu.edu
10/06/09
Newsgroups: comp.os.linux
From: peterson@minerva.Prime.COM (David Peterson)
Subject: Re: Maxtor 7213a update
Followup-To: comp.os.linux
Keywords: Maxtor 7213
Organization: PrimeService, a Computervision Company
Date: Fri, 9 Oct 1992 13:35:10 GMT

jefftep@cs.utexas.edu (Jeffrey Grills) writes:
> please forward all questions you may have to me, either here or in
> mail.  if you have a maxtor 7213a, please tell me your tale...

First off, my configuration:
  486/33, 4M, 256K cache
  Maxtor 7213, PCBA 63
    /dev/hda1 40M DOS
    /dev/hda2  8M Linux /
    /dev/hda3 12M Linux swap
    /dev/hda5 40M Linux /usr
    /dev/hda6 40M Linux /files  (and /usr/src)
    /dev/hda7 40M Linux /files2
    /dev/hda8 23M Linux /files3
  Local Bus video (ET4000) and IDE.
  Linux 0.97p6, X11

When I first installed Linux I was occasionally getting HD-timeout errors.
It seemed that on a given session I would either get lots of them or
none of them, _maybe_ it had something to do with how full my /usr/src 
partition was.  These errors would sometimes cause filesystem corruption
(lots of 'block multiply referenced' or 'block not in any file' errors
reported by fsck), and once zorched my root partition (had to re-mkfs and
restore... yecch)

I tried setting HD_DELAY in hd.c (/usr/src/linux/kernel/blk_drv/hd.c)
to 500, that seemed to reduce the problem slightly but it did not go away.
I then set it to 1000, and haven't had a single HD-timeout error or
filesystem problem since.

+ David Peterson --------------------------+ The American Republic will last
| PrimeService, a Computervision Company   | until its  politicians discover
| peterson@primerd.Prime.COM               | that they can  bribe their  own
| peterson@warpdrive.Milford.MA.US         | people with their own money.   
+------------------------------------------+     -Alexis DeTouqueville, 1785
|
| Opinions expressed are mine, all mine, but they can become yours too for a
| small monthly fee.                                                        
Xref: sparky comp.os.mach:1480 comp.sys.next.programmer:6680
From: chase@stumpy.cs.orst.edu (A. Chase Turner)
Newsgroups: comp.os.mach,comp.sys.next.programmer
Subject: (answer) if_detach or if_unregistervirtual in NeXT OS 3.0 ( mach 2.5 ) ?
Keywords: if_detach
Date: 15 Oct 92 22:38:25 GMT
Article-I.D.: CS.1992Oct15.223825.5775
Reply-To: Chase_Turner@stumpy.cs.orst.edu
Organization: Oregon State University, Computer Science Dept

if_detach exists and is in the NeXT OS documentation.  Sorry for the 
net noise on this one...

chaseNeXT OS documentation.  Sorry for the 
Xref: sparky comp.os.mach:1478 comp.sys.next.programmer:6667
From: chase@stumpy.cs.orst.edu (A. Chase Turner)
Newsgroups: comp.os.mach,comp.sys.next.programmer
Subject: if_detach or if_unregistervirtual in NeXT OS 3.0 ( mach 2.5 ) ?
Keywords: if_attach, if_registervirtual, loadable kernel
Date: 15 Oct 92 16:50:05 GMT
Article-I.D.: CS.1992Oct15.165005.430
Reply-To: Chase_Turner@stumpy.cs.orst.edu
Organization: Oregon State University, Computer Science Dept

Under NeXT OS 3.0 (mach 2.5), I have written a packet sniffer implemented  
 
as a relocatable kernel.  My question is if there is something like an if_detach or if_unregistervirtual in mach 2.5....

After being allocated, loaded and running for awhile, I attempt to unload and deallocate the kernel.  kern_loader_unload_server invokes a signOff function (which returns kernel memory and unwires previously wired memory ranges) without a hitch.  And yet the packet sniffer continues to operate! 

Then, when I explicitly delete the loadable kernel (by executing kern_loader_delete_server), a kernel panic occurs as a packet is delivered to the (now removed) packet sniffer's receive function.

Is there an if_detach / if_unregistervirtual or some such to counter the effects of the if_attach and if_registervirtual?

chase_turner@stumpy.cs.orst.edu
Newsgroups: comp.os.mach