Linux-Development-Sys Digest #618, Volume #6 Mon, 12 Apr 99 20:14:05 EDT
Contents:
Re: Compiling for x86 CPUs (Was: ... seperate "i686" tree for Redhat ("G. Sumner
Hayes")
Re: Linux NFS server, Solaris cient, bad news ... (Leslie Mikesell)
Re: a problem with scanf (Jack Klein)
Re: GDB broken in Redhat 5.2? (Marc Lefranc)
http://www.linuxchick.com ("Jenni Pr0n")
http://www.linuxchick.com ("Jenni Pr0n")
http://www.linuxchick.com ("Jenni Pr0n")
Re: Compiling for x86 CPUs (Was: ... seperate "i686" tree for Redhat ...) (StatiK)
http://www.linuxchick.com ("Jenni Pr0n")
Re: Linux Servers, what to buy? (Don Baccus)
Running process without control terminal (AMAE)
http://www.linuxchick.com ("Jenni Pr0n")
Re: linux 2.2.5, SMP, device driver (bill davidsen)
tiocremote equivalent for linux tty / pty ([EMAIL PROTECTED])
tcp_send_skb() ("sukesh")
Re: Cannot execute /bin/bash (Matt Foster)
----------------------------------------------------------------------------
From: "G. Sumner Hayes" <[EMAIL PROTECTED]>
Subject: Re: Compiling for x86 CPUs (Was: ... seperate "i686" tree for Redhat
Date: Mon, 12 Apr 1999 12:44:48 -0400
Urs Thuermann wrote:
>
> "G. Sumner Hayes" <[EMAIL PROTECTED]> writes:
> >
> > > 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
>
> Is this different from -O2 without -m<anything> on gcc-2.7.2.3 when it
> is configured as i686-pc-linux-gnu? Since I asked for max performance
> for i686 I interpret your answer to mean gcc only knows 386 and 486
> and -m486 doesn't make a diff in my case, since I didn't configure for
> 386. Is that right?
I don't know whether your gcc defaults to -m486 or not.
> > egcs:
> > -Os -mcpu=pentiumpro
>
> Same question again: is this different from -Os without -m<anything>
> when egcs is configured for i686?
I don't know. I don't know that configuring for i686-pc-linux causes
default output to be -mpentiumpro. It might, it might not. I use
the same build of the compiler on a number of machines and use the
appropriate -m flags on each one.
> BTW, are there differences in instruction set and/or egcs code
> generation between PII and PPro?
No. PII and PPro are the same instruction set (except MMX). The core
is almost identical between the two; the socket/slot is different,
cache is offloaded on the PII, and a few other differences.
egcs uses -mpentiumpro for all of the 6th generation Intel chips.
> > Contrary to Intel docs, egcs developers claim these beat out 2 or 4
> > alignments. Generates smaller code. Probably a lose on a 486,
>
> By "lose" you mean performance wise, or do you mean it crashes on 486?
Performance-wise. It should run okay, just a bit slower.
> > -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.
>
> Oops. Do -fno-exceptions and -fno-rtti affect the cc1 compiler? I've
> thought it's only for cc1plus.
No, it affects cc1 as well. You need to be able to throw exceptions
through C libraries, so stack unwinding information is generated unless
you use -fno-exceptions. I don't know whether rtti requires C support or
not.
In simple cases there might not be any stack unwinding code. Like I
said, -fexceptions shouldn't slow things down but could make them a
little bigger.
> > 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
>
> Unfortunately, I guess it won't then use the code from
> glibc-2.1/sysdeps/unix/sysv/linux/i386/i686 (and probably other
> similar cases), which seems ok for all x86 but faster on i686 (as the
> comment states). Anyway, this is what I will try tonight and see if
> my diskless i486 machine will work with glibc-2.1 compiled this way.
>
Good luck.
> > 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.
>
> I've last read the code using TSC in do_fast_gettimeoffset() a few
> month ago in 2.0.35 or 36. IIRC, there is a check if the CPU has the
> needed capability. But maybe, there are places in 2.2.x where
> PII/PPro features are used without such checks.
Also, some TSCs are broekn (especially some of the early-generation
clones, newer ones are ok) and picking CPU under 2.2.x helps tell the
kernel which bugs to work around. TSC isn't the only feature, just an
example picked out of a hat.
> > > 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.
>
> Hm. Again the question: If I get you right, -m486 is the best since
> gcc doesn't know code generation for 586 and 686 anyway. But it is
> the same as without -m486 unless gcc is configured for 386. That is,
> gcc knows only -m486 and -mno-486 (meaning 386), as the man page says?
Yes.
Also, playing with the options used to compile the kernel may be
counterproductive since the kernel uses a lot of inline asms and C
that are tweaked based on the output of the compiler with particular
settings. It could help, but it could hurt.
--Sumner
------------------------------
From: [EMAIL PROTECTED] (Leslie Mikesell)
Crossposted-To: matrix.lists.linux.kernel
Subject: Re: Linux NFS server, Solaris cient, bad news ...
Date: 12 Apr 1999 15:57:48 -0500
In article <[EMAIL PROTECTED]>,
mlw <[EMAIL PROTECTED]> wrote:
>Wouldn't patches for nfsd in the 2.2.3 kernel be in the 2.2.5 kernel?
Not the ones needed to interoperate with non-linux clients. If you
unpack the knfsd tar file from
ftp://ftp.varesearch.com/pub/support/hjl/knfsd/.
there are kernel patches for 2.2.5 as well as the current versions
of the knfsd utility programs.
I'm surprised at how little I've heard about this problem. Are there
not many people using Linux as a server in mixed environments?
Les Mikesell
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Jack Klein)
Crossposted-To: comp.lang.c
Subject: Re: a problem with scanf
Date: Mon, 12 Apr 1999 21:18:13 GMT
On Mon, 12 Apr 1999 21:30:40 +0200, Francesc Oller
<[EMAIL PROTECTED]> wrote in comp.lang.c:
> executing the following code in LINUX:
>
> ...
> void main(void)
> {
> char c;
> setvbuf(stdin,NULL,_IONBF,0);
> tty_raw(0);
> scanf("%c",&c);/*c=getchar();*/
> tty_reset(0);
> printf("c='%c'\n",c);
> }
>
> where tty_raw puts the terminal in RAW mode and tty_reset
> returns it to COOKED mode, makes me to have to press two chars
> in order for scanf to get the first (i.e printf doesn't
> execute until I press twice).
>
> However getchar works as expected (only one keyb press)
> WHY?
>
> Francesc Oller
<Jack>
This question has nothing to do with the C language. In fact it stops
being legal C when you typed "void main(void)" because the C language
always has and still does require that main be defined with a return
type of int.
A bigger issue is that there are no functions named setvbuf(),
tty_raw() or tty_reset() in the C language. Please keep your Linux
specific questions in the Linux groups and out of comp.lang.c.
But if you want to know why scanf() is evil and should be avoided in
almost all situations, especially for live user input, see the
comp.lang.c FAQ.
FAQ for comp.lang.c
http://www.eskimo.com/~scs/C-faq/top.html
</Jack>
--
Do not email me with questions about programming.
Post them to the appropriate newsgroup.
Followups to my posts are welcome.
------------------------------
From: Marc Lefranc <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: GDB broken in Redhat 5.2?
Date: 12 Apr 1999 23:39:44 +0200
[EMAIL PROTECTED] (Peter Samuelson) writes:
> [Louis S Leclerc <[EMAIL PROTECTED]>]
> > The fix I used was:
> >
> > 1.) Install the original source rpm of the redhat distribution
> > rpm -i glibc.....
> > 2.) Edit the glibc-spec file /usr/src/redhat/SPECS/glibc....
> > (There should be some Entry line CCFLAGS = "-g",
> > one should simply delete it)
>
> I still think
>
> strip --strip-debug /lib/libc.so.6
>
> would be a lot easier, and several orders of magnitude faster.
>
Well, if at least he has taken advantage of this to add optimization
flags to speed up his libc :-)
--
_____________________________________________________________
Marc Lefranc, Charge de Recherche au CNRS
Laboratoire de Physique des Lasers, Atomes, Molecules
Bat P5, UFR de Physique
Universite des Sciences et Technologies de Lille
F-59655 Villeneuve d'Ascq CEDEX (FRANCE)
e-mail: [EMAIL PROTECTED] ; FAX : +33 (0)3 20 33 70 20
_____________________________________________________________
------------------------------
From: "Jenni Pr0n" <[EMAIL PROTECTED]>
Subject: http://www.linuxchick.com
Date: Mon, 12 Apr 1999 22:20:01 +0100
http://www.linuxchick.com
------------------------------
From: "Jenni Pr0n" <[EMAIL PROTECTED]>
Subject: http://www.linuxchick.com
Date: Mon, 12 Apr 1999 22:20:01 +0100
http://www.linuxchick.com
------------------------------
From: "Jenni Pr0n" <[EMAIL PROTECTED]>
Subject: http://www.linuxchick.com
Date: Mon, 12 Apr 1999 22:20:01 +0100
http://www.linuxchick.com
------------------------------
From: [EMAIL PROTECTED] (StatiK)
Crossposted-To: comp.os.linux.misc,alt.linux,alt.os.linux,comp.os.linux.hardware
Subject: Re: Compiling for x86 CPUs (Was: ... seperate "i686" tree for Redhat ...)
Reply-To: [EMAIL PROTECTED]
Date: Mon, 12 Apr 1999 22:02:32 GMT
Buy another Pro / P][ and get rid of the dx2!!
StatiK
On 12 Apr 1999 14:28:40 +0200, Urs Thuermann
<[EMAIL PROTECTED]> wrote:
>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: "Jenni Pr0n" <[EMAIL PROTECTED]>
Subject: http://www.linuxchick.com
Date: Mon, 12 Apr 1999 22:20:01 +0100
http://www.linuxchick.com
------------------------------
Subject: Re: Linux Servers, what to buy?
From: [EMAIL PROTECTED] (Don Baccus)
Date: 12 Apr 1999 14:29:40 PST
In article <[EMAIL PROTECTED]>, Scott Mayberry <[EMAIL PROTECTED]> wrote:
>If anyone has some other suggestions for an economical
>Linux server please respond! =)
check out http://www.tdl.com/~netex. This is the web page
of a custom system builder (most Intel, it appears these
days, but also Alpha based and in the past at least Sun).
They sell 'em with Linux or (if you make them) NT.
Their web page is a great resource for folks exploring
hardware options. They list typical suggested configurations,
but the site's far more useful than this. For each configuration,
they list each component in exhaustive detail (including the
brand of exhaust fan). Each component is actually a hyperlink
to a separate page that lists a suite of other components,
with their editorial comments about their view of the tradeoffs
involved with each.
So, for instance, if you check out their sample PII/PIII workstation
you'll find they suggest an ASUS motherboard with onboard UWII.
Click on the motherboard, and you can explore motherboards from
ASUS or other manufacturers with, say, no UWII, etc etc.
At this level, click on the ASUS board description and they
send you to the ASUS site.
They do this for every component, so you can quickly poke
around and see why they make the choices they do, and
what alternative choices they think are reasonable.
They also have a lot of information on Intel, for
instance a history of different chip introductions
of various cpus and clock speeds, graphs of past
price trends (and predictions of future trends), tech
info on various cpus, that kind of thing.
You don't have to register or anything to use this site,
you're under no obligation to buy, etc etc. They started
as a co-op of Berkley students, engineers, professors
etc and their website reflects this. For instance, I
studied options for a couple of days, got ansy, and just
went out and bought components myself and put it together
over the weekend because I didn't want to wait for mail-order!
If you do buy from them, they'll ship the parts to you
assembled, or unassembled - at the same price. Fast
turn-around isn't their forte, though, the site gives
you their next available build date and it seems to
be about two weeks ahead most of the time.
--
- Don Baccus, Portland OR <[EMAIL PROTECTED]>
Nature photos, on-line guides, at http://donb.photo.net
------------------------------
From: [EMAIL PROTECTED] (AMAE)
Subject: Running process without control terminal
Date: 12 Apr 1999 20:37:02 GMT
What does it mean to say that a process X is running without control
terminal. For example, ps -x shows processes running with or without
control terminal. How does a process get in that state?
Thanks
--
Ayman Elsaedi
Georgia Institute of Technology, Atlanta Georgia, 30332
Email: [EMAIL PROTECTED]
------------------------------
From: "Jenni Pr0n" <[EMAIL PROTECTED]>
Subject: http://www.linuxchick.com
Date: Mon, 12 Apr 1999 22:20:01 +0100
http://www.linuxchick.com
------------------------------
From: [EMAIL PROTECTED] (bill davidsen)
Subject: Re: linux 2.2.5, SMP, device driver
Date: 12 Apr 1999 22:00:28 GMT
In article <[EMAIL PROTECTED]>,
Lorenz Hahn <[EMAIL PROTECTED]> wrote:
| At the first look a cache problem, but why does it occur only when two CPU's
| are involved? Any known caveats?
You got a great answer, I'll only note one more thought, when you built
the kernel did you use the advanced clock stuff? You need that with SMP.
Sorry, no config file on this machine, can't tell you exactly the
wording.
--
bill davidsen <[EMAIL PROTECTED]> CTO, TMR Associates, Inc
What I find astonishing is not that my cat has started to sing, but that
he has taken up country-western. This morning he sang `Momma, don't let
your kittens grow up to be barn cats' in the shower, followed by a
pretty decent yodeling version of `Roundup time in Texas when the catnip
is in bloom.'
------------------------------
From: [EMAIL PROTECTED]
Subject: tiocremote equivalent for linux tty / pty
Date: Mon, 12 Apr 1999 22:51:48 GMT
Hello,
is there an equiavalent for
linux tty 's / pty 's
for the BSD
TIOCREMOTE ioctl setting?
TIA, this will help me a lot.
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: "sukesh" <[EMAIL PROTECTED]>
Subject: tcp_send_skb()
Date: Mon, 12 Apr 1999 19:01:37 -0400
Hi,
I am trying to trace the path of a tcp packet through the kernel.
At tcp_send_skb() ... the packet is written to the kernel memory. Next
ip_queue_xmit() is called. How does the call to ip_queue_xmit() made ?
Thanks,
Sukesh
------------------------------
From: Matt Foster <[EMAIL PROTECTED]>
Subject: Re: Cannot execute /bin/bash
Date: 12 Apr 1999 22:51:16 GMT
John Coppens <[EMAIL PROTECTED]> wrote:
: Hi all!
: Since a few weeks, I detected I could not login as a normal user
: anymore.
: Login, yes, but after the mail message, 'login' says:
: Cannot execute /bin/bash: Permission denied
Try checking the permissions on /lib & /usr/lib & it's contents.
Matt
------------------------------
** 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
******************************
