Linux-Development-Sys Digest #730, Volume #8 Thu, 17 May 01 17:13:14 EDT
Contents:
Kernel Errors - ideas? ("Henry Thompson")
Re: Why O_SYNC and fsync are slow on Linux? ("Heikki Tuuri")
Re: Execve and execvp (Alessandro "oVeRRiDe")
looking for external modem driver ("gary zhu")
Re: Java vs memory ("Karl Pihlblad")
Re: interrupts too frequent?
Re: passing messages to a forked thread ("Darren LS")
Re: transpareny ("Darren LS")
Compiling Drivers ("Fred Marshall")
Re: SIGSEGV is not blocking ("Michael J. Saletnik")
Re: Compiling Drivers
Re: SIGSEGV is not blocking
Re: passing messages to a forked thread (Dragan Cvetkovic)
----------------------------------------------------------------------------
From: "Henry Thompson" <hthompson@no(spire-inc)spam.com>
Subject: Kernel Errors - ideas?
Date: Thu, 17 May 2001 11:50:44 -0400
Hello All,
I am posting this here as I am not sure the best place to post it. If there
is a better forum please let me know.
I have been getting these dumps in my logs just in the couple of days. They
come in droves. I have a one day 12M /var/log/messages file to prove it.
When normally they are about 50K I have bounced the box three or four time
to see if that would clear it up and it has not. When I flush the firewall
chains and rmod ipchains it seems to go away. It is a Nat Firewall so I
must have ipchains active.
I am using kernel 2.4.1-0.1.9 (it is a Redhat kernel, please no thrashing)
Can any one tell me how I can go about finding what it means.
May 16 18:11:53 fw1 kernel: Flags; bus-master 1, full 0; dirty 1082874(10)
current 1082874(10).
May 16 18:11:53 fw1 kernel: Transmit list 00000000 vs. cf37a2a0.
May 16 18:11:53 fw1 kernel: 0: @cf37a200 length 8000002a status 0001002a
May 16 18:11:53 fw1 kernel: 1: @cf37a210 length 8000002a status 0001002a
May 16 18:11:53 fw1 kernel: 2: @cf37a220 length 8000003a status 0001003a
May 16 18:11:53 fw1 kernel: 3: @cf37a230 length 800005ea status 000105ea
May 16 18:11:53 fw1 kernel: 4: @cf37a240 length 8000058d status 0001058d
May 16 18:11:53 fw1 kernel: 5: @cf37a250 length 80000036 status 00010036
May 16 18:11:53 fw1 kernel: 6: @cf37a260 length 80000036 status 00010036
May 16 18:11:53 fw1 kernel: 7: @cf37a270 length 800005ea status 000105ea
May 16 18:11:53 fw1 kernel: 8: @cf37a280 length 800005ea status 000105ea
May 16 18:11:53 fw1 kernel: 9: @cf37a290 length 800005ea status 800105ea
May 16 18:11:53 fw1 kernel: 10: @cf37a2a0 length 800005ea status 000105ea
May 16 18:11:53 fw1 kernel: 11: @cf37a2b0 length 800005ea status 000105ea
May 16 18:11:53 fw1 kernel: 12: @cf37a2c0 length 800005ea status 000105ea
May 16 18:11:53 fw1 kernel: 13: @cf37a2d0 length 800005ea status 000105ea
May 16 18:11:53 fw1 kernel: 14: @cf37a2e0 length 800005ea status 000105ea
May 16 18:11:53 fw1 kernel: 15: @cf37a2f0 length 80000040 status 00010040
------------------------------
From: "Heikki Tuuri" <[EMAIL PROTECTED]>
Subject: Re: Why O_SYNC and fsync are slow on Linux?
Date: Thu, 17 May 2001 15:58:49 GMT
Greg,
Greg Copeland wrote in message ...
>"Heikki Tuuri" <[EMAIL PROTECTED]> writes:
>
>> Hi!
>>
>> On different systems I have measured strange differences in performance
>> depending
>> on whether I open a file with O_SYNC and let the operating system do the
>> flushing
>> of the file to disk after each write, or if I open without O_SYNC, and
call
>> fsync myself.
>
>> On Windows NT I have not noticed such performance problems if I use
>> non-buffered
>> i/o to a file.
>
>You can't really compare OS's because they can be implemented completely
>different, especially if different hardware is in the mix. One thing that
>is for sure, in almost all cases (that is, as a rule of thumb), you should
>always see a negative performance impact when using non-buffered I/O. The
Using non-buffered i/o might be faster for a database because the
database already orders the writes in a sensible way. When I dug into
mailing list
archives I noticed that there was discussion some time ago about
implementing non-buffered i/o
also in Linux.
>reasons for this are obvious. If you are not seeing some type of delta, it
>implies that you are not performing a metric with enough accuracy to
measure
>a delta for your OS/hardware combination. It's important to remember that
>some drives may have 2M+ worth of cache, which *may* be used as a
write-back
>cache. If that's the case, if you are writing less than 2M at a time and
>allowing for the cache to be written prior to attempting a second write,
>your write operations will seem very fast. In these cases, even though the
>intention is to make every write a physical write, it's very possible that
>they are actually virtual writes, even at the hardware level. If you are
>on higher end hardware, you may be looking at large caches on both the
>drives and/or the disk controllers, which may have 32M to 2G worth of
cache.
>Let's not forget solid state drives too...but I'm guessing that this is not
>that case here.
These should be rather inexpensive disks. I am writing 100 MB to 1 GB, so
the disk cache
cannot help too much in write speed.
>>
>> I have written a database engine InnoDB under MySQL and bumped into these
>> problems
>> on Linux.
>
>I think I missed something. I know that you said that you are seeing
performance
>differences on different platforms, but I guess I don't understand the
"problems"
>that you are see. What again is the "problem."
The problem is how to choose between O_(D)SYNC and f(data)sync for the
database files?
At least on one system O_SYNC was much faster for small writes while on
another system
fsync was much faster for big writes.
It would also be nice to know waht is the algorithm Linux uses in O_SYNC and
fsync. It seems that O_SYNC only sends some 8 kB of data at a time to the
disk, and waits for the
disk to reply "write completed". It could send much more data because the 1
MB chunk is
probably mostly contiguous on the disk.
Regards,
Heikki
http://www.innobase.fi
>--
>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: Alessandro "oVeRRiDe" <[EMAIL PROTECTED]>
Subject: Re: Execve and execvp
Date: Thu, 17 May 2001 18:02:05 GMT
Hi! So I did that your way. But i have a problem: concat function. Well, i
supposed to use strcat function, but it gave me many problems, since
z=strcat(x, y), puts the content in x and then in z, so the for cycle you
suggested me does not work at all, since strcat modifyes pe. In fact,
having a "ls" input, the output is:
lsls
ls
lsls
ls
lsls
....
Any idea on how to solve this? Thanks.
------------------------------
From: "gary zhu" <[EMAIL PROTECTED]>
Subject: looking for external modem driver
Date: Thu, 17 May 2001 11:51:17 -0700
Is there anybody can tell me where can I get a external modem driver source
code, especially in kernel 2.4? Any help is very appreciated!
Gary
------------------------------
From: "Karl Pihlblad" <[EMAIL PROTECTED]>
Subject: Re: Java vs memory
Date: Thu, 17 May 2001 20:56:58 +0200
"Kasper Dupont" <[EMAIL PROTECTED]> wrote:
> It works with everything that is memory mapped using the mmap() system
> call. So wether it works with java code depends on the java virtual
> machine you are using.
As far as I can tell neither Sun's or IBM's JVM mmaps .jar or .class
files. (Exception is IBM's JVM on AIX, which, I think, mmaps all files.)
-Karl Pihlblad
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: interrupts too frequent?
Date: Thu, 17 May 2001 19:12:56 -0000
In article <[EMAIL PROTECTED]>,
Barry Smyth <[EMAIL PROTECTED]> wrote:
>Could this be because the operating system is doing something in the
>background which lasts a few milliseconds leading to missing my
>interrupts?
How long do you take to process each interrupt?
--
http://www.spinics.net/linux
------------------------------
From: "Darren LS" <[EMAIL PROTECTED]>
Subject: Re: passing messages to a forked thread
Date: Thu, 17 May 2001 20:37:23 +0100
Greg Copeland <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> "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.
hmm. sounds good but i may not own all the processes
> > >
> > >
> > > | 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.
yes i am familier with sockets. but i would have to know the ports and
hanshaking of the other processes and this info is not always available.
still the message pipes sounds the wayy to go
>
> See ipc and msgget, etc.
will do
> >
> > >
> > >
> > > | 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.
RPC? thats Microsoft isn't it. no i am just looking for some common message
piping system that runs on linux and can be uses remotely as well as locally
i mean lets face it, thats what unix is about:-)
>
> 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.
I agree but first things first :-)
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.
I have my own encyption algorythms sorted, i could use them
>
> >
> > >
> > >
> > > | 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.
I am with you with the logging it exist bit but how would the parent know
if the child terminates?
>
> > 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.
just did
:-)
------------------------------
From: "Darren LS" <[EMAIL PROTECTED]>
Crossposted-To:
alt.linux,comp.os.linux.development.apps,linux.redhat.devel,linux.redhat.development
Subject: Re: transpareny
Date: Thu, 17 May 2001 20:39:30 +0100
Kasper Dupont <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Darren LS wrote:
> >
> [...]
> >
> > Hi Kasper, thanks but what I would like to do is dump the output to a
vacant
> > tty terminal for debugging purposes
> >
> > Darren
>
> In that case the easiest probably is just to
> start it with the open command from the
> command line. "man 1 open"
>
> Notice that in some distributions open is not
> installed by default. It is really a handy
> tool, so just install it from your CD if it
> is not already installed.
>
> You could also use /dev/ttyXX instead of
> /dev/null in the code from my last post, the
> problem is to find the appropriate value for
> XX. There is an ioctl to get that number, I
> can post some code if you need it.
please do tried some piping to ttyS8 but the system told me not to be stupid
> --
> Kasper Dupont
------------------------------
From: "Fred Marshall" <[EMAIL PROTECTED]>
Subject: Compiling Drivers
Date: Thu, 17 May 2001 13:04:37 -0700
Rarely, I've had to compile drivers to install as modules. I'm working with
the natsemi.c driver from Scyld for the netgear FA311 in 2.2.14-5 Turbolinux
distribution install.
Because I rarely do this, I have a couple of questions for which I can't
find ready answers in books or howtos:
1) how can I capture all the messages that come out of gcc when running in
command line mode? I'm missing the first messages that scroll off the
string. The computer is too fast to do ctrl-s effectively. At any rate,
until I learn how to do this, I can't forward the error messages for anyone
to see.
2) there are lots of messages so I anticipate there are path problems.
Likely causes / fixes for this specific situation would be appreciated. The
source is in /usr/src/modules/scyld. I have *no* idea what's expected and
haven't yet analyzed the code for all the paths that are hard coded into it.
I suspect the assumptions regarding directories were different.
Suggested places to go read?
Thanks,
Fred Marshall
Mission Systems, Inc.
201 Ada Avenue
Suite 13
Mountain View, CA 94043
Tel: (650) 967-1803
Fax: (650) 969-3850
Cell: (408) 489-8190
http://mission-systems-inc.com
[EMAIL PROTECTED]
------------------------------
Crossposted-To: comp.os.linux.development.apps,comp.programming.threads
Subject: Re: SIGSEGV is not blocking
From: "Michael J. Saletnik" <[EMAIL PROTECTED]>
Date: Thu, 17 May 2001 20:37:34 GMT
[EMAIL PROTECTED] (Linus Torvalds) writes:
> Well, the kernel has no alternative. It has to do something. You told it
> not to send the SEGV, so _what_ do you expect it to do?
My expectations all along have been tailored specifically to the
interpretation of POSIX and the documentation provided in the Linux
man pages, relative to the original poster's question of "it does
something different under AIX". These talk about behavior being
undefined after ignoring a SIGSEGV not generated by kill() or raise().
I have been taking "ignoring" to literally mean an ignoring
disposition, as opposed to an attempt to block, and saying that given
the information I have in front of me, in spite of the fact it doesn't
make sense, I didn't see why the original poster can't do it. It was
more of a semantic argument than one of technical feasibility.
That's why I made such statements as:
> >What bothers me is that SIGSEGV was blocked, and yet still
> >delivered, and I want to know why.
And this is a perfectly satisfactory explanation:
> deliver it despite the programmer telling it not to
Also note my question:
> Was the block flat-out ignored, or did something else clear the
> block and the pending signal was delivered?
which was meant to question if it was the kernel delivering the signal
anyway, or the kernel or some other layer clearing the block and
refaulting.
The answers to these were not mentioned *anywhere* that I can find
(heck, the man page for signal(7) on my RH6.2 2.2.19 system reads
"Linux 1.3.88 April 14, 1996") and that was my issue.
> The CPU does not
> advance the instruction pointer past the instruction that faulted,
Of course! [slaps self in head] The scary thing is that I knew this,
because otherwise such things as page faults wouldn't work. I got so
wrapped up in "but it doesn't *say* that anywhere" that I totally
blitzed on this fact. I don't know why I presumed the process could
continue in the presence of a cpu-raised segfault; I think I was
considering a point about blocking in the presence of raise(SIGSEGV);
and got sidetracked.
--
{michael}
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: Compiling Drivers
Date: Thu, 17 May 2001 20:41:55 -0000
In article <9e1avm$1d7$[EMAIL PROTECTED]>,
Fred Marshall <[EMAIL PROTECTED]> wrote:
>1) how can I capture all the messages that come out of gcc when running in
>command line mode? I'm missing the first messages that scroll off the
>string. The computer is too fast to do ctrl-s effectively. At any rate,
>until I learn how to do this, I can't forward the error messages for anyone
>to see.
add "2>/tmp/capure" to the command line
--
http://www.spinics.net/linux
------------------------------
From: [EMAIL PROTECTED] ()
Crossposted-To: comp.os.linux.development.apps,comp.programming.threads
Subject: Re: SIGSEGV is not blocking
Date: Thu, 17 May 2001 20:52:19 -0000
In article <[EMAIL PROTECTED]>,
Michael J. Saletnik <[EMAIL PROTECTED]> wrote:
>I have been taking "ignoring" to literally mean an ignoring
>disposition, as opposed to an attempt to block, and saying that given
>the information I have in front of me, in spite of the fact it doesn't
>make sense, I didn't see why the original poster can't do it.
It doesn't make sense because there's nothing that can be done. Do you
understand that problem can't just continue and there's nothing to
unblock the signal if the problem isn't running?
--
http://www.spinics.net/linux
------------------------------
Subject: Re: passing messages to a forked thread
From: Dragan Cvetkovic <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Date: 17 May 2001 16:58:53 -0400
"Darren LS" <[EMAIL PROTECTED]> writes:
>
> RPC? thats Microsoft isn't it.
No, it's not. Check rpc(3N) man page on Linux or any other UNIX system. For
example, NFS is based on RPC (if I am not terribly wrong).
Bye, Dragan
--
Dragan Cvetkovic,
To be or not to be is true. G. Boole
------------------------------
** 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
******************************
