594 lines
21 KiB
Plaintext
594 lines
21 KiB
Plaintext
Subject: Linux-Development Digest #534
|
||
From: Digestifier <Linux-Development-Request@senator-bedfellow.MIT.EDU>
|
||
To: Linux-Development@senator-bedfellow.MIT.EDU
|
||
Reply-To: Linux-Development@senator-bedfellow.MIT.EDU
|
||
Date: Thu, 10 Mar 94 03:13:07 EST
|
||
|
||
Linux-Development Digest #534, Volume #1 Thu, 10 Mar 94 03:13:07 EST
|
||
|
||
Contents:
|
||
Re: Memory Allocation (was Re: AMD 486DX problem (with Linux?)) (Nick Holloway)
|
||
Re: select (Matthias Urlichs)
|
||
Re: Linux/Windows (Gonzalo Diethelm)
|
||
Re: Small pre-1.0 problem (Achim Oppelt)
|
||
Re: AMD 486DX problem (with Linux?) (Robert Ebe)
|
||
** Bug in hp.c HPLAN driver ** (Laurent JULLIARD LAB GND 1267)
|
||
Re: GOD SPEAKS ON LINUX! (Arthur Tateishi)
|
||
Re: UDP report card (Mark Evans)
|
||
Re: select (Mark Evans)
|
||
Re: AMD 486DX problem (with Linux?) (Robert Ebe)
|
||
Re: GOD SPEAKS ON LINUX! (Grant Taylor)
|
||
gcc internal compiler error - SIGSE[2~[2SEGV (Christopher Andrew Smith)
|
||
Re: AMD 486DX problem (with Linux?) (Ralf Messerer)
|
||
|
||
----------------------------------------------------------------------------
|
||
|
||
From: alfie@dcs.warwick.ac.uk (Nick Holloway)
|
||
Subject: Re: Memory Allocation (was Re: AMD 486DX problem (with Linux?))
|
||
Date: Wed, 9 Mar 1994 16:18:10 GMT
|
||
|
||
In <2lknvi$b5f@serra.unipi.it> romano@pimac2.iet.unipi.it (Romano Giannetti) writes:
|
||
> [enquire.c]
|
||
> But _before_ comment out the following lines around line#450:
|
||
>
|
||
> while (size!=0) {
|
||
> while (malloc(size)!=(char *)NULL)
|
||
> total+=(size/2);
|
||
> size/=2;
|
||
> }
|
||
>
|
||
> that drive my Linux box to a quiet dead :-) after a lot of swapping.
|
||
> BTW: is this normal? I cannot afford test it on another Unix. My conf
|
||
> is Linux pre-1.0, 8M ram, 16M swap. The box don't crash nor panic,
|
||
> only get more and more slow if I don't ctrl-c the program.
|
||
|
||
This program defeats Linux's ``don't grab all the memory'' heuristic.
|
||
Linus did say that it would be possible to defeat, and this does it.
|
||
|
||
The good news is that it doesn't actually die -- eventually (have a
|
||
coffee :-) the process gets killed by the system.
|
||
|
||
--
|
||
Nick Holloway | `O O' | alfie@dcs.warwick.ac.uk, alfie@warwick.UUCP,
|
||
[aka `Alfie'] | // ^ \\ | ..!uunet!mcsun!uknet!warwick!alfie
|
||
|
||
------------------------------
|
||
|
||
From: urlichs@smurf.noris.de (Matthias Urlichs)
|
||
Subject: Re: select
|
||
Date: 9 Mar 1994 17:30:25 +0100
|
||
|
||
In comp.os.linux.development, article <fgm.763211130@lipo>,
|
||
fgm@doc.ic.ac.uk (Frank McCabe) writes:
|
||
> I have come across an apparent problem with the select system call.
|
||
>
|
||
Wrong. You've come across a bug in your program.
|
||
|
||
> According to the specification, if select is given a non-zero timeout then
|
||
> the system call is supposed to wait for the appropriate interval before
|
||
> terminating.
|
||
>
|
||
> Well it doesnt! If you give a non-zero timeout the nit comes back immediately.
|
||
>
|
||
> I know that this is not my problem, because the same (i.e. identical) program
|
||
> behaves as expected on a sun sparc under suno 4.1.13.
|
||
>
|
||
> Are there any known fixes for this?
|
||
>
|
||
Yes. Read the documentation. You're reusing your timeout values.
|
||
The first time you call select(), it zeroes the variable because no more
|
||
time is remaining. The next time you're calling select(), the variable is
|
||
still zero.
|
||
|
||
This is mentioned in both the SunOS and Linux manpages for select().
|
||
|
||
--
|
||
"The raytracer of justices recurses slowly, but it renders exceedingly fine."
|
||
-- Larry Phillips (lphillips@lpami.wimsey.bc.ca)
|
||
--
|
||
Matthias Urlichs \ XLink-POP N|rnberg | EMail: urlichs@smurf.noris.de
|
||
Schleiermacherstra_e 12 \ Unix+Linux+Mac | Phone: ...please use email.
|
||
90491 N|rnberg (Germany) \ Consulting+Networking+Programming+etc'ing 42
|
||
|
||
Click <A HREF="http://smurf.noris.de/~urlichs/finger">here</A>.
|
||
|
||
------------------------------
|
||
|
||
From: gonzo@malloco.ing.puc.cl (Gonzalo Diethelm)
|
||
Subject: Re: Linux/Windows
|
||
Date: Wed, 9 Mar 1994 05:24:52 GMT
|
||
|
||
a920101@zipi.fi.upm.es wrote:
|
||
> I heard something about a MS-Windows emulator under Linux. Can anybody
|
||
> tell me about it? (E-mail, please).
|
||
|
||
> THANKS!
|
||
|
||
> Juanje.
|
||
|
||
I want to know about such a beast too, please!
|
||
|
||
Gonzalo
|
||
|
||
------------------------------
|
||
|
||
From: aoppelt@scr.siemens.com (Achim Oppelt)
|
||
Subject: Re: Small pre-1.0 problem
|
||
Date: Tue, 8 Mar 1994 17:05:05 GMT
|
||
|
||
kevinl@bruce.cs.monash.edu.au (Kevin Lentin) writes:
|
||
|
||
>I have just compiled pre-1.0 and have a strange problem. I've never seen it
|
||
>before.
|
||
|
||
>My /proc/version contains:
|
||
>Linux version pre-1.0 (root@krayzee) #87 Tue Mar 8 21:01:21 EST 1994
|
||
|
||
>[87 rebuilds, that's sick!]
|
||
|
||
>My /etc/issue contains (generated from /proc/version in rc.local):
|
||
>Linux version pre-1.0 (root@krayzee) #87 Tue Mar 8 21:01:21 EST 1994
|
||
|
||
|
||
>BUT muy virtual consoles say this above the login prompt:
|
||
>Linux version pre-1.0 (rootrayzee) #87 Tue Mar 8 21:01:21 EST 1994
|
||
|
||
>Note the contents of the brackets. Where did those 2 characters disappear
|
||
>to?
|
||
|
||
>[486/dx50, 32 meg ram, 2xide, 1xSCSI, T130B controller, cluster patches]
|
||
|
||
>--
|
||
>[==================================================================]
|
||
>[ Kevin Lentin |___/~\__/~\___/~~~~\__/~\__/~\_| ]
|
||
>[ kevinl@bruce.cs.monash.edu.au |___/~\/~\_____/~\______/~\/~\__| ]
|
||
>[ Macintrash: 'Just say NO!' |___/~\__/~\___/~~~~\____/~~\___| ]
|
||
>[==================================================================]
|
||
|
||
I assume you are using getty_ps, which interprets certain @-character
|
||
sequences and replaces them with things like hostname, number of users
|
||
logged in etc. @k is probably not defined, so it is simply stripped.
|
||
(I cannot check this out since I currently do not have acces to my
|
||
Linux box, which is at home in Germany :-( )
|
||
So this has nothing to do with pre-1.0.
|
||
|
||
Achim
|
||
|
||
------------------------------
|
||
|
||
From: robert@agharta.rt.schwaben.de (Robert Ebe)
|
||
Subject: Re: AMD 486DX problem (with Linux?)
|
||
Date: Tue, 8 Mar 1994 11:31:21 GMT
|
||
|
||
In article <MCKESEY.94Mar5004239@imaphics.prior.com>,
|
||
Gregory McKesey <mckesey@imaphics.prior.com> wrote:
|
||
|
||
> Anyways, I was hoping that someone else with an AMD 486DX
|
||
>could verify that this is an AMD problem (or whether it is just
|
||
>limited to me :( ). If someone also had another OS/Compiler
|
||
>combination to ensure that this is not just a AMD486DX/GCC/Linux
|
||
>problem.
|
||
|
||
Greg, thank you for the detailed information. I also had the Ghostscript
|
||
initialization problem with an AMD 486DX2-66, datecode 9342FPW / Malaysia.
|
||
It didn't matter which operating system I used. Same behaviour under
|
||
ISC 3.0 and Linux 0.99.14i. The OS/2 version of ghostscript gets initialized,
|
||
but the output is sometimes nonsense. It looks like rounding errors, as you
|
||
pointed out in your test program. Swapping to an Intel CPU fixed all the
|
||
problems.
|
||
|
||
Hope AMD will change all the buggy CPUs.
|
||
|
||
Robert
|
||
|
||
--
|
||
=========== Bar Keeper, geben Sie mir bitte einen Synthohol! ==========
|
||
Email: <robert@agharta.rt.schwaben.de> Phone: +49 7121 83335
|
||
Home: Robert Ebe, Immanuel-Kant-Str. 31, D-72800 Eningen u.A., Germany
|
||
|
||
------------------------------
|
||
|
||
From: Laurent JULLIARD LAB GND 1267 <laurentj@gnlab030.grenoble.hp.com>
|
||
Date: Tue, 8 Mar 1994 12:01:43 GMT
|
||
Subject: ** Bug in hp.c HPLAN driver **
|
||
|
||
|
||
Hi Donald,
|
||
|
||
|
||
Yesterday I installed the slackware 1.1.2 distribution of Linux (
|
||
Patrick your setup is marvellous !!) on my 486/33T machine (this is an
|
||
HP EISA machine). Everything went smoothly except that my HP27247A
|
||
ethertwist machine was not recognized. So I went through hp.c (0.99.15c) and
|
||
discovered a few things :
|
||
|
||
========
|
||
hp_probe
|
||
========
|
||
|
||
Here is the beginning of the function:
|
||
|
||
int hp_probe(struct device *dev)
|
||
{
|
||
int *port, ports[] = {0x300, 0x320, 0x340, 0x280, 0x2C0, 0x200, 0x240, 0
|
||
short ioaddr = dev->base_addr;
|
||
|
||
if (ioaddr > 0x1ff) /* Check a single specified loca
|
||
return hpprobe1(dev, ioaddr);
|
||
else if (ioaddr > 0) /* Don't probe at all. *
|
||
return ENXIO;
|
||
|
||
[lines deleted]
|
||
|
||
}
|
||
|
||
The second test on ioaddr is wrong ! It's exactly the opposite (ioaddr < 0)
|
||
that must be done.
|
||
|
||
=========
|
||
hp_probe1
|
||
=========
|
||
|
||
PROBLEM #1
|
||
==========
|
||
|
||
Before I start using the machine mention aboved (EISA machine) I had no
|
||
problem with the autoirq code but it looks like on EISA architecture the
|
||
way you twinkle the interrupts doesn't work :
|
||
|
||
/* Twinkle the interrupt, and check if it's seen....*/
|
||
outb_p(irqmap[irq] | HP_RUN, ioaddr + HP_CONFIGURE);
|
||
outb_p( 0x00 | HP_RUN, ioaddr + HP_CONFIGURE);
|
||
|
||
I don't know why but that is how it goes. So what I did is that I added a
|
||
piece of code to get an IRQ with request_irq() like that:
|
||
|
||
do {
|
||
[lines deleted]
|
||
} while (*++irqp);
|
||
|
||
if (*irqp == 0) {
|
||
int *irqp = irq_8list;
|
||
do {
|
||
int irq = *irqp;
|
||
if (request_irq (irq, &ei_interrupt) == 0) {
|
||
printk(" (non auto) selecting IRQ %d.\n"
|
||
dev->irq = *irqp;
|
||
break;
|
||
}
|
||
} while (*++irqp);
|
||
|
||
if (*irqp == 0) {
|
||
printk(" no free IRQ lines.\n");
|
||
return EBUSY;
|
||
}
|
||
|
||
}
|
||
|
||
Of course this is not ideal but it works. The drivers grabs the first free
|
||
IRQ (7 on my machine because I don't have LPT2) and that's it.
|
||
|
||
The ideal solution would be to find a way to twinkle the IT that would work
|
||
on any platform. Any idea ?
|
||
|
||
If you want me to test a new method of yours, feel free to send your hp.c
|
||
to me.
|
||
|
||
|
||
PROBLEM #2
|
||
==========
|
||
|
||
The second problem is about the irq_16list you use when the driver detects
|
||
an HP27247A board.
|
||
|
||
int irq_16list[] = { 11, 10, 5, 3, 4, 7, 9, 0};
|
||
int irq_8list[] = { 7, 5, 3, 4, 9, 0};
|
||
|
||
I have the Hardware reference guide of this board at hand and IRQ 11 and
|
||
IRQ 10 (map into option register value 2 and 12) are mentioned as "Not
|
||
used". So is there a reason why you use this 16 bit list ? may be my doc'
|
||
is not up to date.
|
||
|
||
On top of that if I remember well, when I was using my old 386 ISA machine
|
||
with the same HP27247A board, the auto detection of the interrupt lead the
|
||
driver to select IRQ 5 meaning that IRQ 11 and 10 never worked.
|
||
|
||
|
||
It was my $0.01 contribution to Linux.
|
||
|
||
Have a nice day. Cheers.
|
||
Laurent
|
||
|
||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||
~ Laurent JULLIARD (Box 26) | HPDesk: Laurent Julliard /HP6300/UM ~
|
||
~ GND/High Speed Networking Lab | Unix: Laurent_Julliard@grenoble.hp.com~
|
||
~ HEWLETT-PACKARD FRANCE | Phone: (33) 76 62 12 67 ~
|
||
~ 5, avenue Raymond Chanas - EYBENS | Telnet: 779 12 67 ~
|
||
~ 38053 GRENOBLE CEDEX 9 | Fax: (33) 76 62 12 86 ~
|
||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||
|
||
------------------------------
|
||
|
||
From: ruhtra@turing.toronto.edu (Arthur Tateishi)
|
||
Crossposted-To: comp.os.linux,comp.os.linux.admin,comp.os.linux.help,comp.os.linux.misc
|
||
Subject: Re: GOD SPEAKS ON LINUX!
|
||
Date: 9 Mar 94 02:45:38 GMT
|
||
|
||
In article <GTAYLOR.94Mar8181237@god.ext.tufts.edu>,
|
||
Grant Taylor <gtaylor@cs.tufts.edu> wrote:
|
||
>I'll have you know I'm sitting right here in front of god, and god is
|
||
>running Linux.
|
||
|
||
As for that stuff about why people get ill and wars occur, God must be
|
||
reading too much usenet.
|
||
|
||
arthur
|
||
--
|
||
THEOREM: VI is perfect. PROOF: VI in roman numerals is 6. The
|
||
natural numbers < 6 which divide 6 are 1, 2, and 3. 1+2+3 = 6. So 6 is
|
||
a perfect number. Therefore, VI is perfect. QED
|
||
Arthur Tateishi ruhtra@turing.utoronto.ca
|
||
|
||
------------------------------
|
||
|
||
From: evansmp@mb48025.aston.ac.uk (Mark Evans)
|
||
Subject: Re: UDP report card
|
||
Date: Wed, 9 Mar 1994 17:41:32 GMT
|
||
|
||
Alan Cox (iiitac@swan.pyr) wrote:
|
||
: In article <2lj8f2$gis@access1.digex.net> christop@access1.digex.net (Chris Anderson) writes:
|
||
: >Three things seem kinda odd:
|
||
: >
|
||
: >1. A sendto INADDR_ANY as a destination gives me a ENETUNREACH. This errno is
|
||
: > new for me, in other environments the local process bound to either the
|
||
: > loopback or one of the machine's inet addresses gets the message.
|
||
: INADDR_ANY is counted as a broadcast address in Linux. Which is where this
|
||
: is coming from. Earlier pl15 systems also mistakenly return ENETUNREACH
|
||
|
||
Looking at the RFC's I think it should actually be invalid, as should anything not
|
||
a class A, B, C or D address. (Currently any invalid addresses including class
|
||
E ones are likely to get sent to the default router, which is probably not
|
||
a good idea). This check also applies to the destination of any received datagrams
|
||
(as well as an additional check that 127.X.X.X only came from the loop back device)
|
||
and any source routes.
|
||
|
||
Theoretically these should not be necessary, but they do conform to the guide line
|
||
of "Assume that the network is full of hostile entities"
|
||
|
||
------------------------------
|
||
|
||
From: evansmp@mb48025.aston.ac.uk (Mark Evans)
|
||
Subject: Re: select
|
||
Date: Wed, 9 Mar 1994 17:44:45 GMT
|
||
|
||
Frank McCabe (fgm@doc.ic.ac.uk) wrote:
|
||
: I have come across an apparent problem with the select system call.
|
||
|
||
: According to the specification, if select is given a non-zero timeout then
|
||
: the system call is supposed to wait for the appropriate interval before
|
||
: terminating.
|
||
|
||
: Well it doesnt! If you give a non-zero timeout the nit comes back immediately.
|
||
|
||
I suspect it actually only does this the SECOND time you call select.
|
||
What Linux does is to write to the variable used. So if you need to use
|
||
select inside any kind of loop you need a variable specifically for the timeout,
|
||
which you set to the appropriate value before calling select. i.e. use in
|
||
exactly the same way as the fd_set values.
|
||
|
||
: I know that this is not my problem, because the same (i.e. identical) program
|
||
: behaves as expected on a sun sparc under suno 4.1.13.
|
||
|
||
Some people would say that the sun is broken :-)
|
||
|
||
------------------------------
|
||
|
||
From: robert@agharta.rt.schwaben.de (Robert Ebe)
|
||
Subject: Re: AMD 486DX problem (with Linux?)
|
||
Date: Tue, 8 Mar 1994 23:27:43 GMT
|
||
|
||
In article <MCKESEY.94Mar5004239@imaphics.prior.com>,
|
||
Gregory McKesey <mckesey@imaphics.prior.com> wrote:
|
||
>
|
||
> I have found an annoying problem with the AMD 486DX chip and
|
||
>Linux that is leading me to believe that there may be a compatibility
|
||
>problem with this chips math functions.
|
||
|
||
>This is the output that I obtained on my system:
|
||
>
|
||
>% ./amdtest
|
||
>1.312500 * 7.999900 =10.499990
|
||
>1.312500 * 7.999900 =10.499869
|
||
>Test Failed, this must be an AMD 486DX chip!
|
||
>%
|
||
|
||
Here the same rusults. And also the ghostscript initialization death. :-(
|
||
Furtunately my dealer is willing to change my CPU to an Intel.
|
||
|
||
AMD 486DX2-66 Datecode 9342FPW Malaysia
|
||
Linux 0.99.14
|
||
GCC 2.4.5
|
||
|
||
Robert
|
||
|
||
--
|
||
=========== Bar Keeper, geben Sie mir bitte einen Synthohol! ==========
|
||
Email: <robert@agharta.rt.schwaben.de> Phone: +49 7121 83335
|
||
Home: Robert Ebe, Immanuel-Kant-Str. 31, D-72800 Eningen u.A., Germany
|
||
|
||
------------------------------
|
||
|
||
Crossposted-To: comp.os.linux,comp.os.linux.admin,comp.os.linux.help,comp.os.linux.misc
|
||
From: gtaylor@god.ext.tufts.edu (Grant Taylor)
|
||
Subject: Re: GOD SPEAKS ON LINUX!
|
||
Date: Tue, 8 Mar 1994 23:12:37 GMT
|
||
Reply-To: gtaylor@cs.tufts.edu
|
||
|
||
I'll have you know I'm sitting right here in front of god, and god is
|
||
running Linux.
|
||
|
||
-grant
|
||
|
||
--
|
||
Grant Taylor gtaylor@cs.tufts.edu
|
||
Read the linux Printing-HOWTO -- get it from sunsite or mail server:
|
||
To: listserv@god.ext.tufts.edu
|
||
with message body:
|
||
|
||
------------------------------
|
||
|
||
From: z1g192@rick.cs.ubc.ca (Christopher Andrew Smith)
|
||
Subject: gcc internal compiler error - SIGSE[2~[2SEGV
|
||
Date: 8 Mar 1994 17:38:42 -0800
|
||
|
||
I'm getting an error that I've never seen before when compiling a certain
|
||
appliction. What happens is that after I've compiled all the object files
|
||
for the application and start linking the application with the library
|
||
I made, gcc reports an internal error which I've never encountered before.
|
||
|
||
Here is what happens when I type `make':
|
||
|
||
gcc -g -D`arch` -ansi -c app.c -o app.o
|
||
gcc -g -D`arch` -ansi -c startup.c -o startup.o
|
||
/lib/cpp -D`arch` -P context.s > _context.s
|
||
cc -g -c -o context.o _context.s
|
||
rm _context.s
|
||
gcc -g -D`arch` -ansi -c queue.c -o queue.o
|
||
gcc -g -D`arch` -ansi -c procMgmt.c -o procMgmt.o
|
||
gcc -g -D`arch` -ansi -c ipc.c -o ipc.o
|
||
gcc -g -D`arch` -ansi -c time.c -o time.o
|
||
gcc -g -D`arch` -ansi -c scheduling.c -o scheduling.o
|
||
gcc -g -D`arch` -ansi -c synch.c -o synch.o
|
||
gcc -g -D`arch` -ansi -c mem.c -o mem.o
|
||
ar -r pthreads.a startup.o context.o queue.o procMgmt.o ipc.o time.o \
|
||
scheduling.o synch.o mem.o
|
||
Creating archive file `/home/hell/src/pthreads/pthreads.a'
|
||
gcc -g -D`arch` -ansi app.o pthreads.a -o app
|
||
gcc: Internal compiler error: program ld got fatal signal 11
|
||
make: *** [app] Error 1
|
||
|
||
What could cause ld to receive signal 11 (ie SIGSEGV )? Is the compiler
|
||
trying to access a symbol name outside of the library's text segment?
|
||
|
||
If this was due to an error in my code, I would expect the error to show up
|
||
during compilation of the module, or during run-time of the app.
|
||
|
||
I am using these versions of compiler, linker, etc.:
|
||
|
||
gcc 2.5.8
|
||
libc 4.5.21
|
||
ld 1.9l.3
|
||
|
||
Has anyone else ever had this problem? I'd like to know if it is a common
|
||
problem.
|
||
|
||
A listing of my makefile follows.
|
||
|
||
Thanks in advance,
|
||
|
||
Chris Smith aka z1g192@ugrad.cs.ubc.ca
|
||
|
||
|
||
===========================================================================
|
||
Makefile:
|
||
^^^^^^^^^
|
||
CC = gcc # use gcc otherwise
|
||
|
||
ARCH = `arch`
|
||
|
||
CFLAGS = -g -D`arch` -ansi -D_LINUX #defines for linux
|
||
#CFLAGS = -g -D`arch` -Aa -D_HPUX_SOURCE #defines for hpux
|
||
#CFLAGS = -g -D`arch` # defines otherwise
|
||
|
||
|
||
app: app.o pthreads.a
|
||
$(CC) $(CFLAGS) app.o pthreads.a -o app
|
||
|
||
pthreads.a: startup.o context.o queue.o procMgmt.o ipc.o time.o scheduling.o \
|
||
synch.o mem.o
|
||
ar -r pthreads.a startup.o context.o queue.o procMgmt.o ipc.o time.o \
|
||
|
||
scheduling.o synch.o mem.o
|
||
|
||
kernel.h: standards.h os.h kernelTypes.h ipc.h time.h procMgmt.h mem.h\
|
||
synch.h scheduling.h queue.h kernelConfig.h
|
||
# touch kernel.h
|
||
|
||
app.o: app.c os.h standards.h
|
||
|
||
synchronization.o: synch.c kernel.h
|
||
$(CC) $(CFLAGS) -c synch.c -o synch.o
|
||
|
||
scheduling.o: scheduling.c kernel.h
|
||
$(CC) $(CFLAGS) -c scheduling.c -o scheduling.o
|
||
|
||
procMgmt.o: procMgmt.c kernel.h
|
||
$(CC) $(CFLAGS) -c procMgmt.c -o procMgmt.o
|
||
|
||
queue.o: queue.c kernel.h
|
||
$(CC) $(CFLAGS) -c queue.c -o queue.o
|
||
|
||
ipc.o: ipc.c kernel.h
|
||
$(CC) $(CFLAGS) -c ipc.c -o ipc.o
|
||
|
||
time.o: time.c kernel.h
|
||
$(CC) $(CFLAGS) -c time.c -o time.o
|
||
|
||
mem.o: mem.c kernel.h
|
||
$(CC) $(CFLAGS) -c mem.c -o mem.o
|
||
|
||
startup.o: startup.c kernel.h
|
||
$(CC) $(CFLAGS) -c startup.c -o startup.o
|
||
|
||
context.o: context.s
|
||
/lib/cpp -D$(ARCH) -P context.s > _context.s
|
||
cc -g -c -o context.o _context.s
|
||
rm _context.s
|
||
--
|
||
========================================================================
|
||
|Christopher Smith | With a rubber duck, one's never alone. |
|
||
|aka z1g192@ugrad.cs.ubc.ca |-- "The Hitchhiker's Guide to the Galaxy"|
|
||
========================================================================
|
||
|
||
------------------------------
|
||
|
||
From: rm@eacpc4.tuwien.ac.at (Ralf Messerer)
|
||
Subject: Re: AMD 486DX problem (with Linux?)
|
||
Date: 10 Mar 1994 07:39:30 GMT
|
||
|
||
If you change all printf("%f...) to printf ("%3.8f...")
|
||
you will see:
|
||
|
||
1.31250000 * 7.99989986 =10.49986839
|
||
1.31250000 * 7.99990000 =10.49986875
|
||
Test Failed, this must be an AMD 486DX chip!
|
||
|
||
There is no CPU bug. The only thing is that the number 7.9999
|
||
can not be stored in the float format without loosing precision.
|
||
|
||
|
||
--
|
||
-Ralf [rm@eacpc4.tuwien.ac.at]
|
||
|
||
------------------------------
|
||
|
||
|
||
** FOR YOUR REFERENCE **
|
||
|
||
The service address, to which questions about the list itself and requests
|
||
to be added to or deleted from it should be directed, is:
|
||
|
||
Internet: Linux-Development-Request@NEWS-DIGESTS.MIT.EDU
|
||
|
||
You can send mail to the entire list (and comp.os.linux.development) via:
|
||
|
||
Internet: Linux-Development@NEWS-DIGESTS.MIT.EDU
|
||
|
||
Linux may be obtained via one of these FTP sites:
|
||
nic.funet.fi pub/OS/Linux
|
||
tsx-11.mit.edu pub/linux
|
||
sunsite.unc.edu pub/Linux
|
||
|
||
End of Linux-Development Digest
|
||
******************************
|