Linux-Development-Sys Digest #616, Volume #6 Mon, 12 Apr 99 12:14:20 EDT
Contents:
Hayes Modem (Yeung Kai Wah)
Re: Difficulty with C++ clock() function on Linux (Andreas Schwab)
2.2 kernel, diskless clients, chicken/egg problem? (Nils Ulltveit-Moe)
Re: STREAMS Mythology (Mike Jagdis)
script for .procmailrc ("George Macario")
Re: threads and C++ exceptions ("F.J. Lingen")
Compiling for x86 CPUs (Was: ... seperate "i686" tree for Redhat ...) (Urs Thuermann)
Re: CodeWarror for Linux (was: Re: Programming tools for ...) (Alexander Dymerets)
Re: modprobe error at start up and shutdown (Karl Heyes)
Fix for NLS catopen. (Donald Ellis)
Re: Compiling for x86 CPUs (Was: ... seperate "i686" tree for Redhat ("G. Sumner
Hayes")
----------------------------------------------------------------------------
From: Yeung Kai Wah <[EMAIL PROTECTED]>
Subject: Hayes Modem
Date: Mon, 12 Apr 1999 17:29:00 +0800
I'm new user in Linux and don't know whether should I install a driver
for my Hayes 56k modem, in order to get fastest speed online. I suspect
to do so 'coz I found it is much more slow after using Linux when
comparing w/ Win95.
------------------------------
From: Andreas Schwab <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c++
Subject: Re: Difficulty with C++ clock() function on Linux
Date: 12 Apr 1999 11:48:52 +0200
"Robert C. Paulsen, Jr." <[EMAIL PROTECTED]> writes:
|> Andi Kleen wrote:
|>
|> >
|> > The man page says:
|> >
|> > DESCRIPTION
|> > The clock() function returns an approximation of processor
|> > time used by the program.
|> >
|>
|> OK, thanks. I guess MS and Borland have a different idea of processor
|> time and interpret it as elapsed time.
If all you can do is busy waiting then processor time = elapsed time.
--
Andreas Schwab "And now for something
[EMAIL PROTECTED] completely different"
[EMAIL PROTECTED]
------------------------------
Crossposted-To: comp.os.linux.networking
Subject: 2.2 kernel, diskless clients, chicken/egg problem?
From: Nils Ulltveit-Moe <[EMAIL PROTECTED]>
Date: 12 Apr 1999 12:30:10 +0200
Have anyone managed to make NFS-root work on diskless clients running
a 2.2 kernel?
NFS root works OK up to kernel 2.0.36, but I have not yet managed to get
it working on 2.2.X kernels.
The problem now is that RPC seems not to work... After searching
newsgroups it seems like the 2.2 kernel may require to have the local
portmapper running for RPC services to work. (I cannot imagine for what
reason.. It should suffice to contact the remote portmapper.)
If this is the case, the 2.2 kernel has added a
"chicken/egg" problem since the root nfs code may require the local
portmapper running before mounting the root file system, but that is
impossible because the portmapper should be loaded from the root file
system via NFS..
At first I tried to patch ipconfig.c (thanks to Bodo Bellut
[EMAIL PROTECTED]) to make the kernel being able to mount the root
FS via NFS:
--- linux/net/ipv4/ipconfig.c.OLD Sun Feb 28 23:36:50 1999
+++ linux/net/ipv4/ipconfig.c Mon Mar 1 00:39:32 1999
@@ -812,6 +812,9 @@
return 0;
DBG(("IP-Config: Entered.\n"));
+
+ if (root_server_addr == INADDR_NONE)
+ root_server_addr = ic_servaddr;
/* Setup all network devices */
if (ic_open_devs() < 0)
With this patch the client attempts to mount the root FS via NFS:
Root-NFS: Mounting /tftpboot/rootfs/skaalen.linux on server
193.180.211.70 as root
Root-NFS: rsize=4096, wsize=4096, timeout=7, retrans=3
Root-NFS: acreg(min,max)=(3.60), acdir(min,max)=(30,60)
Root-NFS: nfsd port=-1, mountd port=0, flags=00000200
Looking up port of RPC 100003/2 on 193.180.211.70
RPC: sendmsg returned error 101 (ENETUNREACH)
RPC: sendmsg returned error 101 (ENETUNREACH)
RPC: sendmsg returned error 101 (ENETUNREACH)
RPC: sendmsg returned error 101 (ENETUNREACH)
RPC: sendmsg returned error 101 (ENETUNREACH)
Portmap: Server 193.180.211.70 not responding, timed out.
The portmapper IS running and has rpc.mountd/rpc.nfsd running:
eldhus:/usr/home/etonumo# ps -ax | egrep -v grep | egrep "rpc"
25794 ? S 0:00 rpc.mountd
25796 ? S 2:31 rpc.nfsd
104 ? S 0:01 /usr/sbin/rpc.portmap
Programs are registered at portmapper:
eldhus:/usr/home/etonumo# rpcinfo -p eldhus
program vers proto port
100000 2 tcp 111 portmapper
100000 2 udp 111 portmapper
100005 1 udp 954 mountd
100005 1 tcp 956 mountd
100003 2 udp 2049 nfs
100003 2 tcp 2049 nfs
Mount works fine from another machine:
numopc:/usr/src/linux/fs/nfs# mount eldhus:/tftpboot/rootfs/skaalen.linux /mnt
numopc:/usr/src/linux/fs/nfs# ls /mnt
System.map dev lib proc server var
bin etc mnt root tmp
bootImage home opt sbin usr
Please tell me if you have any clue of how to fix the problem.
(e.g. if there are patches floating around for it..)
Regards,
Nils Ulltveit-Moe
------------------------------
From: [EMAIL PROTECTED] (Mike Jagdis)
Subject: Re: STREAMS Mythology
Date: 12 Apr 1999 09:38:07 GMT
In article <[EMAIL PROTECTED]>, David Grothe wrote:
>Incorrect. On an Intel box running SCO OpenServer 5.0.4, I placed a
>breakpoint on the "send" routine in the kernel and single stepped as
>follows: send calls sosend; sosend calls allocmsg which calls allocb
>which allocates a STREAMS buffer; sosend calls soputmsg; soputmsg calls
>putnext which is the STREAMS message passing routine.
It would be more interesting to know how control operations
are performed.
Mike
--
A train stops at a train station, a bus stops at a bus station.
On my desk I have a work station...
.----------------------------------------------------------------------.
| Mike Jagdis | Internet: mailto:[EMAIL PROTECTED] |
| Roan Technology Ltd. | |
| 54A Peach Street, Wokingham | Telephone: +44 118 989 0403 |
| RG40 1XG, ENGLAND | Fax: +44 118 989 1195 |
`----------------------------------------------------------------------'
------------------------------
From: "George Macario" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.help,comp.os.linux.misc
Subject: script for .procmailrc
Date: 12 Apr 1999 11:40:39 GMT
I have a shell account on the Linux system of my university,
but I'm not a Linux expert. I'd like to know if procmail can...
- ...leave, first of all, a local copy of all mail that arrive to my
address, and...
- ...using split and formail, divide only messages smaller than
5 kb into smaller messages of, at most, 160 characters, add
to each new message "date", "from" and "subject" headers
of the mail which was divided and forward all messages
obtained to another address.
To do this, I need a script for the file .procmailrc; anyone could
write it for me?
I thank you in advance
George
------------------------------
From: "F.J. Lingen" <[EMAIL PROTECTED]>
Subject: Re: threads and C++ exceptions
Date: Mon, 12 Apr 1999 14:03:36 +0200
Rich wrote:
> I keep getting SIGSEGV errors when my code executing in a
> pthread_create() created thread tries throws an exception.
What compiler are you using? If you are using a GNU compiler, make sure that
you use egcs version 1.1 or later. From the egcs 1.1 C++ features page:
* Exception handling is now thread safe, and supports nested exceptions and
placement delete. Exception handling overhead on x86 is much lower with
GNU as 2.9.
For more information, go to the egcs homepage: http://egcs.cygnus.com/
Cheers,
Erik Jan Lingen
------------------------------
From: Urs Thuermann <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.misc,alt.linux,alt.os.linux,comp.os.linux.hardware
Subject: Compiling for x86 CPUs (Was: ... seperate "i686" tree for Redhat ...)
Date: 12 Apr 1999 14:28:40 +0200
Johan Kullstam <[EMAIL PROTECTED]> writes:
> -mcpu=i686 makes the compiler schedule for a i686 core. it uses only
> the i386 instruction set.
>
> -march=i686 enables usage of i686 instructions like cmov (which did
> not exist on i[345]86. it also implies cpu=i686.
>
> if you compile with -mcpu=i686, then yes, it would work with any of
> intels 32bit x86 cpus. however, by using -march=i686 you will
> introduce new op-codes which are not implemented on previous
> processors.
>
> based by my own experience with compiling various things with egcs
> on a pentiumpro, it is not very important for performance no matter
> what the cpu or arch settings are so long as you avoid pentium.
Could someone give some more details about this whole story, please?
I seem to have problems with this issue since a few days.
I have a Pentium II running in my server machine (which has only a
Herkules Video card and an Atari ST attached to the serial port) and a
i486dx2 in my diskless client running Linux and X11.
Both machines run the same 2.0.36 kernel image, the diskless machine
has its own /tftpboot dir on the server and shares the /usr with the
server (it mounts /usr read-only, though).
I run egcs-1.1.2 and gcc-2.7.2.3 which have both configured themselves
as a i686-pc-linux-gnu native compiler. What kind of code will these
produce if called without any -m... option? How should I invoke egcs
and gcc-2.7.2.3 to compile with maximum performance on i686 but with
the constraint that the code should also be executable on i486?
The problem I am observing is this: With egcs configured as described
above I compiled the glibc-2.1. When I copy /lib/lib*2.1.so and the
other glibc-2.1 files to the diskless' /tftpboot directory, the
diskless i486 won't boot anymore. The statically linked /sbin/init
seems ok, but (at least) the agetty's die immediately with an SIGILL
(illegal instruction). So I assume, glibc-2.1 is compiled in a way by
egcs so that it only runs on i686. This may, however, also be caused
by glibc itself. glibc-2.1 configured itself as i686-pc-linux-gnu
also, and obviously has code for this case, which is i686-specific,
e.g. in glibc-2.1/sysdeps/libm-i387/i686/s_fdim.S there are
fcomi/fucomi instructions. I think I read in this thread that these
instructions exist only on the i686, right?
What target should I specify to the glibc configure script? I guess
i486-pc-linu-gnu does't what I want, right?
However, then some i686 optimized routines are not used, although
AFAICT based on my little x86 knowledge, these seem to run on other
CPUs as well. For example
glibc-2.1/sysdeps/unix/sysv/linux/i386/i686/sysdep.h.
Maybe some pretty solution would be to have the i686-specific code in
the lib and have an exception handler on the i486 that emulates the
missing instructions, i.e. similar to the kernel's i387 emulation.
Does something like this exist and how much performance loss would
this cause compared to regular i486 code?
And what about the kernel? The 2.0.36 config help files state that
a kernel compiled for i486, pentium, or pentium pro will run on every
cpu except i386. But in 2.2.5 this has changed and it is stated that
code compiled for one CPU will not neccessarily run on a previous
CPU. Is this due to compiler options or because of different inline
assembly routines? I've looked at the make output and even if PPro
is selected, the compiler is called with -m486, but -D586 is changed
to -D686, so I assume some #ifdef selects between different inline
assembly code, that will possibly not run on all ix86 CPUs.
But what sense does the -m486 make, if the code does not necessarily
run on an i486 anyway?
OK, many questions and assumption in this posting. Can someone sched
some light on all this and answer/correct/acknowledge.
urs
P.S. I have removed the linux.redhat.misc group from the Newsgroups
line.
------------------------------
From: Alexander Dymerets <[EMAIL PROTECTED]>
Crossposted-To:
comp.os.linux.advocacy,comp.os.linux.development.apps,comp.os.linux.help,comp.unix.programmer
Subject: Re: CodeWarror for Linux (was: Re: Programming tools for ...)
Date: Mon, 12 Apr 1999 15:23:15 +0300
Hi!
> > It shouldn't
> > be hard to see that there is going to be a big difference in the
> > typical style of free software applications that are created or enhanced
> > by individuals, to personally help them get their work done vs.
> > the style of a commercial application that is developed by a software
> > company to sell to the largest number of users.
>
> That's exactly what's hard to see: why the fundamentals of process
> improvement haven't been accepted.
Powerful IDE like Codewarrior, MSDEV, BCB/Delphi is a greate thing, but
its development requires too much resources. In fact programmers, who
can write it don't need it. If you develope a large program during 10-12
months, any "visual" features will not make this process faster. All
you need is a good text editor, debugger and compiler. I'm a newbie
in Linux and I tried to use some IDE's (xwpe, code crusader). At last
I decided to use emacs + make + gdb.
Alexander
------------------------------
From: Karl Heyes <[EMAIL PROTECTED]>
Subject: Re: modprobe error at start up and shutdown
Date: Mon, 12 Apr 1999 13:23:28 +0100
Julio De Gregorio wrote:
> Hi,
>
> I'm running on RH5.2, I've just recompiled the kernel and the
> modules.
>
> Everything seems to work just fine but I get modprobe errors at start up
> like this
>
> modprobe: can't find module mod-ip3
> modprobe: can't find module mod-ip4
> modprobe: can't find module mod-ip4
> modprobe: can't find module mod-ip5
>
> this errors happen at system boot and shutdown. What are they warning
> me?
Not sure what mod-ipN refers to, but the kernel is requesting a service
provided by those modules. If it's anything like net-pf-N then it's
different
network transport services, ie appletalk, ipx etc.
add the following line to /etc/conf.modules
alias mod-ip3 off
.
.
.
>
>
> Note: this errors don't show with de demsg command... :(
doesn't have to, look at syslog.conf and the files in /var/log for instance.
karl.
------------------------------
From: Donald Ellis <[EMAIL PROTECTED]>
Subject: Fix for NLS catopen.
Date: Mon, 12 Apr 1999 10:47:37 -0400
Reply-To: [EMAIL PROTECTED]
For thoese that are interested. To fix the problem with using %l in the
NLSPATH env variable.
Using glibc-2.0.7 from the Redhat 5.2 distribution, change line 116 of
open_catalog.c from
buf[bufact++] = *tmp;
to
buf[bufact++] = *tmp++;
This has allowed me to us the %l in my NLSPATH.
Have fun.
------------------------------
From: "G. Sumner Hayes" <[EMAIL PROTECTED]>
Subject: Re: Compiling for x86 CPUs (Was: ... seperate "i686" tree for Redhat
Date: Mon, 12 Apr 1999 11:08:34 -0400
CC'ing sender since I cut the massive cross-posting -- never post to
more than 3 groups at a time, and try to limit it to one. I know that
you trimmed some groups, just not enough ;)
Urs Thuermann wrote:
> Could someone give some more details about this whole story, please?
> I seem to have problems with this issue since a few days.
>
> I have a Pentium II running in my server machine (which has only a
> Herkules Video card and an Atari ST attached to the serial port) and a
> i486dx2 in my diskless client running Linux and X11.
>
> Both machines run the same 2.0.36 kernel image, the diskless machine
> has its own /tftpboot dir on the server and shares the /usr with the
> server (it mounts /usr read-only, though).
Note: The 2.0.x kernels should be compiled with gcc 2.7.2.3 rather
than egcs. They don't contain some assembly fixes that are in the
2.2.x kernels, which means that egcs will probably work but might
Start World War III(TM). The 2.2.x kernels should compile and run
okay with egcs. Always specify what compiler you're using when filing
a bug report.
> I run egcs-1.1.2 and gcc-2.7.2.3 which have both configured themselves
> as a i686-pc-linux-gnu native compiler. What kind of code will these
> produce if called without any -m... option?
They'll produce code that will run on a 386 or better (assuming fp
emulation in-kernel).
> How should I invoke egcs
> and gcc-2.7.2.3 to compile with maximum performance on i686 but with
> the constraint that the code should also be executable on i486?
Basic flags:
gcc:
-O2 -m486
egcs:
-Os -mcpu=pentiumpro
-Os means to optimize for space; under egcs 1.1.2, it is generally
makes faster code than using -O2 (or -O3; -O4 and higher are the
same as -O3, and -O3 is just -O2 with function inlining). When egcs 1.2
is released (no earlier than June, possibly not until much later) then
-O2 will probably be better than -Os for speed (but -Os better for
space, of course). no-exceptions and no-rtti avoid some things needed
for full C++ support; don't use them if you're building a library that
you'll be calling through from C++.
Other flags that you may want:
-malign-loops=0 -malign-jumps=0 -malign-functions=0
Contrary to Intel docs, egcs developers claim these beat out 2 or 4
alignments. Generates smaller code. Probably a lose on a 486, you'll
have to test and see on a PPro/PII. I wouldn't use these in the kernel.
The 486 is finicky about alignment.
-fomit-frame-pointer
If you're not debugging. This'll save a register, which is a big deal
on ia32. (Note: ia32==Intel 32-bit architecture, it's Intel's official
way of saying x86. Includes 386,486,Pentium,Pentium Pro, Pentium II,
Pentium III, etc). Sometimes a big speed win.
-fno-exceptions -fno-rtti
If you're not building libraries that might be called through via C++.
Might be good to use when building the kernel with egcs??? Shouldn't
affect run-time too much, but could affect size.
Floating point:
-ffast-math
If you don't need absolute fp precision
-mno-ieee-fp
If you need even less
I think Mesa barfs with these, but povray works okay. Mesa might work
with -ffast-math, I'm not sure. I know it barfs with -mno-ieee-fp
since it requires IEEE floating point (duh). I think I got about a 12%
speedup in povray this way.
In my experience, the -fprofile-arcs stuff doesn't help with egcs
1.1.2. Fooling with the -fschedule-insns options sometimes helps
(try turning of insns and on insns2 or vice-versa and see if it helps),
but the difference is generally under 2% and tough to measure. Not
worth the time, really.
> The problem I am observing is this: With egcs configured as described
> above I compiled the glibc-2.1. When I copy /lib/lib*2.1.so and the
> other glibc-2.1 files to the diskless' /tftpboot directory, the
> diskless i486 won't boot anymore. The statically linked /sbin/init
> seems ok, but (at least) the agetty's die immediately with an SIGILL
> (illegal instruction). So I assume, glibc-2.1 is compiled in a way by
> egcs so that it only runs on i686. This may, however, also be caused
> by glibc itself. glibc-2.1 configured itself as i686-pc-linux-gnu
> also, and obviously has code for this case, which is i686-specific,
> e.g. in glibc-2.1/sysdeps/libm-i387/i686/s_fdim.S there are
> fcomi/fucomi instructions. I think I read in this thread that these
> instructions exist only on the i686, right?
Ahh. glibc includes a lot of assembly code on Intel. There's
probably some 686-specific code in there.
> What target should I specify to the glibc configure script? I guess
> i486-pc-linu-gnu does't what I want, right?
Why not? It seems like that ought to tell libc to use 486 asms
instead of 686 ones. Have you tried:
CFLAGS="-Os -mcpu=pentiumpro" ./configure i486-pc-linux --enable-omitfp
or similar? It ought to work, but I haven't tried it... If it doesn't,
check the README.
You might need CC=egcs depending on how you've got things
set up. If you're using gcc, change the CFLAGS accordingly. Don't
use -fomit-frame-pointer, it'll fail when building debugging libs. The
--enable-omitfp option tells glibc to use -fomit-frame-pointer when
appropriate.
> And what about the kernel? The 2.0.36 config help files state that
> a kernel compiled for i486, pentium, or pentium pro will run on every
> cpu except i386. But in 2.2.5 this has changed and it is stated that
> code compiled for one CPU will not neccessarily run on a previous
> CPU. Is this due to compiler options or because of different inline
> assembly routines?
Newer features are used, new TSC among them. These features don't
exist on 386/486. A 486 compile will run on a PPro, of course.
2.2.x uses a lot more of these features, especially with SMP.
> But what sense does the -m486 make, if the code does not necessarily
> run on an i486 anyway?
gcc doesn't have -m586 or -m686 or anything like that. gcc 2.7.2 is
still the standard compiler for building the kernel (especially since
it is the one that Linus uses). So -m486 is the best you can do.
The kernel also uses -malign-*=2, which is possibly not a win but also
not a big loss. If you're building for an embedded system or something
then you might consider tweaking those. Otherwise, it's not worth
changing them unless you want to experiment.
/usr/src/linux/arch/i386/Makefile is the place to adjust.
--Sumner
------------------------------
** 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
******************************
