Linux-Development-Sys Digest #731, Volume #8 Fri, 18 May 01 06:13:14 EDT
Contents:
Re: SIGSEGV is not blocking (Eric P. McCoy)
Re: SIGSEGV is not blocking (David Schwartz)
Re: SIGSEGV is not blocking (Steve Kirkendall)
Trouble using large amount of memory with Redhat 7 ("J. P. Montgomery")
Re: interrupts too frequent? (Robert Redelmeier)
Re: SIGSEGV is not blocking (Robert Redelmeier)
Re: SIGSEGV is not blocking
Re: make dep clean zImage (Juergen Pfann)
Re: Free OS ? (Joe Pfeiffer)
Re: Compiling Drivers (Villy Kruse)
Re: interrupts too frequent? ("Barry Smyth")
Re: interrupts too frequent? ("Barry Smyth")
Re: Java vs memory (Kasper Dupont)
Re: SIGSEGV is not blocking (Kasper Dupont)
Re: Trouble using large amount of memory with Redhat 7 (Kasper Dupont)
electric fence (Franck Marchand)
Re: electric fence (Kasper Dupont)
[kernel] calling user code from module (Vyacheslav Burdjanadze)
Re: [kernel] packet filtering/modifying (Vyacheslav Burdjanadze)
Re: Help me write a driver (Vyacheslav Burdjanadze)
----------------------------------------------------------------------------
Crossposted-To: comp.os.linux.development.apps,comp.programming.threads
Subject: Re: SIGSEGV is not blocking
From: [EMAIL PROTECTED] (Eric P. McCoy)
Date: 17 May 2001 18:02:20 -0400
"Michael J. Saletnik" <[EMAIL PROTECTED]> 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'm not sure how you mean this, so I won't comment. (But will leave
it in if you want to clarify.)
[...]
> 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.
If that man page describes the POSIX-standard behavior, and Linux has
maintained POSIX compatability in this regard since then, there's no
reason to update it.
> > 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.
Don't feel too bad. Traps, which are also exceptions, do advance EIP
on IA32 CPUs. But there are only 2.5 traps which the CPU can raise.
--
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
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.programming.threads
Subject: Re: SIGSEGV is not blocking
Date: Thu, 17 May 2001 15:43:54 -0700
"Michael J. Saletnik" wrote:
> 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 kernel is the only code that could possibly have done it. The
kernel found itself handling a page fault that was a segmentation
violation and found nothing sane it could do, so it killed the process.
> 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.
Right. Only the kernel can determine that the page fault is a fatal
one. And all it can do is continue the process where it left off or
change it to go somewhere else.
DS
------------------------------
From: Steve Kirkendall <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Crossposted-To: comp.os.linux.development.apps,comp.programming.threads
Subject: Re: SIGSEGV is not blocking
Date: Thu, 17 May 2001 16:50:44 -0700
"Michael J. Saletnik" wrote:
>
> David Schwartz <[EMAIL PROTECTED]> writes:
>
> > 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.
As I understand it, "blocking" only means you can't get one SIGSEGV
while executing the handler function for an earlier SIGSEGV. Outside
of the handler function, the signal can still arrive.
Try a plain old "signal(SIGSEGV, SIG_IGN)" call instead. You'll still
have the issue of undefined behavior after ignoring a segmentation
violation, but at least it'll still be doing... something.
------------------------------
From: "J. P. Montgomery" <[EMAIL PROTECTED]>
Subject: Trouble using large amount of memory with Redhat 7
Date: Thu, 17 May 2001 22:23:34 -0500
I have a K7 AMD 1.2 G machine with 1.5 G of ram using an ASUS motherboard
and am running Redhat 7. I use a Portland Fortran compiler (and sometimes
g77 and gcc). I have found that when I write a simple program I can only
dimension a complex array by about 72000000 before the job will core dump (a
job size of about 549M as verified by computation and running top). The
Portland people point to the OS and say that perhaps I can recompile the
kernel. Okay ... so I've checked the Redhat site and done searching on
newsgroups, etc. The hint I have found is that my stack size is 8M in the
kernel. I can certainly recompile ... but I am trying to figure if this
will solve the problem. I have noted that g77 has a different limit
(somewhat lower ... the Portland guy said however, that they have no such
limitation in the compiler). Also a coworker uses a Lahey compiler on a
Win98 machine with 512M of memory. He can dimension the array mentioned
above by 110000000 or about 840M.
Can anyone point me in the right direction and explain what is happening. I
have written a small c code which pulls all of the resource limits and most
are set at unlimited but the stack and pipe. Top and other means of
examining the memory indicate that all of the memory is recognized by the
system ... so I am inclined to agree with the Portland guy.
Thanks for the help,
J Montgomery
------------------------------
Date: Thu, 17 May 2001 21:49:48 -0500
From: Robert Redelmeier <[EMAIL PROTECTED]>
Subject: Re: interrupts too frequent?
Barry Smyth wrote:
>
> I am writing a driver for a PCI card which generate interrupts at
> intervals of about 1 millisecond. The interrupt has been requested with
> the SA_INTERRUPT flag. The interrupts occur in batches of 256. However
> on some occasions when running, some interrupts are skipped leading to
> lost data.
>
> Could this be because the operating system is doing something in the
> background which lasts a few milliseconds leading to missing my
> interrupts? If so is there any way to give my interrupts a high priority
> to ensure that they are all acted upon? Is there a stated limit on the
> frequency of interrupts in linux?
Your int frequency is not particularly high, but you want a quarter
second
for your full string! I presume 1 ms is ample time for your ISR,
but it's easy to eat up 100,000+ cycles if you're doing alot of IN/OUT.
On your system, the first thing you should do is make sure DMA is
enabled for all hard-disks. Use `hdparm` or the 2.4 kernel config.
This will reduce kernel overhead for `sync`s. You might also
considering adding RAM and disabling swap because swapping is
a high-priority long-running task.
-- Robert
------------------------------
Date: Thu, 17 May 2001 21:54:41 -0500
From: Robert Redelmeier <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.programming.threads
Subject: Re: SIGSEGV is not blocking
[EMAIL PROTECTED] wrote:
>
> 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.
On i386 a trap _is_ an interrupt. The only difference is
the pushed IP corresponds to the faulting instruction, not
the next instruction. This greatly facilitates re-start.
When an int is executed, hardware disables all other ints.
The ISR (OS) may re-enable interrupts (or not). Usually
it will, but for some critical code, it cannot.
-- Robert
------------------------------
From: [EMAIL PROTECTED] ()
Crossposted-To: comp.os.linux.development.apps,comp.programming.threads
Subject: Re: SIGSEGV is not blocking
Date: Fri, 18 May 2001 03:28:52 -0000
In article <[EMAIL PROTECTED]>, Robert Redelmeier <[EMAIL PROTECTED]> wrote:
>> But it's a trap not an interrupt. The timer interrupt should still
>> get serviced.
>On i386 a trap _is_ an interrupt.
No, it isn't. A trap is caused by an instruction execution that fails
in some way. In other words a traps is a synchronous event while an
interrupt is a response to an external event. The difference is subtle
but it is a difference.
------------------------------
From: Juergen Pfann <[EMAIL PROTECTED]>
Subject: Re: make dep clean zImage
Date: Fri, 18 May 2001 09:06:06 +0200
"Peter T. Breuer" wrote:
>
> It would hardly matter! They don't affect each other. make dep makes
> the .dep (.hdep?) files, and make clean removes object files.
>
...as long as you don't issue "make mrproper" instead of "make clean".
With that, you'll lose not only the .depend and .hdepend files
(in addition to the compiled object files), but your .config also,
and may start a new cycle...
Better keep a copy of your .config under a different name.
Feel free to take a look at the makefile (called Makefile), to get
at least an idea what the different make targets do.
Juergen
------------------------------
From: Joe Pfeiffer <[EMAIL PROTECTED]>
Subject: Re: Free OS ?
Date: 17 May 2001 09:14:07 -0600
Kasper Dupont <[EMAIL PROTECTED]> writes:
> > > If you want to know the legal details read the GPL:
> > > <URL:http://www.gnu.org/copyleft/gpl.html#SEC1>
> >
> > I have -- I was respondibg to the poster's comment in which he said
> > he'd heard that for-sale distributions of Linux weren't what Linus had
> > in mind.
>
> I see my words wasn't clear enough.
>
> You mentioned the GNU GPL without any reference telling
> where to find it. I just thought that maybee STG actually
> wanted to read it as it answers most of his questions.
Ah -- I thought you were referring me to it, not referring him to it.
Sorry for the misunderstanding.
--
Joseph J. Pfeiffer, Jr., Ph.D. Phone -- (505) 646-1605
Department of Computer Science FAX -- (505) 646-1002
New Mexico State University http://www.cs.nmsu.edu/~pfeiffer
SWNMRSEF: http://www.nmsu.edu/~scifair
------------------------------
From: [EMAIL PROTECTED] (Villy Kruse)
Subject: Re: Compiling Drivers
Date: 18 May 2001 07:39:29 GMT
On Thu, 17 May 2001 13:04:37 -0700, Fred Marshall <[EMAIL PROTECTED]> wrote:
>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.
>
The "script" command is an extremly usefull function that was created for
this purpose.
Also shift+PageUp will pull down old screen contents on some systems, and
if you are using xterm you should have some scroll bars you can use to
pull down things that got scroled off the top.
Villy
------------------------------
From: "Barry Smyth" <[EMAIL PROTECTED]>
Subject: Re: interrupts too frequent?
Date: Fri, 18 May 2001 09:17:52 +0100
I'm not sure how long it takes to process each interrupt; but each involves
several 'readl' and 'writel' calls followed by a copy of 4096 bytes from a
DMA buffer to a vmalloc'd area whose pages have ben locked down.
<[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
> 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: "Barry Smyth" <[EMAIL PROTECTED]>
Subject: Re: interrupts too frequent?
Date: Fri, 18 May 2001 09:22:40 +0100
Is there a way to disable swapping programmatically, so that I can disable
before the first interrupt occurs and enable after the final interrupt?
Thanks.
Barry
"Robert Redelmeier" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Barry Smyth wrote:
> >
> > I am writing a driver for a PCI card which generate interrupts at
> > intervals of about 1 millisecond. The interrupt has been requested with
> > the SA_INTERRUPT flag. The interrupts occur in batches of 256. However
> > on some occasions when running, some interrupts are skipped leading to
> > lost data.
> >
> > Could this be because the operating system is doing something in the
> > background which lasts a few milliseconds leading to missing my
> > interrupts? If so is there any way to give my interrupts a high priority
> > to ensure that they are all acted upon? Is there a stated limit on the
> > frequency of interrupts in linux?
>
> Your int frequency is not particularly high, but you want a quarter
> second
> for your full string! I presume 1 ms is ample time for your ISR,
> but it's easy to eat up 100,000+ cycles if you're doing alot of IN/OUT.
>
> On your system, the first thing you should do is make sure DMA is
> enabled for all hard-disks. Use `hdparm` or the 2.4 kernel config.
> This will reduce kernel overhead for `sync`s. You might also
> considering adding RAM and disabling swap because swapping is
> a high-priority long-running task.
>
> -- Robert
------------------------------
From: Kasper Dupont <[EMAIL PROTECTED]>
Subject: Re: Java vs memory
Date: Fri, 18 May 2001 08:44:42 +0000
Karl Pihlblad wrote:
>
> "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
If the JVM is going to load the file translate it into
native code and remove the original file from memory
again mmaping wouldn't reduce memory usage anyway.
Anyway I believe that the loaded files is only a small
fraction of the JVM's memory usage, there must be much
more important differences between the different JVMs.
--
Kasper Dupont
------------------------------
From: Kasper Dupont <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.programming.threads
Subject: Re: SIGSEGV is not blocking
Date: Fri, 18 May 2001 09:00:50 +0000
Steve Kirkendall wrote:
>
> "Michael J. Saletnik" wrote:
> >
> > David Schwartz <[EMAIL PROTECTED]> writes:
> >
> > > 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.
>
> As I understand it, "blocking" only means you can't get one SIGSEGV
> while executing the handler function for an earlier SIGSEGV. Outside
> of the handler function, the signal can still arrive.
>
> Try a plain old "signal(SIGSEGV, SIG_IGN)" call instead. You'll still
> have the issue of undefined behavior after ignoring a segmentation
> violation, but at least it'll still be doing... something.
It is possible for a process to block signals it
want to handle at a later time. In this case the
kernel will hold back the signal until it is
unblocked and then immediately deliver the signal.
The blocking can happen when a signal is being
delivered to prevent the next signal to be
delivered before the first has finished, but it
can also be done explicitly using the sigprocmask
system call.
--
Kasper Dupont
------------------------------
From: Kasper Dupont <[EMAIL PROTECTED]>
Subject: Re: Trouble using large amount of memory with Redhat 7
Date: Fri, 18 May 2001 09:14:51 +0000
J. P. Montgomery wrote:
>
> I have a K7 AMD 1.2 G machine with 1.5 G of ram using an ASUS motherboard
> and am running Redhat 7. I use a Portland Fortran compiler (and sometimes
> g77 and gcc). I have found that when I write a simple program I can only
> dimension a complex array by about 72000000 before the job will core dump (a
> job size of about 549M as verified by computation and running top). The
> Portland people point to the OS and say that perhaps I can recompile the
> kernel. Okay ... so I've checked the Redhat site and done searching on
> newsgroups, etc. The hint I have found is that my stack size is 8M in the
> kernel. I can certainly recompile ... but I am trying to figure if this
> will solve the problem. I have noted that g77 has a different limit
> (somewhat lower ... the Portland guy said however, that they have no such
> limitation in the compiler). Also a coworker uses a Lahey compiler on a
> Win98 machine with 512M of memory. He can dimension the array mentioned
> above by 110000000 or about 840M.
>
> Can anyone point me in the right direction and explain what is happening. I
> have written a small c code which pulls all of the resource limits and most
> are set at unlimited but the stack and pipe. Top and other means of
> examining the memory indicate that all of the memory is recognized by the
> system ... so I am inclined to agree with the Portland guy.
>
> Thanks for the help,
> J Montgomery
You don't need to recompile the kernel to change the
stack size. You can check and change the resource
limits using a simple shell command.
In bash and similar shells you can use theese three
commands:
ulimit -a
ulimit -Ha
ulimit -s unlimited
that will respectively print soft limits, hard limits
and remove the stack limit.
In tcsh and similar shells the commands would look
like this:
limit
limit -h
limit s unlimited
After removing the stack limit try runing your program
from the same shell.
--
Kasper Dupont
------------------------------
From: Franck Marchand <[EMAIL PROTECTED]>
Subject: electric fence
Date: Fri, 18 May 2001 11:17:23 +0200
Reply-To: [EMAIL PROTECTED]
I have a pb with a prog compiled with electric fence ....
it returns me a segmentation fault with this line :
if(s->f_close)
... blah blah blah
s->f_close is a function pointer,
when I put MALLOC_CHECK_ environment variable to 1 it says
that s is an invalid pointer.
so If you have an idea about that I will very pleased that you
help me
thanks
frank
------------------------------
From: Kasper Dupont <[EMAIL PROTECTED]>
Subject: Re: electric fence
Date: Fri, 18 May 2001 09:30:00 +0000
Franck Marchand wrote:
>
> I have a pb with a prog compiled with electric fence ....
> it returns me a segmentation fault with this line :
>
> if(s->f_close)
> ... blah blah blah
>
> s->f_close is a function pointer,
>
> when I put MALLOC_CHECK_ environment variable to 1 it says
> that s is an invalid pointer.
>
> so If you have an idea about that I will very pleased that you
> help me
>
> thanks
> frank
Probably that is because s really is an invalid pointer.
It means that there is a bug in your program, but nobody
will be able to find the bug when you post only one line
of code.
I can think of four possible explanations:
1. You forgot to initialise s
2. You forgot to verify if s was a NULL pointer
3. You freed the memory before you finished using it.
4. You have been writing to the wrong memory somewhere
in the program.
When you use electric fence number 4 will in most cases
cause a segmentation fault immediately and not at some
strange point later in the program.
--
Kasper Dupont
------------------------------
Date: Fri, 18 May 2001 13:47:02 +0400
From: Vyacheslav Burdjanadze <[EMAIL PROTECTED]>
Subject: [kernel] calling user code from module
It is possible to call user code from kernel module?
I assume both parts written in C. I read Alan Cox post
about "no software format conversion in kernel part"
and want to move some crypto stuff from my kernel
module to user side. Is there way to just call user
code like usual C function? Or it is bad idea?
------------------------------
Date: Fri, 18 May 2001 13:48:00 +0400
From: Vyacheslav Burdjanadze <[EMAIL PROTECTED]>
Subject: Re: [kernel] packet filtering/modifying
> You might like to have a look at either the ipchains source code section
> of the linux kernel, or surf along to the netfilter website and have a
> look at the iptables source code or documentation.
Thanks.
> PS. When you're done, could you post what you did to the group please?
Yes. I planning to look into iptables code this weekend.
------------------------------
Date: Fri, 18 May 2001 13:51:31 +0400
From: Vyacheslav Burdjanadze <[EMAIL PROTECTED]>
Subject: Re: Help me write a driver
Curtis Russell Nielson wrote:
>
> I am trying to write a very simple Kernel Loadable device driver for a
> character device and I built. The card is a very simple 8255 PPI. I
> am not very familiar with any kind of kernel programming and would
> appreciate some instructions or example code I could look at. Thanks in
> Advance
You may have a look to my stuff. The code is split into few parts and
I think it easy to understand. It also deals with PCI/AGP.
http://yopt.chat.ru/nvctl.tar.bz2
------------------------------
** 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
******************************
