lostecho/oldlinux-files
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

add directory mail-archive

Browse Source
This commit is contained in:
gohigh
2024-02-19 00:25:02 -05:00
parent 07129c3397
commit a778c607a4
1056 changed files with 796887 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

593
mail-archive/linux-devel/Volume1/digest5XX/digest534 Normal file
View File

@@ -0,0 +1,593 @@
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~EGV (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~EGV
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
******************************