HDTenEightyP/NetNews huggingface dataset:
From: pss1@kepler.unh.edu (Paul S Secinaro)
Subject: Re: EISA and the abounding unix clones
Organization: University of New Hampshire  -  Durham, NH
Date: Wed, 12 Aug 1992 20:16:20 GMT

In article <1992Aug12.192445.20894@cbnewsc.cb.att.com> chapin@cbnewsc.cb.att.com ( Tom Chapin ) writes:
>
>Do any of these abounding clones speak EISA yet?  Will they?
>

Well, all I know is that Linux didn't like my 486/33 EISA system with
DTC 3290HD SCSI controller, which is supposed to be Adaptec 1542
compatible.  It seemed to detect the controller and read the partition
table properly when the bootimage was coming up, but then efdisk
failed with an error when it tried to open /dev/hda.  I don't know if
this is a general problem with EISA or just my controller.

Paul

-- 
Niven's Law #14:   There exist minds that think as well as you do, but
                   differently.
Niven's Corollary: The gene-tampered turkey you're talking to isn't
                   necessarily one of them.
Newsgroups: comp.os.linux
From: vince@halcyon.com (Vince Skahan)
Subject: reusing linux-ized disks for DOS
Organization: Northwest Nexus Inc. (206) 455-3505
Date: Wed, 19 Aug 1992 06:41:48 GMT

in cleaning up old versions dating back to 0.95a of boot/root floppies,
compiler images, etc. I notice that DOS5.0 seems unable to reformat a
linux-format (or image) floppy to DOS format.

is there any special magic required to get linux-ized floppies back
to a DOS format ???


-- 
          Vince Skahan				vince@halcyon.com (here)
    vince@atc.boeing.com (work)		    vince@victrola.sea.wa.us (home)

Newsgroups: comp.os.linux
From: hammond@kwhpc.caseng.com (Kevin W. Hammond)
Subject: Errors building tools/build.c
Reply-To: hammond@kwhpc.caseng.com (Kevin W. Hammond)
Organization: The Internet
Date: Fri, 14 Aug 1992 03:47:00 GMT

I installed the inc.tar.Z and 0.97pl1inc.tar.Z files you sent me under
/usr, as per your instructions.  Once again, I am performing the
build with 0.97 source (no patches) and GCC 2.2.2.  I also installed
type symlink from /usr/include/linux to /usr/src/include/linux/include.
I have not replaced the linux include files with the GCC 2.2.2 include
files as is indicated in the README.  I also have the -nostdinc in my
Makefile.

When the make reaches tools/build.c, the following errors occur:

