HDTenEightyP/NetNews huggingface dataset:
From: ching@angelo.amd.com (Mike Ching)
Newsgroups: comp.os.linux
Subject: Re: AMD-40 Cycle Timing Problems
Keywords: amd cpu
Date: 18 Aug 92 18:06:50 GMT
Organization: Advanced Micro Devices, Santa Clara, CA

In article <1992Aug15.230511.14243@mintaka.lcs.mit.edu> knight@hal.gnu.ai.mit.edu (Knight of Tossing and Turning) writes:
>
>Sorry this took forever to jump into this conversation but I figured it
>wasn't going to freak so many people out.
>
>I was instructed in my PC Archetecture class that the AMD-40 CPU (and
>only that CPU) has a relatively minor problem with timing between
>certain cycles.  I'm not sure which combination of instructions causes
>the problem, and I'm not in a position to find out.
>
>If someone looks this up, it is a documented bug.  However, I don't
>have the AMD CPU manuals to look it up.
>
>The reason this is only for the 386-40 is because it is basically a
>superscaler CPU (like a 486-2DX50) consisting of something like
>2-25 MHz chips.  I'm not really into the hardware aspect of personal
>computers, so don't ask me much more than this.  But is basically
>timing between the two where the bug occurs.
>
>As the guy with the flat-hat says, "A PC that is MS-DOS compatible
>might not be UNIX compatible, but any that is compatible with UNIX
>will run probably anything."
>
>--- Eric Knight


No one has bothered to correct this so I guess I will. The information
in this posting is wrong. The Am386 does not have a documented bug in
the manuals. Neither the Am386 nor the 486DX2 are superscalar.

On a related topic, there is a design problem on the motherboard if
the Am386 is getting hot. If the core logic chip is also getting hot,
it's pretty likely that there is bus contention. On a properly designed
motherboard the Am386 is barely warm to the touch.

Mike Ching
AMD Field Applications
Newsgroups: comp.os.linux
From: almesber@nessie.cs.id.ethz.ch (Werner Almesberger)
Subject: LILO: Version Alpha.4
Organization: Swiss Federal Institute of Technology (ETH), Zurich, CH
Date: Sat, 15 Aug 1992 21:50:46 GMT

A new alpha test version of LILO can be found on reggae.oit.unc.edu in
pub/pc-stuff/Linux/Incoming as lilo.s.4.tar.Z and lilo.b.4.tar.Z

lilo.s contains source, documentation and support files.
lilo.b contains pre-compiled binaries without source, documentation
and support files. /lib/libc.2.2.2 is needed to run the pre-compiled
executable of the map installer.

