Linux-Development-Sys Digest #727, Volume #8 Wed, 16 May 01 23:13:12 EDT
Contents:
Re: SIGSEGV is not blocking (Robert Redelmeier)
enum elements NET_BH in interrupt.h ("gary zhu")
net access to unix computers ("Shaun Troedson")
Re: Odd behaivour with select and raw sockets (Greg Copeland)
Re: SIGSEGV is not blocking (David Schwartz)
Re: AIX coff binaries ("BrentRBrian")
Re: SIGSEGV is not blocking (Eric P. McCoy)
Re: passing messages to a forked thread (Greg Copeland)
Re: net access to unix computers (Jim Cochrane)
Re: Linux 2.4 network performances (compared to 2.2) (Greg Copeland)
Re: Will Linux recognize >4GB RAM on Pentium-III Xeon? (Greg Copeland)
[Q]What is frame buffer?? ("songjg")
Re: creating files under /proc? (Greg Copeland)
Re: SIGSEGV is not blocking (Robert Redelmeier)
Re: SIGSEGV is not blocking
Re: Raid A0 patch with Kernel 2.2.17 and ReiserFS
Re: Raid A0 patch with Kernel 2.2.17 and ReiserFS (Chris Cox)
----------------------------------------------------------------------------
Date: Wed, 16 May 2001 19:39:56 -0500
From: Robert Redelmeier <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.programming.threads
Subject: Re: SIGSEGV is not blocking
Michael J. Saletnik wrote:
>
> If I explicitly block the SIGSEGV from being delivered, I would not
> expect the process still to terminate on a SIGSEGV.
Then how would you like it to terminate? SIGSEGV is an
urgent make-or-break signal.
> For example, in the example code shown it *is* perfectly acceptable to
> continue down the codeline since we don't do anything with the null
> value that we've tried to dereference and faulted on.
Then why was it in the code? As a general rule, data is
used. It is possible for clever kernel code to skip the
faulting instruction, but it would be extremely unwise to
do so. Programs are buggy enough without having some
instructions omitted "for grins".
> In other scenarios I might just keep SIGSEGV'ing until
> unblocked/pending-delivered or it died for another reason.
That's usually called a lockup. I don't believe the
timer tick or scheduler will run on a SIGSEGV loop.
> What bothers me is that SIGSEGV was blocked, and yet still
> delivered, and I want to know why. Was the block flat-out ignored, or
> did something else clear the block and the pending signal was
> delivered?
Some signals shouldn't be blocked, but can be for symmetry
with other signals.
> I understand that "behavior is unspecified" but would not expect that
> be what the programmer has explicitly asked to *not* have happen.
Then the programmer should have installed a SIGSEGV
handler to define what s/he wanted to happen.
-- Robert
------------------------------
From: "gary zhu" <[EMAIL PROTECTED]>
Subject: enum elements NET_BH in interrupt.h
Date: Wed, 16 May 2001 17:52:52 -0700
I am upgrading one device driver from kernel 2.2 to 2.4, in interrupt.h file
enum element NET_BH is removed. Is there anybody can tell me what should I
do this?
------------------------------
From: "Shaun Troedson" <[EMAIL PROTECTED]>
Subject: net access to unix computers
Date: Thu, 17 May 2001 10:18:27 +0930
Does anyone know of UNIX computers that are available to be freely connected
to over the net? I have some software I would like to test under various
OS's and so I am looking for orgs that provide UNIX boxes with free
accounts.
thanks
------------------------------
Subject: Re: Odd behaivour with select and raw sockets
From: Greg Copeland <[EMAIL PROTECTED]>
Date: 16 May 2001 20:28:42 -0500
I've not used raw sockets too much so sorry if this isn't just tons of help.
Are you sure that you are using select correctly? Have you tried to use
/dev/poll to see if it makes any difference?
"Cameron Kerr" <[EMAIL PROTECTED]> writes:
> I receive frames of both types, which is good. The problem is that with
> the select version, I only receive frame that did not originate from the
> host that is running the program!
>
> Is this a know behaivour? How can I get around it.
--
Greg Copeland, Principal Consultant
Copeland Computer Consulting
==================================================
PGP/GPG Key at http://www.keyserver.net
DE5E 6F1D 0B51 6758 A5D7 7DFE D785 A386 BD11 4FCD
==================================================
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.programming.threads
Subject: Re: SIGSEGV is not blocking
Date: Wed, 16 May 2001 18:40:13 -0700
Linus Torvalds wrote:
> Now, you might say that killing is better. I might agree. We can vote on
> it, I don't personally particularly care one way or the other. But you
> only get those two choices: kill the dang thing outright, or just ignore
> the blocking. We just don't have any other good choices.
Well, you could spin forever, faulting on the instruction and then
retrying it because the signal was blocked. One could argue that this is
the most theoretically perfect thing to do, but it's hardly useful
behavior under any circumstances I can imagine.
DS
------------------------------
From: "BrentRBrian" <[EMAIL PROTECTED]>
Subject: Re: AIX coff binaries
Date: Wed, 16 May 2001 21:45:00 -0400
No, it's an IBM 'non-free' OS.
the iBCS is "included" into the 2.4 kernel .... I have it turned on,
still it fails to execute (says it can't).
I had iBCS as a separte package in 7.0, still didn't work.
I think AIX coffs were not "finished".
B
In article <zU2M6.124$[EMAIL PROTECTED]>, "Cameron Kerr"
<[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]>, "BrentRBrian"
> <[EMAIL PROTECTED]> wrote:
>
>> I have a friend running AIX 1.3 on x86. I noticed the AIX COFF
>> binaries mentioned in the kernel sources for 2.4, but after #define'ing
>> the AIX magic number in the header and rebuilding, still no luck.
>>
>> Anybody have any idea what would be involved in getting the AIX
>> binaries to execute under Linux ?
>>
>> B
>
> You probably want to have a look at something called IBCS. It lets you
> run various Unix binary formats under Linux.
>
> Slackware comes with it, although I've never used it.
>
> PS. AIX for x86, is that free by any chance?
>
------------------------------
Crossposted-To: comp.os.linux.development.apps,comp.programming.threads
Subject: Re: SIGSEGV is not blocking
From: [EMAIL PROTECTED] (Eric P. McCoy)
Date: 16 May 2001 21:42:24 -0400
"Michael J. Saletnik" <[EMAIL PROTECTED]> writes:
[blocking SIGSEGV]
> > You say it ought to "work". What do you mean? What behavior would
> > constitute working? You have left no reasonable thing for the
> > implementation to do.
> If I explicitly block the SIGSEGV from being delivered, I would not
> expect the process still to terminate on a SIGSEGV.
So you've described what you do _not_ expect. Why don't you say what
you _do_ expect? And, more practically, how you expect the CPU and
kernel to recover from the host of exceptions (on an IA32) which are
all streamrollered into a SIGSEGV?
Technically, I believe all exceptions are recoverable (as far as the
IA32 CPU is concerned), but I think it would require extensive kernel
help.
> For example, in the example code shown it *is* perfectly acceptable to
> continue down the codeline since we don't do anything with the null
> value that we've tried to dereference and faulted on.
So Linux should notify you of what type of exception caused the
SIGSEGV. I hope you realize how thoroughly that will break
portability.
[...]
> What bothers me is that SIGSEGV was blocked, and yet still
> delivered, and I want to know why. Was the block flat-out ignored, or
> did something else clear the block and the pending signal was
> delivered?
I don't have the kernel knowledge to answer that, but if I were doing
it, it would be flat-out silently ignored to prevent horrible things
from happening. (Ignored to prevent the horrible things; silently to
meet up with POSIX which specifies it can be done but the results are
undefined.)
> I understand that "behavior is unspecified" but would not expect that
> be what the programmer has explicitly asked to *not* have happen.
"Unspecified" means just that. Linux may do it one way, SunOS
another, BSD still another. There's no specific way of responding,
and Linux uses the way that makes the most sense.
--
Eric McCoy <[EMAIL PROTECTED]>
"Knowing that a lot of people across the world with Geocities sites
absolutely despise me is about the only thing that can add a positive
spin to this situation." - Something Awful, 1/11/2001
------------------------------
Subject: Re: passing messages to a forked thread
From: Greg Copeland <[EMAIL PROTECTED]>
Date: 16 May 2001 20:47:21 -0500
"Darren LS" <[EMAIL PROTECTED]> writes:
> <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > On Tue, 15 May 2001 23:35:32 +0100 Darren LS <[EMAIL PROTECTED]> wrote:
> >
> > | Hello all. I have a nice little socket programmed than runs
> transparently
> > | due to the fork command thanks to the advice of many wonderful people on
> > | these newsgroups. However now I need to do some manipulation to the
> > | currently running process. I appreciate any advice on the following
> > |
> > | 1. this thread must be able to detect if it is the only instance running
> and
> > | if not then it needs to be able to get the process handle of other
> instances
> > | so it can communicate with them
> >
> > Only instance of what? Of a particular executed program file? Of being
> > forked from the same parent?
>
> hmm good question. The former is what i am really looking for but the latter
> would be handy too
>
If you are wanting to find out if other process instances are running, an easy
way to do this is to have it create/open a file with exclusive access. Close it
when you terminate. If you die, the OS will close it for you. If another
instance runs with the file locked, you'll know that another instance is already
running. There are several other schemes like this that you can use. Once
such example is a named semaphore. See the SYS V IPC documentation on this.
Simply save the semaphore key into a file. If the semaphore is locked, then
you know that something is still running. If it's not, then you know that
it has been released and you are safe to run. As I said, there are lots of
schemes you can use here.
See ipc, semget, etc., and pipe for more info on the above.
> >
> >
> > | 2. Active instances must be able to take signals of other threads,
> processes
> > | or even programs
> >
> > Depending on what you are expecting, this may or may not be possible.
>
> I'm looking for something a bit like a message pipe
SYS V IPC can do this (message queues). You can also use pipes or even UNIX
sockets. As in the first part of the message, here, you have lots of mechanisms
that you can use.
See ipc and msgget, etc.
>
> >
> >
> > | 3. must be able to send signals to other processes both local and remote
> >
> > What do you mean by remote? On a different computer?
>
> yes
So you are wanting to develop a message passing scheme? CORBA? RPC? SOAP?
Something simpler? I don't think there is enough information to directly
answer your question.
Long story short, you need to make sure you have a reliable means to convey
this signal via a network path. It sure would stink to have someone send
bogus signals which cause all of your applications to shutdown because you
couldn't validate the source or intent. This could even be as simple as
sending a GPG encrypted message which the recipient decrypts and verifies
the signature. The message could be the signal to use. This is just one
example, but I hope you can see the importance of verifying who a message
is coming from if signals are directly acted upon from network events.
>
> >
> >
> > | 4. must be able to ignore SIGTERM and should SIGKILL be thrown at it
> then it
> > | needs to survive long enough to fill in a log entry before it goes down.
> I
> > | appreciate any ideas.
> >
> > SIGKILL is defined as not being interceptable. The only way to detect
> such
> > a signal is to have a parent waiting for it and have that parent enter the
> > log entry (if it is also not killed).
>
If process monitoring is what you are trying to do, the previous poster is
absolutely correct. You need to have a parent process start your child which
then waits for it to exist, logging that it did, which means you can also
monitor why it terminated as well.
> yes i inderstand you cannot stop the kill so what you said sounds good to me
> >
> > It is possible for an errant process to go into a loop when it's handling
> a
> > signal. How would you kill such a process if you didn't have a SIGKILL
> that
> > was not interceptable?
>
> oh i understand completely. I do not want to intercept it just log a
> shutdown
>
See the above.
--
Greg Copeland, Principal Consultant
Copeland Computer Consulting
==================================================
PGP/GPG Key at http://www.keyserver.net
DE5E 6F1D 0B51 6758 A5D7 7DFE D785 A386 BD11 4FCD
==================================================
------------------------------
From: [EMAIL PROTECTED] (Jim Cochrane)
Subject: Re: net access to unix computers
Date: 16 May 2001 19:53:04 -0600
One of the first places to look is probably your ISP (as long as your tests
don't hog system resources too much.)
In article <[EMAIL PROTECTED]>,
Shaun Troedson <[EMAIL PROTECTED]> wrote:
>Does anyone know of UNIX computers that are available to be freely connected
>to over the net? I have some software I would like to test under various
>OS's and so I am looking for orgs that provide UNIX boxes with free
>accounts.
>
>thanks
>
>
--
Jim Cochrane
[EMAIL PROTECTED]
------------------------------
Subject: Re: Linux 2.4 network performances (compared to 2.2)
From: Greg Copeland <[EMAIL PROTECTED]>
Date: 16 May 2001 20:53:31 -0500
Last I heard, ECN must be explicately enabled. It is disabled by default
because it can cause problems with some older routers and firewalls not
allowing connections or incorrectly masking the bits.
I do think that /proc/sys/net/core/message_burst may be worth looking into
because I do remember some form of "traffic control" was added by default.
Try playing with that and see if it makes any difference. I honestly
don't know if that is the magic entry to play with though.
Greg
[EMAIL PROTECTED] (sl3uth) writes:
> 2.4 has an option to enable TCP Explicit Congestion Notification support.
> Not sure if this would affect your test, but I would suggest turning it off
> if it is on...then run your test.
>
> HTH
> Sam
>
> Jerome Tollet <[EMAIL PROTECTED]> wrote in
> news:[EMAIL PROTECTED]:
> > I don't knwo what means the new /proc/sys/net/core/*cong* but those
> > parameters are the standards one fixed by the kernel!
> >
> > I think that linux 2.4.2 limits the number of packets sent per second
> > over the network.
>
--
Greg Copeland, Principal Consultant
Copeland Computer Consulting
==================================================
PGP/GPG Key at http://www.keyserver.net
DE5E 6F1D 0B51 6758 A5D7 7DFE D785 A386 BD11 4FCD
==================================================
------------------------------
Crossposted-To: comp.os.linux.hardware
Subject: Re: Will Linux recognize >4GB RAM on Pentium-III Xeon?
From: Greg Copeland <[EMAIL PROTECTED]>
Date: 16 May 2001 20:58:35 -0500
I'm not surprised at all. I've worked with lots of Alpha systems used
as a database box. Bluntly put, they stink at this. On the other hand,
what little we got to do as far as raw CPU processing went, they screamed.
I guess what I'm trying to say is, keep the Alpha for scientific computing
(floating point especially) and use Spark or PA/RISK? for your big
databases.
Greg
"Steve Wolfe" <[EMAIL PROTECTED]> writes:
> > you seem willing to part with large coin since you are considering the
> > intel wallet vaccuum -- maybe equipment from, e.g., sun would be
> > competitive in price/performance?
>
> Our $12,000 quad Xeon handily beats a $25,000 Alpha machine at database
> work. The Compaq rep that loaned us the Alpha for a week was pretty sad
> to hear that. : )
>
> steve
>
>
>
--
Greg Copeland, Principal Consultant
Copeland Computer Consulting
==================================================
PGP/GPG Key at http://www.keyserver.net
DE5E 6F1D 0B51 6758 A5D7 7DFE D785 A386 BD11 4FCD
==================================================
------------------------------
From: "songjg" <[EMAIL PROTECTED]>
Subject: [Q]What is frame buffer??
Date: Thu, 17 May 2001 11:05:38 +0900
I want to show Bitmap and Dialog Box on screen Without X.
Somebody recommend me to use frame buffer.
As I am a beginner with linux, I don't know what frame buffer is, and How to
use it.
Anyone who knows the answer help me... please..
Thanks.
------------------------------
Subject: Re: creating files under /proc?
From: Greg Copeland <[EMAIL PROTECTED]>
Date: 16 May 2001 21:08:28 -0500
/proc is a special filesystem. It is not handled like other file systems.
Normally the kernel (or by extension, kernel modules) will create these
entries which then allow for reading and writing of entries within the
proc fs. While I certainly could be wrong (I'm sure someone will correct
me if I am), the only way to create these is via a kernel module and/or
kernel modification.
Remember, /proc is normally used to only reflect state and statistics of
the kernel and its drivers. So, if you keep that in mind, I'm hard pressed
to envision why you even want to create an entry that doesn't reflect the
kernel or its drivers.
What is it that you are trying to do?
Greg
Timur Tabi <[EMAIL PROTECTED]> writes:
> I have a driver which creates a directory and a couple files under
> /proc, namely /proc/zfc/. Is it possible to create new files in
> /proc/zfc/ using the ln, cat, or cp commands? I can't seem to find any
> examples of doing that, so I'm not sure whether it can be done (or where
> to look to find out).
--
Greg Copeland, Principal Consultant
Copeland Computer Consulting
==================================================
PGP/GPG Key at http://www.keyserver.net
DE5E 6F1D 0B51 6758 A5D7 7DFE D785 A386 BD11 4FCD
==================================================
------------------------------
Date: Wed, 16 May 2001 21:14:02 -0500
From: Robert Redelmeier <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.programming.threads
Subject: Re: SIGSEGV is not blocking
David Schwartz wrote:
>
> Linus Torvalds wrote:
>
> > Now, you might say that killing is better. I might agree. We can vote on
> > it, I don't personally particularly care one way or the other. But you
> > only get those two choices: kill the dang thing outright, or just ignore
> > the blocking. We just don't have any other good choices.
>
> Well, you could spin forever, faulting on the instruction and then
> retrying it because the signal was blocked. One could argue that this is
> the most theoretically perfect thing to do, but it's hardly useful
> behavior under any circumstances I can imagine.
It could be worse than that. The continuously generated interrupt
could prevent the scheduler from ever running, and the machine would
be effectively locked-up.
-- Robert
------------------------------
From: [EMAIL PROTECTED] ()
Crossposted-To: comp.os.linux.development.apps,comp.programming.threads
Subject: Re: SIGSEGV is not blocking
Date: Thu, 17 May 2001 02:30:16 -0000
In article <[EMAIL PROTECTED]>, Robert Redelmeier <[EMAIL PROTECTED]> wrote:
>It could be worse than that. The continuously generated interrupt
>could prevent the scheduler from ever running, and the machine would
>be effectively locked-up.
But it's a trap not an interrupt. The timer interrupt should still
get serviced.
--
http://www.spinics.net/linux
------------------------------
From: <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.setup
Subject: Re: Raid A0 patch with Kernel 2.2.17 and ReiserFS
Date: Wed, 16 May 2001 19:39:40 -0700
I'll add another question to the thread. 2 of the developers I work with say
that reiserFS should be used for development because it is more robust then
ext2 and in the embedded system we are developed, the power frequently is
removed from the target system running Linux. As a consequence of the fact
that power can be removed at any time, there is no graceful shutdown of this
system. I am told by one of the developers that reiserFS will be the new
default file system in the next release of Linux. I wonder what some of the
developers here have to say about reiserFS and its reliability in a
situation where power can and will be removed frequently from an embedded
system.
"Cristov" <[EMAIL PROTECTED]> wrote in message
news:9duai2$[EMAIL PROTECTED]...
> Does the Raid A0 patch for the 2.2.17 kernel fix whether or not ReiserFS
> will work with Raid5?
>
> Chris
>
>
>
------------------------------
From: Chris Cox <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.setup
Subject: Re: Raid A0 patch with Kernel 2.2.17 and ReiserFS
Date: Thu, 17 May 2001 03:03:08 GMT
Are you seriously asking a question here?.... or is this some kind
of joke.
You may want to have your "developers" rethink their design.
Have they done any embedded work before?
I'm not an expert by any means... but....
[EMAIL PROTECTED] wrote:
>
> I'll add another question to the thread. 2 of the developers I work with say
> that reiserFS should be used for development because it is more robust then
> ext2 and in the embedded system we are developed, the power frequently is
> removed from the target system running Linux. As a consequence of the fact
> that power can be removed at any time, there is no graceful shutdown of this
> system. I am told by one of the developers that reiserFS will be the new
> default file system in the next release of Linux. I wonder what some of the
> developers here have to say about reiserFS and its reliability in a
> situation where power can and will be removed frequently from an embedded
> system.
>
> "Cristov" <[EMAIL PROTECTED]> wrote in message
> news:9duai2$[EMAIL PROTECTED]...
> > Does the Raid A0 patch for the 2.2.17 kernel fix whether or not ReiserFS
> > will work with Raid5?
> >
> > Chris
> >
> >
> >
------------------------------
** 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 by posting to the
comp.os.linux.development.system newsgroup.
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
******************************
