Linux-Development-Sys Digest #748, Volume #6 Thu, 27 May 99 10:14:59 EDT
Contents:
read() not interrupted by SIGINT in linux? why? ([EMAIL PROTECTED])
Re: Free Celeron Linux Workstation (bryan)
Re: Anyway to recover origianl kernel source from RH6.0-ified kernel-source? (David
T. Blake)
Re: SMP needlessly migrating processes between processors? (bryan)
Re: Anyway to recover origianl kernel source from RH6.0-ified kernel-source? (Kelley
Spoon)
Re: read() not interrupted by SIGINT in linux? why? (Bas de Bakker)
Re: read() not interrupted by SIGINT in linux? why? (Andreas Jaeger)
/dev/virtualcom ... Minor and Major numbers ? (FX)
ELF header specifications (LARS GRUNEWALDT)
Re: Support for motherboard monitoring ? (jamiemm)
Re: read() not interrupted by SIGINT in linux? why? (Villy Kruse)
SMP: Inconsistent variable MTRR settings ??? (You Wish)
source for the route utility (hwj)
loading version nonsensitive module into version sensitive kernel? (Rolf Welde Skeie)
Re: source for the route utility ([EMAIL PROTECTED])
Re: ELF header specifications (J.H.M. Dassen (Ray))
Re: Terabite Plus Filesystems (Bob Hoekstra)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.unix.programmer
Subject: read() not interrupted by SIGINT in linux? why?
Date: Thu, 27 May 1999 05:19:01 GMT
I found some curious behaviour on linux during simple
reads... when a SINGIN is sent, linux doesn't seem to want
to interrupt the read and set errno to EINTR, as the
man page says it should. The right signal handler is called,
but Linux plonks me back into the original read!
For instance, given the few lines of code listed at
the end of this post, Solaris behaves the following
way when I hit ctl-C:
skunk% strange
^CCaught signal 2!
read() returned -1
^CCaught signal 2!
read() returned -1
^CCaught signal 2!
read() returned -1
However, Linux 2.2 does the following:
[raoul@slinky raoul]$ strange
^CCaught signal 2!
^CCaught signal 2!
^CCaught signal 2!
Does anyone have any ideas why Linux does this, or
what I need to do for the read to be interrupted
with an EINTR in errno?
Here's the code:
/* --------------------------------------------------- */
#include <signal.h>
void handler(int i)
{
printf("Caught signal %d!\n", i);
signal(SIGINT, handler);
}
main()
{
char c;
int i;
signal(SIGINT, handler);
while ((i = read(0, &c, 1)) != 1)
printf("read() returned %d\n", i);
}
/* --------------------------------------------------- */
--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
------------------------------
From: bryan <[EMAIL PROTECTED]>
Subject: Re: Free Celeron Linux Workstation
Date: Thu, 27 May 1999 01:21:45 GMT
Mike Jacobs <[EMAIL PROTECTED]> wrote:
: Brandon Fuhr wrote:
: >
: > Visit http://www.atipa.com/ and enter to win a free Linux Celeron
: > Workstation. The winner will be selected at the LinuxWorld Expo in San
: > Jose, CA on August 12, 1999. Atipa has been a leading provider of Linux
: > Clusters, Servers, and Workstations since 1994.
: What type of Celeron ? Fast, slow, etc.
they're ALL fast - just some are faster than others ;-)
--
Bryan
------------------------------
From: [EMAIL PROTECTED] (David T. Blake)
Subject: Re: Anyway to recover origianl kernel source from RH6.0-ified kernel-source?
Date: 26 May 1999 16:38:00 -0700
Jamie Walker <[EMAIL PROTECTED]> writes:
>I've just upgraded to Redhat 6.0, mainly for the 2.2 kernel. My problem
>is, the kernel-source-2.2.5-15.rpm package distributed on the CD
>contains a modified source tree, and the patches from kernel.org fail on
>it :(
>
>Is there any way to undo the modifications made by the Redhat team, so
>that I can apply the diff patches and move to 2.2.9 without having to
>download the whole thing?
Try this. Stop and get a six pack.
Start a download. Open a beer.
By the time you finish the beer, you should have a
kernel source.
I almost never use RPMs for new kernels. Somehow it is
more fun to download it, unpack it, and change the links
so that /usr/include/linux and /usr/include/asm* point at
the right places.
--
Dave Blake
[EMAIL PROTECTED]
------------------------------
From: bryan <[EMAIL PROTECTED]>
Subject: Re: SMP needlessly migrating processes between processors?
Date: Thu, 27 May 1999 01:22:42 GMT
Arun Sharma <[EMAIL PROTECTED]> wrote:
: On Wed, 26 May 1999 04:46:26 GMT, Skip Montanaro <[EMAIL PROTECTED]> wrote:
: > I recently started running RH 5.2 on a dual P-II box (Tyan Thunderbolt
: > motherboard). I'm running kernel 2.2.9. When I run a single
: > CPU-intensive process and launch xosview to watch things, I see a
: > pattern of CPU load that suggests to me that the single busy process is
: > migrating back and forth between the processors roughly every half
: > second or so. I see a little square wave pattern for the user time
: > portion of the two CPU's graphs. The patterns for the two processors
: > are roughly 180 degrees out of phase with one another. It seems to me
: > that the scheduler isn't weighting things heavily enough to keep
: > processes from migrating too much. Is this normal? Isn't there a cache
: > flush overhead when migrating processes between processors?
: >
: You can increase PROC_CHANGE_PENALTY in include/asm/smp.h to prevent
: the migration.
I tried that once and had bad results. but I admit I don't know the
true effects of incr or decr this value. are there guidelines? what
does x% increase do vs y% incr? etc, etc.
--
Bryan
------------------------------
From: [EMAIL PROTECTED] (Kelley Spoon)
Subject: Re: Anyway to recover origianl kernel source from RH6.0-ified kernel-source?
Date: 27 May 1999 01:32:45 GMT
On Wed, 26 May 1999 23:20:00 +0100, Jamie Walker <[EMAIL PROTECTED]>
wrote:
> I've just upgraded to Redhat 6.0, mainly for the 2.2 kernel. My problem
> is, the kernel-source-2.2.5-15.rpm package distributed on the CD
> contains a modified source tree, and the patches from kernel.org fail on
> it :(
Use the source rpm. It should be where RH puts their SRPMS dir on the cd,
and you just run rpm -Uvh foo.src.rpm to install it. This should put the
pristine sources in /usr/src/redhat/SOURCES, any patches or default
configs for the RPM in SOURCES as well, and a spec file into
/usr/src/redhat/SPECS. You should at least take a look at the %prep and
%build sections of the spec file to see what they're doing in case you
want/need to patch in something like pcmcia-cs.
For the kernel, there should also be a kernel-config file that shows you
what options they set.
Best of luck,
--
Kelley Spoon <[EMAIL PROTECTED]>
Linux Developer
Pacific HiTech, Inc. (http://www.pht.com)
------------------------------
From: Bas de Bakker <[EMAIL PROTECTED]>
Crossposted-To: comp.unix.programmer
Subject: Re: read() not interrupted by SIGINT in linux? why?
Date: 27 May 1999 08:22:26 +0200
>>>>> "ro" == red october <[EMAIL PROTECTED]> writes:
ro> I found some curious behaviour on linux during simple
ro> reads... when a SINGIN is sent, linux doesn't seem to want to
ro> interrupt the read and set errno to EINTR, as the man page
ro> says it should. The right signal handler is called, but Linux
ro> plonks me back into the original read!
The signal() routine isn't really portable. It is much better to use
sigaction(). See the man page for usage details.
Bas.
------------------------------
From: Andreas Jaeger <[EMAIL PROTECTED]>
Crossposted-To: comp.unix.programmer
Subject: Re: read() not interrupted by SIGINT in linux? why?
Date: 27 May 1999 08:28:26 +0200
>>>>> red october writes:
> I found some curious behaviour on linux during simple
> reads... when a SINGIN is sent, linux doesn't seem to want
> to interrupt the read and set errno to EINTR, as the
> man page says it should. The right signal handler is called,
> but Linux plonks me back into the original read!
> For instance, given the few lines of code listed at
> the end of this post, Solaris behaves the following
> way when I hit ctl-C:
> skunk% strange
> ^CCaught signal 2!
> read() returned -1
> ^CCaught signal 2!
> read() returned -1
> ^CCaught signal 2!
> read() returned -1
> However, Linux 2.2 does the following:
> [raoul@slinky raoul]$ strange
> ^CCaught signal 2!
> ^CCaught signal 2!
> ^CCaught signal 2!
> Does anyone have any ideas why Linux does this, or
> what I need to do for the read to be interrupted
> with an EINTR in errno?
>From the glibc 2 FAQ which should be installed somewhere on your
system:
3.7. Why don't signals interrupt system calls anymore?
{ZW} By default GNU libc uses the BSD semantics for signal(), unlike Linux
libc 5 which used System V semantics. This is partially for compatibility
with other systems and partially because the BSD semantics tend to make
programming with signals easier.
There are three differences:
* BSD-style signals that occur in the middle of a system call do not
affect the system call; System V signals cause the system call to
fail and set errno to EINTR.
* BSD signal handlers remain installed once triggered. System V signal
handlers work only once, so one must reinstall them each time.
* A BSD signal is blocked during the execution of its handler. In other
words, a handler for SIGCHLD (for example) does not need to worry about
being interrupted by another SIGCHLD. It may, however, be interrupted
by other signals.
There is general consensus that for `casual' programming with signals, the
BSD semantics are preferable. You don't need to worry about system calls
returning EINTR, and you don't need to worry about the race conditions
associated with one-shot signal handlers.
If you are porting an old program that relies on the old semantics, you can
quickly fix the problem by changing signal() to sysv_signal() throughout.
Alternatively, define _XOPEN_SOURCE before including <signal.h>.
For new programs, the sigaction() function allows you to specify precisely
how you want your signals to behave. All three differences listed above are
individually switchable on a per-signal basis with this function.
If all you want is for one specific signal to cause system calls to fail and
return EINTR (for example, to implement a timeout) you can do this with
siginterrupt().
Andreas
--
Andreas Jaeger [EMAIL PROTECTED] [EMAIL PROTECTED]
for pgp-key finger [EMAIL PROTECTED]
------------------------------
From: FX <[EMAIL PROTECTED]>
Subject: /dev/virtualcom ... Minor and Major numbers ?
Date: Thu, 27 May 1999 10:30:39 +0200
Reply-To: [EMAIL PROTECTED]
Hi,
I would like to create a virtual device such as /dev/virtualcom, that
can be used by PPPD
for example !!!!
A program will transfer data between /dev/modem and /dev/virtualcom,
will observe all
the traffic, and will be able to modify this traffic. For example send
+++ string to the
modem to interrupt for a moment the ppp connexion ....
To do this I must use mknod, and use minor and major numbers .... What
are theses
numbers, and what numbers should I use for my purpose ??
Thanks
FX
------------------------------
From: LARS GRUNEWALDT <[EMAIL PROTECTED]>
Subject: ELF header specifications
Date: Thu, 27 May 1999 11:19:32 +0200
Hi,
I'm in the need of _exact_ specifications of the ELF executable header
(I want to supply it in our own operating system). Where can I find a
description how the ELF executable header generated by ld is to be used?
thanx for spending time,
Lars Grunewaldt
------------------------------
From: jamiemm <[EMAIL PROTECTED]>
Subject: Re: Support for motherboard monitoring ?
Date: Thu, 27 May 1999 02:09:17 -0700
On 27 May 1999, Andrew Daviel wrote:
> I just wondered if there was a package somewhere to read the
> motherboard status (fan speed, temperature etc.) off e.g.
> Asus motherboards.
>
> --
> Andrew Daviel, TRIUMF, Canada
>
>
Try the lm_sensors package. http://www.netroedge.com/~lm78
Works great here, minus a few issues with my strange M/B (Aopen AX6B) and
its chipset (gl518, I forget the manufacturer).
Good luck!
--
Jamie M
"On the other hand, there are different fingers"
-Steven Wright
------------------------------
From: [EMAIL PROTECTED] (Villy Kruse)
Crossposted-To: comp.unix.programmer
Subject: Re: read() not interrupted by SIGINT in linux? why?
Date: 27 May 1999 09:15:04 +0200
In article <[EMAIL PROTECTED]>,
Bas de Bakker <[EMAIL PROTECTED]> wrote:
>>>>>> "ro" == red october <[EMAIL PROTECTED]> writes:
>
> ro> I found some curious behaviour on linux during simple
> ro> reads... when a SINGIN is sent, linux doesn't seem to want to
> ro> interrupt the read and set errno to EINTR, as the man page
> ro> says it should. The right signal handler is called, but Linux
> ro> plonks me back into the original read!
>
>The signal() routine isn't really portable. It is much better to use
>sigaction(). See the man page for usage details.
>
>Bas.
With glibc the signal function works like on BSD, that is, the handler
will stay installed, the signal is blocked while the signal handler is
running, and some system calls like read are restarted when the signal
handler returns. This means that the read system call won't return with
an EINTR error; convinient in som cases, a serious problem in other cases.
With sigaction you can separately control these behaviours.
With the libc5 libary the signal would follow the System V behaviour,
at least any interrupted system call won't be restarted, but return with
and error and error code 4 EINTR.
Villy
------------------------------
From: [EMAIL PROTECTED] (You Wish)
Crossposted-To: comp.os.linux.setup
Subject: SMP: Inconsistent variable MTRR settings ???
Date: Thu, 27 May 1999 11:21:18 GMT
Hi there,
I just installed RH 6.0 on a dual P2-266 system (QDI motherboard) and I get
the following message when booting:
...
*IRQ mapping table*
mtrr: your CPUs had inconsistent variable MTRR settings
mtrr: probably your BIOS does not setup all CPUs
PCI: PCI BIOS revision 2.10 entry at 0xfb530
...
Can someone give me more info. on this? Should I care at all?
Thanks,
Marc
------------------------------
From: hwj <[EMAIL PROTECTED]>
Subject: source for the route utility
Date: Thu, 27 May 1999 13:51:00 +0200
Does anybody know where i can find the source code for the route
utility?
TIA
Henrik Winther Jensen
[EMAIL PROTECTED]
------------------------------
From: Rolf Welde Skeie <[EMAIL PROTECTED]>
Crossposted-To: fa.linux.kernel
Subject: loading version nonsensitive module into version sensitive kernel?
Date: Thu, 27 May 1999 14:18:46 +0200
Hi!
We have a driver which (unfortunately) is not open source.
We deliver this driver in binary format (as an rpm) to customers.
Customers sometimes add patches or use newer kernels than what
we compiled with. With versioning (which is default on and *mostly* a
good thing in my opinion) symbol names change and our driver module does
not load. We do not wish to tell our customers to disable versioning.
Is there any way of getting around this?
Our only option at this time seems to be demangling the ksyms
and our module symbols, match them and replace the module symbol
references with the new ones in ksyms (using libbfd or some such).
Not an ideal solution...
What is the "correct" way of doing it? Even with open source kernel
external modules one would like to be able to avoid recompiling them
after doing a minor change in the kernel configuration??
Enlighten me, but please be gentle ;-)
Sincerely
--
Rolf Welde Skeie Senior Design Engineer
_____________________________________________________________________
Email : mailto:[EMAIL PROTECTED] Scali AS (http://www.scali.com)
Tlf : (+47) 6384 6705 Hvamstubben 17 oo
Fax : (+47) 6384 4005 2013 Skjetten __________ m/V\> _
Home : (+47) 2214 8987 NORWAY . . :: . 077-0
Mob : (+47) 9248 4511 ----------------------
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: source for the route utility
Reply-To: [EMAIL PROTECTED]
Date: Thu, 27 May 1999 12:25:43 GMT
hwj <[EMAIL PROTECTED]> wrote:
> Does anybody know where i can find the source code for the route
> utility?
It is from the net-tools package
------------------------------
From: [EMAIL PROTECTED] (J.H.M. Dassen (Ray))
Subject: Re: ELF header specifications
Date: 27 May 1999 12:41:02 GMT
LARS GRUNEWALDT <[EMAIL PROTECTED]> wrote:
> I'm in the need of _exact_ specifications of the ELF executable header
>(I want to supply it in our own operating system).
Check out ftp://tsx-11.mit.edu/pub/linux/packages/GCC/ , in particular
ELF.doc.tar.gz and elf.ps.gz.
ELF isn't Linux-specific, so another newsgroup might be more appropriate,
e.g. gnu.utils.bug which is read by the GNU binutils maintainers.
HTH,
Ray
--
Cyberspace, a final frontier. These are the voyages of my messages,
on a lightspeed mission to explore strange new systems and to boldly go
where no data has gone before.
------------------------------
From: Bob Hoekstra <[EMAIL PROTECTED]>
Crossposted-To:
comp.os.ms-windows.nt.admin.misc,comp.sys.sun.admin,comp.sys.hp.misc,comp.os.linux.hardware
Subject: Re: Terabite Plus Filesystems
Date: Thu, 27 May 1999 15:05:52 +0200
Interesting project! What you don't say is how many files you have per
directory. This is particularly important for NT.
I feel that if your data is important and you want a file server that comes
up and stays up, you should discount NT immediately. I have heard some
horror stories about NT with very large directories -- as a test, try
creating 100,000 small files in a single directory and pointing Windows
Exploder at it. You will find that you can go and have a cup of coffee and a
cigarette while the screen updates! This sort of activity affects the
performance of the server as a whole.
While I am a fan of Linux, but I would think twice about this sort of task
for it. This leaves (IMHO) only HPUX and Solaris from your list. My personal
preference is for Solaris, but I don't think that's critical and I cannot
really justify it.
Furthermore, I would resist using intel-based hardware. PCs are just not
built to the same standard as most of the "real" Unix boxes from Sun, HP,
IBM, SGI, etc. The one exception that comes to mind would be the Sequent
range. This brings in some new flavours of Unix (AIX, Irix, Dynix, etc), and
pretty much any of them will do a good job, and you seem to be open to this
- maybe you should look for a good deal on a second-hand box (ex-rentals are
often a good buy) rather than going for intel just to save money.
Lastly, consider if a 64 bit hardware/OS combination may benefit. UltraSPARC
+ Solaris 7 is one option here, but so is DEC Unix (or whatever Compaq is
calling it now) on an Alpha box.
Jake Maizel wrote:
> We are building a system that needs to handle a huge number of files
> that are 500KB-1MB in size (1-2TB total). Our only constraint right now
> is the desire to use intel-based hardware for the host computers for
> cost purposes. My question really is regarding which OS would best
> handle a filesystem of this size. We are using lots of unix and NT so
> we don't have a bias one way but we don't have experience with any OS
> using a filesystem this big. What we are considering for hardware are
> HP LPr hosts connected to a AL-FC RAID system (probably HP). We would
> want to pick either HPUX, linux, NT or Solaris x86. Any experience
> that could be passed would be great.
>
> jake
The contents of this message express only the sender's opinion.
This message does not necessarily reflect the policy or views of
my employer, Merck & Co., Inc. All responsibility for the statements
made in this Usenet posting resides solely and completely with the
sender.
------------------------------
** 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
******************************