(I've also deleted an older, now really obsolete versions.)

This release contains many minor improvements. The most important ones
are a configurable boot delay, a tool to determine SCSI disk parameters
and some protection against weird include file conflicts.

The beginning of the CHANGES file is at the end of this posting.

A few people have reported problems when trying to boot other operating
systems (usually MS-DOS) with LILO, while others report that everything
works. I haven't solved the problem yet, but I'd suggest to use BOOTACTV
(or any other boot switcher) as a temporary work-around, where needed.

- Werner

---------------------------------- cut here -----------------------------------

Changes from version 3 to 4
---------------------------

  Boot sector
  -----------

    - added a configurable delay.
    - added a diagnostic title message.

  Map installer
  -------------

    - fixed all known include file conflicts.
    - added support for variable block sizes. (Not used yet.)
    - added some more sanity checks.
    - added a tool to determine SCSI disk parameters.

  Documentation and installation
  ------------------------------

    - extended coverage of SCSI disks.
    - make install  now backs up chain.b and boot.b of any older LILO
      installation. (To say: your system remains bootable even if you
      forget to run /etc/lilo/install after the update or if this fails
      for some reason.)
    - moved the changes section from README into CHANGES.
    - a set of pre-compiled executables of lilo, boot.b, chain.b and
      dparam.com is available too.
-- 
   _________________________________________________________________________
  / 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: klaus%elc692.dnet@esu36.cfsat.honeywell.com (Let there be MORE light!)
Subject: (none)
Reply-To: klaus%elc692.dnet@esu36.cfsat.honeywell.com (Let there be MORE light!)
Organization: The Internet
Date: Wed, 19 Aug 1992 15:09:11 GMT


[stuff deleted...]

#>Building kernels is not necessarily great fun.  Once you do a few, it
#>gets kind'a boring doesn't it?  I think making patched compiled kernels

#Of course it's not fun.  However, with all the changes floating around,
#there's no way to guarantee compatibility for all the old library calls 

I sure hope Linus doesn't feel this way! :-)


tk

Newsgroups: comp.os.linux
From: sakaria@vipunen.hut.fi (Sakari Aaltonen)
Subject: Jump Tables: A Mystery
Reply-To: sakaria@vipunen.hut.fi (Sakari Aaltonen)
Organization: Helsinki University of Technology
Date: Sat, 15 Aug 1992 08:52:44 GMT


Several people responded to my recent whining about shared libraries
by mentioning "jump tables".

Jump tables?

Is there a book or an article that explains the structure of shared
libraries and of programs using them? I, too, would like to understand
jump tables. I just can't find anything on them in Tanenbaum.

My impression now is that shared libraries are something like MS-Windows
dynamic link libraries. "Dynamic" seems a good description, as a matter
of fact - code that is loaded into memory dynamically, at runtime.

However, I think you can change MS-Windows DLL's as often as you like
without recompiling or relinking the programs that use the libraries.
You just have to keep the name of the DLL and the indexes of the functions
therein the same, because the calling programs refer to the functions by
library name (LINUX.DLL, say) and index (96, say). I don't know whether the
name of the function matters.

Why can't shared libraries be like that?


-- 
-----------------------------------------------------------------------------
Sakari Aaltonen                             Helsinki University of Technology
Email: sakaria@vipunen.hut.fi
---  You can't keep a Finn down without him getting all red in the face  ----
From: davidsen@ariel.crd.GE.COM (william E Davidsen)
Newsgroups: comp.os.linux
Subject: Re: Troubles compiling lilo v3
Date: 14 Aug 92 15:24:02 GMT
Reply-To: davidsen@crd.ge.com (bill davidsen)
Organization: GE Corporate R&D Center, Schenectady NY

In article <1992Aug14.024317.19775@inmet.camb.inmet.com>, newbie@dylan.camb.inmet.com (Chris Newbold) writes:

| Anyhow, I'm having major trouble compiling it. There is a massive conflicy
| between the linux/include types.h and the include/sys/types.h ... I'm sure
| all of this was covered... If someone would be kind enough to point me
| in the right direction, I would really appriciate it.
| 
| The problems: Both /usr/src/linux/include/linux/types.h and /usr/include/sys
| /types.h get included. I tried to fix this by linking /usr/include/sys
| to /usr/src/linux/include/linux. This seems like a hack, but I don't really
| know. Didn't reall help.

  I think you are hitting one of the real problems at this time, you
need different includes for a lot of stuff, and if everyone would get to
a common set of headers life would be a lot nicer, and development might
go a bit faster.

-- 
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: tytso@ATHENA.MIT.EDU (Theodore Ts'o)
Newsgroups: comp.os.linux
Subject: My apologies *again* for another mail loop....
Date: 15 Aug 92 03:08:23 GMT
Reply-To: tytso@ATHENA.MIT.EDU (Theodore Ts'o)
Organization: The Internet

My apologies *again* for another mail loop.  This time it was a site at
GE.COM that was at fault.  And, like last time, I've removed the
misbehaving address from the list until they can prove to me that
they've fixed the problem. 

Can someone investigate and let me know if someone has released some
sort of bogon, untested mailer from Mars on the net recently?  This is
the second time this week, which is getting suspicious.

Thanks again for your patience.......

							- Ted
From: copernicus@digund.uucp (Copernicus) 
Newsgroups: comp.os.linux
Subject: How safe is Mtools?
Date: 18 Aug 92 19:32:00 GMT
Distribution: world
Organization: Digital Underground - PRIVATE
Reply-To: copernicus@digund.uucp (Copernicus) 

To: rwb@Turing.ORG

RWBC:>Hey,
RWBC:>        Can anyone tell me just how safe it is to use mtools on my 130 meg
RWBC:>dos partition?  I don't want to have to go the expensense of messing it
RWBC:>up.  I have been hesitant in the past, so I just use a floppy.  It would
RWBC:>make things much easier if there is no real chance of damage being done.

RWBC:>Thanks,
RWBC:>Rob

Well I have been using MTOOLS on my SEVERELY hacked 0.97pl1.5 system.
On this system I have installed the extended file system, the dos file system
extension for mounting dos partitions and I have yet to experience ANY
problems with any of the packages so far.  Ive been using MTOOLS for about
3 weeks daily without any problems.  Works great.  Fast too!

Chris Nalley / copernicus%digund@coplex.com
---
 . SLMR 2.1 . Digital Underground - A Copernician Corporation
From: tytso@ATHENA.MIT.EDU (Theodore Ts'o)
Newsgroups: comp.os.linux
Subject: Re: New version of the serial driver....
Date: 20 Aug 92 05:17:15 GMT
Reply-To: tytso@ATHENA.MIT.EDU (Theodore Ts'o)
Organization: The Internet


   Date: Thu, 20 Aug 92 01:00:39 -0400
   From: tytso@Athena.MIT.EDU (Theodore Ts'o)

   I've uploaded diffs for some changes that I've made to the serial
   driver.

I just realized I forgot to mention *where* to find said changes.  Oops,
sorry about that!  They can be found on tsx-11.mit.edu, in the directory 
~ftp/pub/linux/ALPHA/serial.

						- Ted
From: iiitac@cybaswan.UUCP (Alan Cox)
Newsgroups: comp.os.linux
Subject: Re: AMD386 and LINUX
Date: 18 Aug 92 18:40:52 GMT
Organization: No way!

In article <4759@blue.cis.pitt.edu.UUCP> broadley@neurocog.lrdc.pitt.edu writes:
>As far as I know there are no documented bugs in the AMD 386.
>
>If there were you would be sure that INTEL would brag about em.
>
>I have run all the tests mentioned and has absolutely no problem
>with my motherboard with AMD396-40.  
>
>I often use my machine hard and leave it processing for more then a
>day.

I run Linux on to AMD386DX machines a 33 and a 40. The 386DX40 has been 
running Linux continuously for over a month with the only reboots being
for OS upgrades. It's also often fairly busy as its an amateur radio
network node running a modified KA9Q with all the amateur radio stuff
enabled. 

Reminds me: ka9q.4 for linux runs all the radio stuff fine just for reference.
Newsgroups: comp.os.linux
From: arthuro@rosa.nbr.no (Arthur N. Olsen)
Subject: INSTALL PROBLEMS SCSI ?
Keywords: LINUX INSTALL SCSI NOKIA M356
Organization: The National Library, Rana, Norway
Date: Mon, 17 Aug 1992 15:39:51 GMT

As a complete beginer regarding Linux I tried an installation with the boot
image ( 0.97 ) from nic.funet.fi. My configuration is as follows:
Nokia m356 ( once Finnish now ICL)
33MHZ 386
Adaptec 1542b SCSI controller
110 MB disk
12 MB memory
After generating the boot diskett and booting, the kernel loaded with the 
following pertinent messages:
Unexpected HD IRQ
Three times
Adaptec 15421 detected  ( maybe not exactly that)
Unexpected HD IRQ 
I have read through the FAQ, ftp'ed some info from Colorado and looked at 
the Info at MCC. My guesses are that I have to change the IRQ of the SCSI
controller from the factory setting ( YUK no info about the SCSI card from
Nokia). Any useful information would be much aprechiated. 
  Arthur N. Olsen                  Nasjonalbibliotekavd. i Rana
  Senior Executive Officer         The National Library, Rana Norway
  Systems Development              " The furthest north of any national
  E-MAIL arthuro@rosa.nbr.no         library in the world: 66:30 N ! "

Newsgroups: comp.os.linux
From: trussell@cwis.unomaha.edu (Tim Russell)
Subject: Re: The Third Degree
Keywords: questions
Organization: University of Nebraska at Omaha
Date: Sat, 15 Aug 1992 14:44:02 GMT

cummings@hammer.Prime.COM (Kevin Cummings) writes:

>YES INDEED.  I haven't had the time to work on this stuff lately, but a timeout
>would definately be useful.  (Especially one with a configurable default, but
>then again I haven't looked at 0.97 or 0.97pl1, shame on me).

    0.97 has an option to preset the VGA mode, so the question just goes right
past.  It's not a timeout, alas, but at least the system doesn't hang every
time it comes up..

--
    Tim Russell                 Omaha, NE              trussell@unomaha.edu
One of the richest men in the world made his billions selling a toy "operating
system" that is more accurately described as a glorified bootstrap loader.
                                                  -- Phil Karn
Newsgroups: comp.os.linux
From: bhenning@wimsey.bc.ca (Bill Henning)
Subject: Re: AMD386 vs. Intel386 & external cache problems
Organization: Wimsey 
Date: Sat, 15 Aug 1992 04:13:26 GMT

In article <1992Aug14.084810.20876@news.th-darmstadt.de> herr@iti.informatik.th-darmstadt.de (Gabor Herr) writes:
>In article <1992Aug12.190649.7668@athena.mit.edu>, tytso@ATHENA.MIT.EDU (Theodore Ts'o) writes:
>
>...
>
>> Well, have a AMD 386 40 MHz motherboard, ETEQ chipset, 128k cache, 16 MB
>> memory --- and I haven't had any problems at all.  Perhaps your board
>> was just defective; did you try asking your dealer to swap your
>> motherboard for another one with the same configuration?
>> 
>> 							- Ted
>
>How do you explain the same errors on two completely different mainboards? The
>boards I tested had only one common factor: the AMD 386. 
>
>Gabor
>
>
>############################################################################
>Gabor Herr			Email: herr@iti.informatik.th-darmstadt.de
>Computer Science Department
>Technical University of Darmstadt, Germany

I am also running Linux quite succesfully (along with OS/2 2.0) on an Opti
motherboard (AMD386/40, 64k cache, Opti chipset).
From: jjb0391@tm0006.lerc.nasa.gov (James J. Bahm)
Newsgroups: comp.os.linux
Subject: Getting Started...
Date: 13 Aug 92 16:30:00 GMT
Distribution: usa
Organization: NASA Lewis Research Center / Cleveland, Ohio
News-Software: VAX/VMS VNEWS 1.41

Hello Linux Folks :

I am new to Linux and wish to run it at home.  I am having difficulty
trying to figure out how to install it on my machine.  The instructions
that I have are for VER 0.95 and I was wondering what is needed to
install VER 0.97.  Could someone give me a detailed install instruction
list or point me to one which I have yet to find.

Jim Bahm
JJB0391@TM0006.LERC.NASA.GOV
From: simonich@uservx.plk.af.mil
Newsgroups: comp.os.linux
Subject: GCC 2.2.2d omission?
Date: 16 Aug 92 15:32:04 GMT
Article-I.D.: uservx.1992Aug16.153204.35658
Organization: Phillips Laboratory - Kirtland AFB

I notice that GCC.2.2.2d README lists binutils.tar.Z as being 
in the release but I can't find it.  Is this an oversight or
are we just supposed to compile binutils.src?
From: tytso@ATHENA.MIT.EDU (Theodore Ts'o)
Newsgroups: comp.os.linux
Subject: Re: Linus security/Non root access
Date: 21 Aug 92 03:20:39 GMT
Reply-To: tytso@ATHENA.MIT.EDU (Theodore Ts'o)
Organization: The Internet


   From: erc@unislc.uucp (Ed Carp)
   Date: 21 Aug 92 02:06:26 GMT

   Hmmm...you could hack the loader to refuse to load the kernel from
   diskette - that might be easier than spending the $$$ to get a machine with
   a password protected BIOS.  If someone booted MS-DOS from a diskette,
   it wouldn't do them any good, anyway, 'cause you can't read a linux
   partition from MS-DOS.  Not yet, anyway... :)

   The loader code is in /usr/src/linux/boot/bootsect.S

Yes, but the boot loader is part of what you load from the floppy.  How
are you going to control what randoms stick into a floppy and boot?
After all, anyone who downloaded a copy of bootimage-0.97 would quickly
get around your suggestion.  

As I mentioned in private mail, if you're worried about attacks where
people are inserting their own boot disks into your public access linux
machines, the only way you can prevent this is to get a new BIOS, since
it is the BIOS that decides what software to boot.  Presumably, you can
trust the BIOS and your hard disk to contain what you wish --- but you
can't control what will be on the boot sector of the floppy that someone
sticks in your computer.

						- Ted
From: arumble@extro.ucc.su.OZ.AU (Anthony Rumble)
Newsgroups: comp.os.linux
Subject: Re: Modem dial-in procedures needed
Date: 16 Aug 92 02:42:24 GMT
Organization: Sydney University Computing Service, Sydney, NSW, Australia

lfoard@Turing.ORG (Lawrence C. Foard) writes:

>In article <1992Aug13.052324.8490@athena.mit.edu> chchen@stat.fsu.edu writes:
>>I've seen several discussions about modem dial-in for Linux system. I
>>got two unsolved questions here:
>>
>>I will be greatly appreciated if someone can post his whole procedures
>>to allow modem dial-in.

>The best approach if you are dedicating your modem to this is to
>set the parameters and save them in the modems non volatile
>memory. If I remember right I have the following set-
>echo off
>hangup on dtr being dropped
>no result codes
>answer on one ring

>I saved these and then turned on the switch that makes it ignore
>at commands. This prevents the computer sending garbage to the modem
>and making it do weird things.

This isn't the best way of doing things, as soon as I clean up my
Modem Server, ill post it.. The only problem I am having with it at the moment
is that for some reason, the MNP init characters being sent by the calling
modem seems to make the TTY go wierd, and hang up the modem?!?!?
Haven't worked that one out yet, when I do, ill post it..

>One possible problem you may run into is that getty doesn't hold
>DTR down for long enough, if your modem doesn't always hang up you
>can make a shell script-
>getty1
>#!/bin/sh
>sleep 10
>exec /bin/agetty $*

>this will hold dtr down for 10 seconds.

Also.. Another funny thing ive found, is that if people Drop CArrier..
It usually kills the program that their in.. But NOT the SHELL!!!

Ie.. Say there in ELM, and their line dropps out.. ELM quits fine
But the Shell is still there!.. Echoing to the modem forever, or
until I kill the process..

Is there anything that can be done about this anyone??
-- 
Anthony Rumble
aka SmilieZ
"Anything is possible.. If there is enuf money in it"
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: executables in linux
Date: 13 Aug 92 13:37:00 GMT
Organization: University of Helsinki

In article <1992Aug12.225538.16085@usenet.ins.cwru.edu> mdr4@po.CWRU.Edu (Mark D. Rutherford) writes:
>
>I'm currently running linux .95.  Several times now, I've FTP'd
>something, tar'd it to floppy, and then untar'd from linux,
>and tried to execute what I've untar'd.  I get the message,
>"Cannot execute binary file"  The directory listing for the file
>says that it's executable, and it's docs say it's executable.
>I'm sure it's something simple that I'm missing.  Can anyone help?

While I have tried to keep each new kernel backwardsly compatible (ie
running most old binaries, excepting things like ps and in some cases
gdb), it's /not/ the case the other way around - binaries compiled with
a new compiler may not work on an older kernel.  There have been several
changes in this direction: the header information changed somewhere
along the way (the old headers were still accepted, but old kernel
versions didn't accept the new headers) and new features (extended stat
structure etc) have made binaries unrunnable on older kernel versions. 

So the answer is to upgrade your kernel: if possible all the way to
0.97.pl1 + the one-line patch due to performance reasons, but 0.96c or
similar should work very well for your needs.

		Linus
Newsgroups: comp.os.linux
From: pmacdona@sanjuan (Peter MacDonald)
Subject: SLS typo, and an antecedent to device drivers
Organization: University of Victoria, Victoria, BC, CANADA
Date: Sat, 15 Aug 92 22:31:04 GMT

Oops.  Forgot to point out the typo in my original SLS post.
The disk sizes should have read

Minimal: 6 Meg.
Base:   20 Meg.
Base+X  30 Meg.

On another note, the problem with device drivers, is that
(as someone else pointed out) the extra complexity they pose
is not offset by an attendant gain in general functionality,
at least in some of our opinions.  Of course if someone were
to go ahead and do it (like how about those who most vocally
proclaim them), and adapted existing devices to them, I doubt
Linus would turn the difs away :-)

But hold on here, I am not just rambling, and yes there is a 
point.   A much easier task would be to modify the kernel 
slightly to allow some of the compile time options to be 
selected at run time instead, ala rootdev.  Like for instance:

keyboard type
startup video mode
ramdisk or no
# of pty's
# of VC's
max buffer size
swap ?

Perhaps, the word or two after the rootdev byte, could contain
an offset to a static data table in the kernel (or is there
enough room to just put it down there (Linus?).  Then a 
rootdev like program could be used to set these options
and one kernel could work for all (except those wising to
turf SCSI code etc.  They would still have to recompile).

I think I know already how to do most of this, but with SLS
am just to busy now.  The line has been drawn :-).

Peter.
Newsgroups: comp.os.linux
From: Upholder@uiuc.edu (THE Upholder of Truth)
Subject: Re: Help wanted - LINUX does not boot on PS/2
Keywords: IBM PS/2 boot hanging system
Reply-To: Upholder@uiuc.edu (THE Upholder of Truth)
Organization: The University of Illinois at Urbana-Champaign (UIUC)
Date: Wed, 19 Aug 1992 17:20:18 GMT

avliet@nl.oracle.com (Arrie van der Vliet) writes:
>I'm new to LINUX, in fact so new that I never saw it running on my own
>IBM/PS2... 
>[...]
>My configuration is as follows:
>	An IBM/PS2 model 80 with:
>	    2   IDE harddisks (110 and 70 MByte)
>	    1   3.5" floppy
>	    1   serial Microsoft mouse connected to mouse port
>	    1   serial port card (MCA, 2 extra ports)
>	    1   memory card with 6 MByte of memory
>	    1	VGA monitor

Linux runs only on ISA/EISA based machines.  MCA machines cannot
run it at all (yet... this may or may not change in the future).
-- 
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: bjones@magnus.acs.ohio-state.edu (William A Jones)
Subject: Problems installing GCC-2.2.2d
Organization: The Ohio State University
Date: Sun, 16 Aug 1992 22:05:04 GMT

After about an hour of trying to install GCC2.2.2d I really
wish that the install script was as simple as it once was
(then it only took ten minutes to install).  But, even
though I had all of the files required, in the correct
from (something I never found in the README, the FAQ, or
the release notes -- but I could have missed it) many
(OK at least three) files seem to be missing and I cannot
get it installed.

The missing files are
		/usr/lib/gcc-lib/i386-linux/2.2.2d/shared/libhard.a
(I took care of this with a hard link to libm.a which did exist)
		libc.so.2.2
		libhard.so.2.2

Apparently I will be unable to finish the installation until I get
these files.  Where, praytell, are they??  And also, (this is directed
to HJ) where is the new binutils.tar.Z?  As of 1:00 pm EDT August 16
it was nowhere to be found although the sources were on tsx-11.

Thanks for the haelp.

Bill
From: mbo@dde.dk (Morten A. Bonde)
Newsgroups: comp.os.linux
Subject: Re: (none)
Date: 19 Aug 92 06:19:32 GMT
Reply-To: mbo@dde.dk (Morten A. Bonde)
Organization: The Internet

help

Please subscribe me to Linux-Activists Digest