In file included from tools/build.c:25:
/usr/include/stdlib.h:55: conflicting types for `div_t'
/usr/include/linux/types.h:68: previous declaration of `div_t'
/usr/include/stdlib.h:62: conflicting types for `ldiv_t'
/usr/include/linux/types.h:69: previous declaration of `ldiv_t'
In file included from /usr/include/unistd.h:188, from tools/build.c:29:
/usr/include/sys/utsname.h:16: `MAXHOSTNAMELEN' undeclared, outside of functions
/usr/include/sys/utsname.h:16: size of array `nodename' has non-integer type
In file included from /usr/include/unistd.h:191, from tools/build.c:29:
/usr/include/signal.h:14: parse error before `SignalHandler'
/usr/include/signal.h:14: warning: data definition has no type or storage class
/usr/include/signal.h:35: parse error before `signal'
/usr/include/signal.h:35: parse error before `__sighandler_t'
/usr/include/signal.h:35: warning: data definition has no type or storage class
tools/build.c: In function `main':
tools/build.c:90: `O_RDONLY' undeclared (first use this function)
tools/build.c:90: (Each undeclared identifier is reported only once
tools/build.c:90: for each function it appears in.)

What would be causing this problem?  I'm almost there....  unfortunatly I go on
vacation tomorrow and won't have a chance to test any corrections, but I'll
still be checking my mail to keep updated.

Thanks.

-kwh-
-- 
Kevin W. Hammond
hammond@kwhpc.caseng.com

                 Looking for a real operating system?  Try Linux.

  CASE Engineering * 575 W. Madison #1601 * Chicago, IL 60661 * (312)902-2161
Newsgroups: comp.os.linux
From: drew@kinglear.cs.colorado.edu (Drew Eckhardt)
Subject: Re: Memory mapped files?
Organization: University of Colorado at Boulder
Date: Thu, 13 Aug 1992 05:46:53 GMT

In article <1992Aug12.215042.5114@murdoch.acc.Virginia.EDU> lfoard@Turing.ORG (Lawrence C. Foard) writes:
>Is there any soft of project underway to implement memory mapped files
>in Linux? It seems that the shared library code is pretty close except
>that it doesn't support writting pages back to the library file.
>
>Has anyone looked into what would be involved?

Ideally, some one will implement something along the lines of a 
vnode based vm system, where each virtual memory object has a mapping
and certain characteristics associated with it.

That mapping could be to a file, to a device, etc.  Ideally, a file mapping
would be a mapping to blocks as specified by the file's bmap, with those
blocks shared with buffercache.  Shared libararies / mmap / sysV 
shared memory semmantics could be implemented on top of this 
internal structure, quite easily.

very similiar to what MACH uses.

>Along with this is there any reason to keep the 4giga byte total
>limit for processes rather than having seperate page tables for
>each process?

Not 4G per process.  You still want room for kernel space in the 
same page table, so you can keep most of the same code in place
for kernel<>user space transfers, with kernel and user space in 
different x86 segments. Linus has something going with
> 3G per process, with the remainder allocated to the kernel - 

-- 
Microsoft is responsible for propogating the evils it calls DOS and Windows, 
IBM for AIX (appropriately called Aches by those having to administer it), but neither is as bad as AT&T.  Boycott AT&T, and let them know how you feel. 

Newsgroups: comp.os.linux
From: corywest@rice.edu (Cory West)
Subject: Re: Buffer corruption problems.
Followup-To: comp.os.linux
Organization: Well, none really, but I know where my socks are!
	<BURLEY.92Aug13153840@geech.gnu.ai.mit.edu>
Date: Fri, 14 Aug 1992 00:09:39 GMT

In article <BURLEY.92Aug13153840@geech.gnu.ai.mit.edu> 
burley@geech.gnu.ai.mit.edu (Craig Burley) writes:

>  ...I believe there is a bug in Linux that has the following behavior:
>
>  -  causes Linux to "misread" one 1024KB chunk of data from a disk-based file
>     so that what your app ends up with is some _other_ 1024KB chunk
>     (apparently from the same file)
>
>  -  occurs only during very heavy disk access, such as megabytes accessed
>     continually
>
>  -  is intermittent, but happens enough to reproduce fairly easily
[Etc...]

	I have noticed some abnormalities, but I have been writing them
off to a disk block in the process of going bad.  Here's what I have
noticed:

	- Under heavy and prolonged disk I/O (in this example, while compiling
gdb from scratch) there seem to be problems with the buffer cache.  After 
compiling for a while, gcc will choke with a TON of strange errors and die.
However, if I just restart make, the compiler will continue successfully
with the file that it had just died on, but it will die a little later 
down the line (after some more intensive I/O) under the same circumstances.
After a couple of tries, I can usually get through the entire make.

	- I am running on MFM drives on a 486-33 with 4 Megs RAM (gcc 2.2.2d and
gcc 2.2.2 and Linux 0.97 PL1), so while compiling large things, my disks never 
stop to breath, especially if I am trying to do something else while the compile 
is running.

	- The errors always include the same file (which is why I thought
perhaps that that particular file was living on a disk block that was going
belly up.  I plan to rename that file to .deadblock and putting a new copy
of the file in the directory to test this theory).  I am also going to run some
more large compiles to see if I can reproduce this error elsewhere in the 
system.

	I don't know what it is yet, and I'm not sure if it's anything, but
I'll see what I can reproduce and hopefully we can determine if this is an
OS bug or a hardware bug and whether or not it has anything to do at all with
the above problem.

	Anyone else out there having problems?



					Cory West
					corywest@rice.edu
From: hedrick@athos.rutgers.edu (Charles Hedrick)
Newsgroups: comp.os.linux
Subject: Re: problems getting X running
Date: 20 Aug 92 02:38:34 GMT
Organization: Rutgers Univ., New Brunswick, N.J.

rgb@esleng.ocunix.on.ca (Richard Briggs) writes:

>Hi Linux'ers:

>Any time I try to initialize, the screen goes dead and a terminal on a serial
>port is the only feedback I've been able to get aside from capture files. 

When I've seen this happen, it's been because Xconfig did not define
a valid configuration.  There must be at least one line in the Modedb
section where

  - the mode at the beginning of the line, e.g. "1024x768", 
	matches the mode listed in the Modes line.
  - the dot clock (the number immediately following the mode)
	matches one of the clocks in the Clocks line.  Or
	if there is no Clocks line, one of the clocks that X386
	figures out for itself.

If more than one mode is listed in the Modes line, there must be
a matching line for each one.

I believe your problem is that you do not have a Modes line.
Newsgroups: comp.os.linux
From: Upholder@uiuc.edu (THE Upholder of Truth)
Subject: Re: 64Mb on HD limit?
Reply-To: Upholder@uiuc.edu (THE Upholder of Truth)
Organization: The University of Illinois at Urbana-Champaign (UIUC)
Date: Sun, 16 Aug 1992 22:51:20 GMT

ce12+@andrew.cmu.edu (Christopher Aaron Ekberg) writes:

>Hello,

>I read someplace that there is (was?) a limit of 64Mb hard disk space
>for Linux.  If I didn't just dream that, is that still true for 0.97?  

The 64M partition limit is due to the use of Minix style filesystems.
The Extended filesystems allow up to 4 TERAbyte partitions and up to
255 characters in files (the minix fs only allows 14 char file names).

One word of warning: The extended fs is in alpha test...

However, I've not had one problem with them at all (using one for root
and one for /usr).
-- 
The Upholder of Truth		  	    I am not only ready to
Upholder@uiuc.edu (BSD/ASCII mail)          retract this, but also
jar42733@sumter.cso.uiuc.edu (NeXT mail)    deny I said anything.  =)
wi.4173@wizvax.methuen.ma.us (anon. mail)   This is *NOT* CCSO's opinion.
Newsgroups: comp.os.linux
From: almesber@nessie.cs.id.ethz.ch (Werner Almesberger)
Subject: Re: loadable device drivers
Organization: Swiss Federal Institute of Technology (ETH), Zurich, CH
Date: Thu, 13 Aug 1992 15:10:40 GMT

In article <2659@nlsun1.oracle.nl> jhelberg@nl.oracle.com (Joost Helberg) writes:
> Far too long, and you have to reboot too! i.e. all users have to 
> get coffee or tea!

You're developping new drivers while users are working on your machine ?
Poor users ... ;-)

> The kernel must be mapped when implementing loadable device drivers (to
> get page-faults) so the kernel doesn't need contiguous memory --> less
> problems allocating memory.

Page-faults are deadly for most parts of the kernel. Unless the interrupt
handling is changed in radical ways (see below), you don't want interrupt
handlers and code that's called by them to reside in paged memory. (Besides
the obvious case of device drivers that may be possibly invoked when
handling a page fault.)

Using the paging hardware to map kernel pages is a good idea, though.

> - The kernel will never use more core than necessary. Only text/data really
>  used will be in core (that is using LRU algorithms). 

Yes, but you need interrupt queues and an interrupt scheduler to be able
to accept interrupts from devices that can send more than one interrupt
per interaction (i.e. SIOs) even if you have to fault in the driver first.
Might be hairy to implement, although it looks like a very elegant
solution for most interrupt problems.

You also need a way to lock certain kernel areas in physical memory.
(MM, at least one FS, scheduler, hd driver, some other kernel data
structures, drivers for devices that expect a low interrupt latency, etc.)
 
> - Updating a driver can be done at runtime shortening the development time
>  of driver enhancements.

Certainly a big win, especially on slow systems where a compile-reboot-
test-fail-edit-...-cycle is significantly longer than 45 seconds. Even
a mechanism where you'd have to compile stubs into the kernel but could
load the actual code at run time would be useful.

An even more important use would be dynamic system configuration, e.g. one
could use local drivers without patching them into each kernel release.
(Needs probably some changes to the way existing driver are called.)

- 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_/
From: eric@tantalus.dell.com (Eric Youngdale)
Newsgroups: comp.os.linux
Subject: Re: Linux Logo
Date: 12 Aug 92 23:07:39 GMT
Organization: Naval Research Laboratory

In article <CORYWEST.92Aug12161500@rio-grande.rice.edu> corywest@rice.edu (Cory West) writes:
>	Ghostscript pulled it up fine for me and I like it!  I don't 
>like having the Version number in becuase it means we'll have to update
>the logo every Saturday :-), but other than that it's cool and I'd
>love to see it included in manuals and the such :-).

	Well ghostscript barfs when I try it.  Is there some secret??
I am using gs on a SVr4 machine, since I do not yet have gs on my linux
machine.

-Eric

	Here is the mess that gs left:

bash$ gs linux-1.ps
Initializing... done.
Error: /typecheck in --and--
Operand stack:
    -savetype-  true  false  55665
Execution stack:
    operator_804c220    --nostringval--  --nostringval--  false  --nostringval--  --nostringval--  false  --nostringval--  --nostringval--  --nostringval--  --nostringval--
Dictionary stack:
    337/401  4/200
Ghostscript 2.3  Copyright (C) 1990, 1991 Aladdin Enterprises,
   Menlo Park, CA.  All rights reserved.
Distributed by Free Software Foundation, Inc.
Ghostscript comes with NO WARRANTY: see the file COPYING for details.
GS<4>


--
Eric Youngdale
eric@tantalus.nrl.navy.mil
Newsgroups: comp.os.linux
From: andre@sun.ac.za (ANDRE SKARZYNSKI)
Subject: Re: reusing linux-ized disks for DOS
Date: Thu, 20 Aug 92 12:07:17 GMT
Organization: Electronic Engineering, University of Stellenbosch, South Africa

In article <1992Aug19.064148.9940@nwnexus.WA.COM> vince@halcyon.com (Vince Skahan) writes:

>in cleaning up old versions dating back to 0.95a of boot/root floppies,
>compiler images, etc. I notice that DOS5.0 seems unable to reformat a
>linux-format (or image) floppy to DOS format.

Are you sure your drive is okay ? There shouldn't be any problems. Try an 
unconditional format, format a:/u. 

>is there any special magic required to get linux-ized floppies back
>to a DOS format ???

Try passing the disk over a magnet a few times, and then try reformating it.

>-- 
>          Vince Skahan                          vince@halcyon.com (here)
>    vince@atc.boeing.com (work)             vince@victrola.sea.wa.us (home)

Newsgroups: comp.os.linux
From: jofre@socrates.umd.edu (Jaime Jofre)
Subject: Is XView 3.0 available for Linux/X386 ????
Organization: University of Maryland University College
Date: Tue, 18 Aug 1992 01:21:13 GMT

Hello everyone,
  Has anyone ported the XView 3.0 library for Linux/X386?  If no, is anyone
porting it to Linux?  Thanks,

Jaime Jofre
  
Newsgroups: comp.os.linux
From: jhuang@Chaos.mcs.kent.edu (Jing Huang)
Subject: Need Help: TeX
Organization: Kent State University
Date: Fri, 14 Aug 1992 17:12:31 GMT

	Hello everyone.

	I recently downloaded the TeX stuff from 129.78.66.1 (the Australia
site) and followed the instructions in the README.222 file, and got it
installed.

	I thought that I was about to fly. But when I ran "latex foo" or
"tex foo", I got the following greetings:

------------------------------------------------
This is TeX, C Version 3.141
I can't find the default format file!
------------------------------------------------

The first line is fine, but the second line ruined my whole day.

	I looked around the directories and found that all the format files
"xxx.fmt" were there under the "/usr/local/lib/tex/formats" directory.

	So, what did I do wrong? How come TeX didn't like me. :-(

	Could someone please help me out here?

--
Jing Huang  |  jhuang@Chaos.mcs.kent.edu
Department of Physics
Kent State University
Kent, OH 44242
From: zlsiial@uts.mcc.ac.uk (A. V. Le Blanc)
Newsgroups: comp.os.linux
Subject: Re: Can't fdformat
Date: 13 Aug 92 07:11:39 GMT
Reply-To: LeBlanc@mcc.ac.uk (A. V. Le Blanc)
Organization: Computing Centre, University of Manchester

In article <1992Aug12.044400.590@pool.info.sunyit.edu> ujlh@pool.info.sunyit.edu (James Henrickson) writes:
>I've got a question.  Will we always have at0, or will that eventually
>be dropped in favor of autodetecting with fd0?

There are three points here:

(1)  The name 'at0' is very obsolete; get rid of it, or if you wish to have
     it on your own system out of sentimental reasons, please don't use
     it in messages which are read by innocent, confusable novices.
     No flame is intended.

(2)  Autodetecting will probably never do everything; autodetecting with
     setfdparms can do just about everything now, assuming your CMOS is
     se up correctly.

(3)  The operating system will probably continue to support fd devices
     other than fd0 and fd1 for some time, unless Linus decides to
     clean it all out with space-saving efficiency.

     -- Owen
     LeBlanc@mcc.ac.uk
From: magidj@cellbio.duke.edu (Jonathan Magid)
Newsgroups: comp.os.linux
Subject: Re: NEW linux ftp site (banjo ressurected)
Date: 14 Aug 92 03:08:57 GMT
Organization: Duke University Medical Center, Dept. of Cell Biology

In article <2178@fnnews.fnal.gov> rohrer@fncrd6.fnal.gov (Keith Rohrer) writes:
>In article <4514@news.duke.edu> magidj@cellbio.duke.edu (Jonathan Magid) writes:
>[deleted]
>>This ftp site is trying to be compliant with the IAFA guidelines on archives, 
>>which are (imho) Good Things. 
>>[DELETED]
>Could *you* make those incoming description files, or a digest of them
>per directory, available to us the downloaders?  
>[DELETED]


Yep.  They should all be available in IAFA-PACKAGES in the appropriate
directories, once
a)i get everything organized
and
b)people actually take the trouble to write them.

a) is coming soon. b) i can only cross my fingers. :)

jem.
-- 
Jonathan Magid     jem@reggae.oit.unc.edu
Virtual pizza Delivery (tm)::faxed in 30 cycles or less or you get it
----------------------------------------FREE!!!-----------------------
From: benjie@quack.sac.ca.us (Andriod)
Newsgroups: comp.os.linux
Subject: Where can I get a copy of linux os and how big is it
Date: 14 Aug 92 03:40:36 GMT
Organization: The Duck Pond public unix: +1 408 249 9630, log in as 'guest'.

Can anyone tell me where I can get a copy of linux os and how big it
is(in megs)?
Thanks
Ben

-- 
     BBB		Benjie Chen
    BCCCB 		benjie@quack.sac.ca.us
    BCCCB		No Axiomatic System Could Produce All Number-
     BBB		Theoretical Truths, Unless It Is Inconsistent.
From: davidsen@ariel.crd.GE.COM (william E Davidsen)
Newsgroups: comp.os.linux
Subject: Re: xsetroot
Date: 19 Aug 92 15:14:33 GMT
Reply-To: davidsen@crd.ge.com (bill davidsen)
Organization: GE Corporate R&D Center, Schenectady NY

In article <1992Aug19.092241.7677@monu6.cc.monash.edu.au>, int177c@aurora.cc.monash.edu.au (Jae Won) writes:
| Hi,
| 
| 	I am just wondering if there is a port of xsetroot to X386 yet. If there is
| where can I find it? I couldn't find it with the X386 distribution(version 1.0)

  I'm getting a bunch of stuff to upload to the ftp sites, ported by a
new Linux convert. Xsetroot may be among them. I know he did the icon
editor and a few other things (antfarm?) in the last week. I expect to
get a bunch of stuff from him on disk this weekend and will upload it
when I do.

-- 
bill davidsen, GE Corp. R&D Center; Box 8; Schenectady NY 12345
    I admit that when I was in school I wrote COBOL. But I didn't compile.
From: drew@kinglear.cs.colorado.edu (Drew Eckhardt)
Subject: Re: A few basic questions...
Organization: University of Colorado at Boulder
Distribution: na
Date: Wed, 19 Aug 1992 17:38:30 GMT

In article <7873@lee.SEAS.UCLA.EDU> liebgold@mott.seas.ucla.edu (Dan M. Liebgold) writes:
>
>Greetings fellow linux do-it-yourselfers...
>
>I have a few questions that probably been answered, but not in the FAQ.
>First, is the only way to get the kernel for shoelace to grab the
>source and compile it yourself? 

No, just dd it out to /vmunix or whatever you want to use.

>Next, I have a trident card and a bus mouse, so there is currently no
>windowing system readily available for me, or so it seems. Is there anywhere
>to get the patched X386 (for trident) BINARY? How about a bus mouse driver

No, and from the discussion on the X11 channel, it's not entirely stable
yet.  

>for MGR?

You probably already have one - .97 has a bus mouse driver in the kernel.
Try 

mknod /dev/mouse c 10 0
-- 
Microsoft is responsible for propogating the evils it calls DOS and Windows, 
IBM for AIX (appropriately called Aches by those having to administer it), but neither is as bad as AT&T.  Boycott AT&T, and let them know how you feel.
Newsgroups: comp.os.linux
Subject: Re: Buffer corruption problems.
From: zuazaga@ucunix.san.uc.edu (Humberto Ortiz-Zuazaga)
Date: Fri, 14 Aug 92 01:31:30 GMT
 <BURLEY.92Aug13153840@geech.gnu.ai.mit.edu> <CORYWEST.92Aug13180939@rio-grande.rice.edu>
Organization: University of Cincinnati
Keywords: HD: read_intr:, errors
Summary: HD-controller reset in BIG compiles

In article <CORYWEST.92Aug13180939@rio-grande.rice.edu> corywest@rice.edu (Cory West) writes:
>In article <BURLEY.92Aug13153840@geech.gnu.ai.mit.edu> 
>burley@geech.gnu.ai.mit.edu (Craig Burley) writes:
>
>>  ...I believe there is a bug in Linux that has the following behavior:
>>
>>  -  causes Linux to "misread" one 1024KB chunk of data from a disk-based file
>>     so that what your app ends up with is some _other_ 1024KB chunk
>>     (apparently from the same file)
>>
>>  -  occurs only during very heavy disk access, such as megabytes accessed
>>     continually
>>
>>  -  is intermittent, but happens enough to reproduce fairly easily
>[Etc...]
>
>	- Under heavy and prolonged disk I/O (in this example, while compiling
>gdb from scratch) there seem to be problems with the buffer cache.  After 
>compiling for a while, gcc will choke with a TON of strange errors
and die.

I get a series of "HD: read_intr: status = 0x59", "HD: read_intr:
error = 0x10" followed by an "HD-controller reset" on an odball
Western Digital + Seagate IDE when doing big compiles ever since 0.96.
The compilations proceed without error, however.

>	- The errors always include the same file (which is why I thought
>perhaps that that particular file was living on a disk block that was going
>belly up.  I plan to rename that file to .deadblock and putting a new copy

It may be the same file, if compiling the file excercises the bug (not
reading it, compiling it). Check to see how much memory is used during
the compile, or turn off optimization?
-- 
Humberto Ortiz-Zuazaga                            zuazaga@ucunix.san.uc.edu
Dept. of Physiology & Biophysics                   University of Cincinnati