Linux-Development-Sys Digest #57, Volume #8 Mon, 31 Jul 00 16:13:22 EDT
Contents:
Re: PPPoE (Matt Lesko)
Re: a problem for calling pthread_create (Naveen Gogineni)
root image over nfs?? (Jerome Corre)
Re: undefined symbols in modules (Rick Ellis)
Re: Linux memory perfomance is horrible (Szabolcs Csetey)
Re: GCC 2.95.2 problems on RedHat 6.2 -- help anyone ? (Grant Edwards)
Re: Linux memory perfomance is horrible (Bob Tennent)
serial port signals (Danny Tran)
Re: Linux memory perfomance is horrible (Szabolcs Csetey)
Re: exec*() and argv[0] (Andrew Kuchling)
Re: dark colors in ANSI Escape Sequences ([EMAIL PROTECTED])
Re: Linux memory perfomance is horrible (Kaz Kylheku)
Re: Linux memory perfomance is horrible ("S V")
Re: Linux memory perfomance is horrible ([EMAIL PROTECTED])
Re: exec*() and argv[0] ([EMAIL PROTECTED])
Re: problem with open files (Shankar)
Re: GCC 2.95.2 problems on RedHat 6.2 -- help anyone ? (Michael Meding)
Debugging Embedded Linux Applications ("Dean A. Henkel")
Re: GCC 2.95.2 problems on RedHat 6.2 -- help anyone ? (Ronald Cole)
Re: GCC 2.95.2 problems on RedHat 6.2 -- help anyone ? (Ronald Cole)
Re: GCC 2.95.2 problems on RedHat 6.2 -- help anyone ? (Toby Haynes)
----------------------------------------------------------------------------
From: Matt Lesko <[EMAIL PROTECTED]>
Subject: Re: PPPoE
Date: Mon, 31 Jul 2000 10:21:06 -0400
I don't know if this works, but give it a shot:
http://www.roaringpenguin.com/pppoe/
David Findlay wrote:
> Does Linux 2.4 work with PPPoE? I need it for ADSL.
>
> David Findlay
------------------------------
From: Naveen Gogineni <[EMAIL PROTECTED]>
Subject: Re: a problem for calling pthread_create
Date: Mon, 31 Jul 2000 10:06:18 -0400
Did you include the pthread library while linking.
use the -lpthread option while compiling.
Terry wrote:
>
> pthread_t tid;
> pthread_create(&tid, NULL, echo_serv, &newsockfd);
>
> where the prototype for the thread start function is:
> void *echo_serv(void *sockfd);
>
> When I compile, the following message appears:
> undefined reference to `pthread_create'
>
> What is wrong with the above code??
> Would anyone tell me ??
>
> Thx,
> Terry
------------------------------
From: Jerome Corre <[EMAIL PROTECTED]>
Subject: root image over nfs??
Date: Mon, 31 Jul 2000 15:22:48 GMT
hi,
I have two PCs, an old 386 with no screen and no hard drive, just a
floppy, and a new one with screen and everything else. I also have a
wireless network link between the two PCs.
I was wondering if it is possible to boot linux on the old 386 in the
following way:
1-kernel is loaded from a bootdisk,
2-root image to be taken from the network,
3-root image to be extracted in ram.
Is that possible?
Does the other PC on my m=network need to be configurated in a
different way?
from the howtos i found that the argument root=/dev/nfs can be passed
to the kernel but what does it do and does it work?
thanks for any help?
Jerome
--
Jerome Corre
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Rick Ellis)
Subject: Re: undefined symbols in modules
Date: 31 Jul 2000 15:36:24 GMT
In article <[EMAIL PROTECTED]>,
F. Heitkamp <[EMAIL PROTECTED]> wrote:
>I have several kernel projects involving modules.
>When I compile my modules using "gcc -c module.c -DMODULE \
>-D__KERNEL__ -o module.o"
Add -O to the gcc flags.
--
http://www.fnet.net/~ellis/photo/linux.html
------------------------------
From: Szabolcs Csetey <[EMAIL PROTECTED]>
Crossposted-To: comp.unix.bsd.freebsd.misc
Subject: Re: Linux memory perfomance is horrible
Date: Mon, 31 Jul 2000 15:26:22 GMT
In article <%wZg5.23206$[EMAIL PROTECTED]>,
"S V" <[EMAIL PROTECTED]> wrote:
>
> there is a little benchmark list compiled at
> http://www.phystech.com/download/ubench.html
> and it consistently shows Linux memory benchmarks
> are 6-7 (!) times lower than FreeBSD or Solaris 8
> on the same hardware.
You should multiply the Linux mem result by 8 since
the used BUFSIZ 8x bigger. ubench mem testing is buggy.
> The seems to be a problem with Linux memory subsystem
> or, maybe, glibc memory functions, why would simple
> malloc and memcpy be so slow under Linux?
No, based on the corrected results Linux outperforms both Solaris and
FreeBSD [just try the benchmark with the same BUFSIZ value, I did].
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Grant Edwards)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: GCC 2.95.2 problems on RedHat 6.2 -- help anyone ?
Date: Mon, 31 Jul 2000 16:07:15 GMT
In article <[EMAIL PROTECTED]>, J Wendel wrote:
>>I have problems using gcc 2.95.2 which I bootstrapped on RH6.2.
>>System is AMD Duron on VIA KT-133 MSI-6330. LAtest binutils are used,
>>kernel is 2.4.0-test5.
>
>Dude, 2.4.0-test5 has bad VM problems, your hardware is not the
>problem! Drop back to 2.2.x and wait for a more stable 2.4 kernel.
Sorry for my misleading posts. Since "4" was an even digit, I
assumed it was a fairly stable kernel.
--
Grant Edwards grante Yow! Where does it go when
at you flush?
visi.com
------------------------------
From: [EMAIL PROTECTED] (Bob Tennent)
Crossposted-To: comp.unix.bsd.freebsd.misc
Subject: Re: Linux memory perfomance is horrible
Date: 31 Jul 2000 15:55:02 GMT
Reply-To: [EMAIL PROTECTED]
On Mon, 31 Jul 2000 15:26:22 GMT, Szabolcs Csetey wrote:
>
>> The seems to be a problem with Linux memory subsystem
>> or, maybe, glibc memory functions, why would simple
>> malloc and memcpy be so slow under Linux?
>
>No, based on the corrected results Linux outperforms both Solaris and
>FreeBSD [just try the benchmark with the same BUFSIZ value, I did].
>
How do you know that the Solaris and BSD results aren't going to change
if you change *their* BUFSIZ value? And which BUFSIZE are you
speaking of anyway?
Bob T.
------------------------------
From: Danny Tran <[EMAIL PROTECTED]>
Subject: serial port signals
Date: Mon, 31 Jul 2000 09:28:49 -0700
I'm having trouble getting Linux to generate a SIGINT signal when a
break is received across the serial port.
Its not a hardware problem or setting up the signal handlers.
I've set all the proper flags:
IGNBRRK off
BRKINT on
The serial port has no problem sending a SIGIO when anything is
transmitted, it just can't generate a SIGINT for the break.
Any suggestions?
------------------------------
From: Szabolcs Csetey <[EMAIL PROTECTED]>
Crossposted-To: comp.unix.bsd.freebsd.misc
Subject: Re: Linux memory perfomance is horrible
Date: Mon, 31 Jul 2000 16:54:20 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> On Mon, 31 Jul 2000 15:26:22 GMT, Szabolcs Csetey wrote:
> >
> >> The seems to be a problem with Linux memory subsystem
> >> or, maybe, glibc memory functions, why would simple
> >> malloc and memcpy be so slow under Linux?
> >
> >No, based on the corrected results Linux outperforms both Solaris
and
> >FreeBSD [just try the benchmark with the same BUFSIZ value, I did].
> >
> How do you know that the Solaris and BSD results aren't going to
change
> if you change *their* BUFSIZ value? And which BUFSIZE are you
> speaking of anyway?
BUFSIZ defined in stdio.h. FreeBSD and Solaris use 1024 while
Linux 8192. The memory tests are done with BUFSIZ chunks so
Linux should do 8x more work during the same time. Of course
it false since it's not 8x faster than FreeBSD or Solaris. If Linux were
8x slower (contrary to 6-7x that was reported before) in mem tests then
it would perform the same "badly" way as FreeBSD or Solaris. Hope this
clears things up.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Subject: Re: exec*() and argv[0]
From: Andrew Kuchling <[EMAIL PROTECTED]>
Date: 31 Jul 2000 13:12:07 -0400
[EMAIL PROTECTED] writes:
> Instead, I'm *ASKING* why does an interpreter binary have to NOT receive
> its full path via argv[0] when an ordinary binary does. There may well
> be a very convincing argument to justify it. But it appears from your
> lack of willingness to state it, that you simply do not know what it is.
That was also my motivation for raising the issue in the first place;
it's not obvious *why* the kernel is changing argv[0] in this way, and
if there's no real reason, it might be worth changing, particularly if
it increases compatibility with other Unixes. (Though I only have a
sample size of 1, namely Solaris. Anyone know what HP-UX, IRIX, and
other variants do?
--amk
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: dark colors in ANSI Escape Sequences
Date: Mon, 31 Jul 2000 17:51:44 GMT
On Mon, 31 Jul 2000 13:07:38 GMT [EMAIL PROTECTED] wrote:
| How can I make ANSI-colors become displayed in the first style?
|
| I go mad, if I don't get back the dark colors!
You can load the first 16 pallette registers with the RGB color value
you want with this escape sequence:
ESC ] P R r G g B b X
P = literally 'P'
X = the 4 bit index identifying which color pallette register to change
R = high order 4 bits of the red value
r = low order 4 bits of the red value from which the high 2 bits are used
G = high order 4 bits of the green value
g = low order 4 bits of the green value from which the high 2 bits are used
B = high order 4 bits of the blue value
b = low order 4 bits of the blue value from which the high 2 bits are used
Each of the 4 bit values is given as a hexadecimal character.
To reset all pallette registers back to default values:
ESC ] R
R = literally 'R'
--
| Phil Howard - KA9WGN | My current websites: linuxhomepage.com, ham.org
| phil (at) ipal.net +----------------------------------------------------
| Dallas - Texas - USA | [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Crossposted-To: comp.unix.bsd.freebsd.misc
Subject: Re: Linux memory perfomance is horrible
Reply-To: [EMAIL PROTECTED]
Date: Mon, 31 Jul 2000 17:54:05 GMT
On Mon, 31 Jul 2000 16:54:20 GMT, Szabolcs Csetey <[EMAIL PROTECTED]> wrote:
>BUFSIZ defined in stdio.h. FreeBSD and Solaris use 1024 while
>Linux 8192. The memory tests are done with BUFSIZ chunks so
>Linux should do 8x more work during the same time.
What kind of a moron would design a benchmark that depends on
implementation-defined constants like BUFSIZ?
--
Any hyperlinks appearing in this article were inserted by the unscrupulous
operators of a Usenet-to-web gateway, without obtaining the proper permission
of the author, who does not endorse any of the linked-to products or services.
------------------------------
From: "S V" <[EMAIL PROTECTED]>
Crossposted-To: comp.unix.bsd.freebsd.misc
Subject: Re: Linux memory perfomance is horrible
Date: Mon, 31 Jul 2000 18:15:14 GMT
Hi
Oops, shame on me.
Thanks for the debugging info.
I made the correction to the code and
re-ran the benchmark on the systems
where I could get a hand on, and it came
out that the factor I had to multiply the
MEM benchmark for Linux is almost
exactly 8.
Sergei
"Szabolcs Csetey" <[EMAIL PROTECTED]> wrote in message
news:8m4avr$48n$[EMAIL PROTECTED]...
> In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
> > On Mon, 31 Jul 2000 15:26:22 GMT, Szabolcs Csetey wrote:
> > >
> > >> The seems to be a problem with Linux memory subsystem
> > >> or, maybe, glibc memory functions, why would simple
> > >> malloc and memcpy be so slow under Linux?
> > >
> > >No, based on the corrected results Linux outperforms both Solaris
> and
> > >FreeBSD [just try the benchmark with the same BUFSIZ value, I did].
> > >
> > How do you know that the Solaris and BSD results aren't going to
> change
> > if you change *their* BUFSIZ value? And which BUFSIZE are you
> > speaking of anyway?
>
> BUFSIZ defined in stdio.h. FreeBSD and Solaris use 1024 while
> Linux 8192. The memory tests are done with BUFSIZ chunks so
> Linux should do 8x more work during the same time. Of course
> it false since it's not 8x faster than FreeBSD or Solaris. If Linux were
> 8x slower (contrary to 6-7x that was reported before) in mem tests then
> it would perform the same "badly" way as FreeBSD or Solaris. Hope this
> clears things up.
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Linux memory perfomance is horrible
Crossposted-To: comp.unix.bsd.freebsd.misc
Date: Mon, 31 Jul 2000 18:16:25 GMT
In comp.os.linux.development.system Kaz Kylheku <[EMAIL PROTECTED]> wrote:
> What kind of a moron would design a benchmark that depends on
> implementation-defined constants like BUFSIZ?
That's a loaded question. What does any benchmark really measure,
apart from the performance of the target running the benchmark?
Granted, this is one of the dumber ones, but there are numerous
examples of people spending large amounts of money based on equally
inapplicable bench marks. The bottom line is people rarely stop to see
what the benchmark is actually measuring before making sweeping
declarations about the results.
--
Matt Gauthier <[EMAIL PROTECTED]>
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: exec*() and argv[0]
Date: Mon, 31 Jul 2000 18:33:37 GMT
On 31 Jul 2000 13:12:07 -0400 Andrew Kuchling <[EMAIL PROTECTED]> wrote:
| [EMAIL PROTECTED] writes:
|> Instead, I'm *ASKING* why does an interpreter binary have to NOT receive
|> its full path via argv[0] when an ordinary binary does. There may well
|> be a very convincing argument to justify it. But it appears from your
|> lack of willingness to state it, that you simply do not know what it is.
|
| That was also my motivation for raising the issue in the first place;
| it's not obvious *why* the kernel is changing argv[0] in this way, and
| if there's no real reason, it might be worth changing, particularly if
| it increases compatibility with other Unixes. (Though I only have a
| sample size of 1, namely Solaris. Anyone know what HP-UX, IRIX, and
| other variants do?
Maybe this should be brought up on comp.unix.programmer to get some insight
into "what is right (and why)".
--
| Phil Howard - KA9WGN | My current websites: linuxhomepage.com, ham.org
| phil (at) ipal.net +----------------------------------------------------
| Dallas - Texas - USA | [EMAIL PROTECTED]
------------------------------
From: Shankar <[EMAIL PROTECTED]>
Subject: Re: problem with open files
Date: Tue, 1 Aug 2000 00:06:22 +0530
Hi
>Close or compress your files so you aren't using 64GB on 70GB disk?
But how do I close deleted files. I have tried gleaning their fds and
then writing separate code to shut them down/unlink them but it doesn't
seem to work.
shankar
------------------------------
From: Michael Meding <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: GCC 2.95.2 problems on RedHat 6.2 -- help anyone ?
Date: Mon, 31 Jul 2000 17:15:02 +0200
Reply-To: [EMAIL PROTECTED]
Hi there,
again.
After disabling the cache I got no more bootstrapping problems with gcc.
But still I can't compile XF4.01. Even if using an earlier kernel
version (2.2.14).
I am somewhat clueless at the moment.
With best regards
Michael
------------------------------
From: "Dean A. Henkel" <[EMAIL PROTECTED]>
Subject: Debugging Embedded Linux Applications
Date: Mon, 31 Jul 2000 14:17:42 -0500
Hello,
Looking for opinions from some Linux Guru's.
We are considering using using an embedded Linux Kernal on a PPC
environment. What tools are available for Source Level Debug, Profiling,
and Code Coverage Analysis. Are there any tools that support a "macro"
environment (Dynamically Loaded Shared Libraries?).
Thanks,
Dean
------------------------------
From: Ronald Cole <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: GCC 2.95.2 problems on RedHat 6.2 -- help anyone ?
Date: 31 Jul 2000 12:27:48 -0700
[EMAIL PROTECTED] (Grant Edwards) writes:
> On Sun, 30 Jul 2000 07:10:05 +0200, Michael Meding <[EMAIL PROTECTED]> wrote:
>
> >Thing is though that XF4.01 consistently is a no go.
>
> Does it always fail in the same place with the same error
> messages? If yes, then it's probably not hardware -- you might
> have it configured incorrectly.
>
> If it fails "randomly" in different places in different files,
> then it's more likely a hardware problem.
Not necessarily true. An old 486 system of mine had a stuck bit that
changed an "r" into an "s" in the assembler source during the assembly
pass. Always happened in the same place with the same error message
because I was the only user on the system.
--
Forte International, P.O. Box 1412, Ridgecrest, CA 93556-1412
Ronald Cole <[EMAIL PROTECTED]> Phone: (760) 499-9142
President, CEO Fax: (760) 499-9152
My GPG fingerprint: C3AF 4BE9 BEA6 F1C2 B084 4A88 8851 E6C8 69E3 B00B
------------------------------
From: Ronald Cole <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: GCC 2.95.2 problems on RedHat 6.2 -- help anyone ?
Date: 31 Jul 2000 12:29:06 -0700
[EMAIL PROTECTED] (Grant Edwards) writes:
> In article <[EMAIL PROTECTED]>, J Wendel wrote:
> >Dude, 2.4.0-test5 has bad VM problems, your hardware is not the
> >problem! Drop back to 2.2.x and wait for a more stable 2.4 kernel.
>
> Sorry for my misleading posts. Since "4" was an even digit, I
> assumed it was a fairly stable kernel.
What part of the word "test" says "fairly stable" to you?
--
Forte International, P.O. Box 1412, Ridgecrest, CA 93556-1412
Ronald Cole <[EMAIL PROTECTED]> Phone: (760) 499-9142
President, CEO Fax: (760) 499-9152
My GPG fingerprint: C3AF 4BE9 BEA6 F1C2 B084 4A88 8851 E6C8 69E3 B00B
------------------------------
From: Toby Haynes <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: GCC 2.95.2 problems on RedHat 6.2 -- help anyone ?
Date: 31 Jul 2000 15:54:49 -0400
!! "Grant" == Grant Edwards <[EMAIL PROTECTED]> writes:
Grant> In article <[EMAIL PROTECTED]>, J Wendel wrote:
>>> I have problems using gcc 2.95.2 which I bootstrapped on RH6.2. System
>>> is AMD Duron on VIA KT-133 MSI-6330. LAtest binutils are used, kernel is
>>> 2.4.0-test5.
>> Dude, 2.4.0-test5 has bad VM problems, your hardware is not the problem!
>> Drop back to 2.2.x and wait for a more stable 2.4 kernel.
Grant> Sorry for my misleading posts. Since "4" was an even digit, I assumed
Grant> it was a fairly stable kernel.
Umm - it will be when it gets out of the test kernels. These 2.4.0-testXX
kernels are the final run-up to the 2.4.0 release, which will hopefully be a
stable release. Until those test suffices go away, it's still a little bit
early to be calling them full stable releases. Your mileage may vary.
Cheers,
Toby Haynes
--
Toby Haynes
The views and opinions expressed in this message are my own, and do
not necessarily reflect those of IBM Canada.
------------------------------
** 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: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.development.system) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Development-System Digest
******************************
