Linux-Development-Sys Digest #732, Volume #8 Fri, 18 May 01 12:13:14 EDT
Contents:
Re: Trouble using large amount of memory with Redhat 7 ("J. P. Montgomery")
Re: transpareny (Kasper Dupont)
Re: transpareny (Kasper Dupont)
Re: Execve and execvp (Josef Moellers)
Fwd: Like in windows snmp service, can i get the same in linux? ("v.nagasrinivas")
Re: interrupts too frequent? (Robert Redelmeier)
GNU_SOURCE ("Ivor Cox")
Re: SIGSEGV is not blocking (Robert Redelmeier)
isa mem in 0xA0000-0xFFFFFF, Paging fault? ("Jason M. LaPenta")
mmap() and msync() extensions? (At150bogomips)
Sharing the virtual address space? (At150bogomips)
Re: isa mem in 0xA0000-0xFFFFFF, Paging fault? (Josef Moellers)
Re: Sharing the virtual address space? (Josef Moellers)
Re: mmap() and msync() extensions? (Dragan Cvetkovic)
Re: Raid A0 patch with Kernel 2.2.17 and ReiserFS (Angry Bob)
Re: USB Development ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: "J. P. Montgomery" <[EMAIL PROTECTED]>
Subject: Re: Trouble using large amount of memory with Redhat 7
Date: Fri, 18 May 2001 06:36:15 -0500
I've already done this both in my normal user account and as root to no
avail ...
"Kasper Dupont" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> 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: Kasper Dupont <[EMAIL PROTECTED]>
Crossposted-To:
alt.linux,comp.os.linux.development.apps,linux.redhat.devel,linux.redhat.development
Subject: Re: transpareny
Date: Fri, 18 May 2001 12:38:50 +0000
This is a multi-part message in MIME format.
==============2FC9C8D778BAF5A952AC3365
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Darren LS wrote:
>
> 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
The attached example demonstrates a lot of theese
features. You can remove the parts you don't like.
All this program does could have been by using the
open command with some appropriate options.
--
Kasper Dupont
==============2FC9C8D778BAF5A952AC3365
Content-Type: text/plain; charset=us-ascii; name="newtty.c"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="newtty.c"
#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>
#include <fcntl.h>
#include <sys/ioctl.h>
#include <linux/vt.h>
int newttynumber()
{
/* Try in all posible ways to get the number of the first free tty */
char *ttynames[]={"/dev/console","/dev/tty","/dev/tty0","/dev/tty1"};
int i,number,fd;
for (i=0;i<3;++i)
if (!ioctl(0,VT_OPENQRY,&number))
return number;
for (i=0;i<sizeof(ttynames)/sizeof(ttynames[0]);++i) {
fd=open(ttynames[i],O_RDONLY);
if (fd==-1) fd=open(ttynames[i],O_WRONLY);
if (fd!=-1) {
if (!ioctl(fd,VT_OPENQRY,&number)) {
close(fd);
return number;
}
close(fd);
}
}
fprintf(stderr,"Could not get number of free tty\n");
exit(1);
}
void newtty()
{
char ttyname[42];
int fd,number;
number=newttynumber();
sprintf(ttyname,"/dev/tty%d",number);
fd=open(ttyname,O_RDWR);
if (fd==-1) {
perror(ttyname);
exit(1);
}
/* This will switch to the new tty and wait for the
* switch to complete before continuing. Remove if
* you don't want that feature.
*/
ioctl(fd,VT_ACTIVATE,number);
ioctl(fd,VT_WAITACTIVE,number);
fflush(NULL); /* With this fflush there is less
* chance of confusing stdio with
* the dup2() and fork() calls.
*/
switch(fork()) {
/* fork() makes a new copy of the process
* the parent terminates the child continues.
*/
case 0: break;
case -1: perror("fork"); exit(1);
default: _exit(0);
}
setsid(); /* setsid() disconnects from the
* controling terminal.
*/
dup2(fd,0);
dup2(fd,1);
dup2(fd,2);
/* The following line will allow the program to receive
* C-C and C-Z key combinations from the new tty.
* Remove if you don't want that feature
*/
if (ioctl(fd,TIOCSCTTY,0))
perror("Warning: could not set new controling tty");
if(fd>2) close(fd);
}
int main()
{
newtty();
/* Just an example, do whatever you like here */
system("ls");
return 0;
}
==============2FC9C8D778BAF5A952AC3365==
------------------------------
From: Kasper Dupont <[EMAIL PROTECTED]>
Crossposted-To:
alt.linux,comp.os.linux.development.apps,linux.redhat.devel,linux.redhat.development
Subject: Re: transpareny
Date: Fri, 18 May 2001 12:42:24 +0000
Kasper Dupont wrote:
>
[...]
>
> The attached example demonstrates a lot of theese
> features. You can remove the parts you don't like.
> All this program does could have been by using the
> open command with some appropriate options.
>
[...]
Oops I just discovered a small mistake the line:
if (!ioctl(0,VT_OPENQRY,&number))
is wrong it should instead have been:
if (!ioctl(i,VT_OPENQRY,&number))
--
Kasper Dupont
------------------------------
From: Josef Moellers <[EMAIL PROTECTED]>
Subject: Re: Execve and execvp
Date: Fri, 18 May 2001 15:00:13 +0200
Alessandro oVeRRiDe wrote:
> =
> 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=3Dstrcat(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.
Sorry if I confused you with that. I intended the code fragment to be a
skeleton in some "pseudo-C" ...
I usually malloc() a buffer which has the length of the first
component(the path name taken from PATH) plus 1 (for the separating /)
plus the length of the program name plus 1 (for the terminating NUL
byte):
pathcmd =3D concat(pe, cmd);
then becomes
pathcmd =3D malloc(strlen(pe) + 1 + strlen(cmd) + 1);
sprintf(pathcmd, "%s/%s", pe, cmd);
Don't forget to free() the string if execve fails!
Josef
-- =
Josef M=F6llers (Pinguinpfleger bei FSC)
If failure had no penalty success would not be a prize
-- T. Pratchett
------------------------------
From: [EMAIL PROTECTED] ("v.nagasrinivas")
Subject: Fwd: Like in windows snmp service, can i get the same in linux?
Date: Fri, 18 May 2001 13:01:43 +0000 (UTC)
Hi,
Like in windows snmp service, can i get the same in linux also.
Why means i have my own propritery snmp manager to access the mib tables
of my ATM/Frame Relay box, just now i configured the snmp services in
windows2000 server, and through general mib, i am getting my machines
information in the manager by specifying the machine as a node.
Similarly how to configure the snmp service in the linux box. Is the
snmp service integrated inside the kernel, where can i get all these
information.
thanks in advance,
regards,
srinivas.
--
v.naga srinivas
YVL SoftwareConsultancy,
B4,Q1,6th floor,
CyberTowers,Hi-Tec city,
Madhapur,Hyderabad-500033
Andhra Pradesh State
INDIA.
ph(office):091-040-3110200
visitme http://www.nagasrinivasv.com
--
Posted from ns.stph.net [196.12.32.2]
via Mailgate.ORG Server - http://www.Mailgate.ORG
------------------------------
Date: Fri, 18 May 2001 08:25:59 -0500
From: Robert Redelmeier <[EMAIL PROTECTED]>
Subject: Re: interrupts too frequent?
Barry Smyth wrote:
>
> 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?
Best to check via `rdtscl()`. This will read the time-stamp counter
and subtracting readings at entrance and exit will give you the
number of cycles your routine took. Add 200-1000 for interrupt
overhead outside your function.
-- Robert
------------------------------
From: "Ivor Cox" <[EMAIL PROTECTED]>
Subject: GNU_SOURCE
Date: Fri, 18 May 2001 14:58:25 +0100
Hi,
I am using pthread library and having trouble with pthread_cond_timedwait
which is seemingly faulty in my implementation (Red Hat 7 etc) - see my
other post.
Looking at the header file pthread.h I notice conditional compiles based on
__USE_GNU, __UNIX_98(?) and so on. Should I be specifying any of these to
use pthread in linux? What are they for and how do they affect what pthread
does?
Hope you can help. Cheers
Ivor Cox
------------------------------
Date: Fri, 18 May 2001 09:17:22 -0500
From: Robert Redelmeier <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.programming.threads
Subject: Re: SIGSEGV is not blocking
Kasper Dupont wrote:
>
> The kernel will have the option to schedule once
> at the end of every trap. Interrupts could be
> allowed to happen just after the IRET returning
> to userspace but just before reexecuting the
> failing instruction. I don't know if the Intel
> architecture actually will do that.
>
> If this would lock-up the machine I can think of
> lots of similar ways to lock-up the machine
> which the kernel doesn't know about. I will try
> changing my kernel to retry and see if it locks
> up, I don't believe it will.
Very true. DIV 0 with a null handler, for one.
I just checked this in x86 real-mode, and there
_is_ a window between the returning ISR and a
faulting instruction for other interrupts to be
handled. So no lockup.
-- Robert
------------------------------
From: "Jason M. LaPenta" <[EMAIL PROTECTED]>
Subject: isa mem in 0xA0000-0xFFFFFF, Paging fault?
Date: Fri, 18 May 2001 10:43:14 -0400
Hello,
I'm trying to access some memory located at 0xE0500 on a custom built
16bit isa card. I'm using the asm/io.h macro readw( 0xE0500 ) and I
get
the following error reported to dmesg (after my user program
segfaults
);
Unable to handle kernel paging request at virtual address 000e0500
printing eip:
c89191c2
*pde = 00000000
Oops: 0000
....
Any ideas?
Thanks a bunch in advance.
Jason
------------------------------
From: [EMAIL PROTECTED] (At150bogomips)
Date: 18 May 2001 15:05:03 GMT
Subject: mmap() and msync() extensions?
Would it be reasonable to extend mmap() to include a flag indicating
that the memory area is not intended to be used in its entirety
immediately but the application desires to use memory addressing rather
than (buffered) file I/O operations? The kernel could allocate the
address space (perhaps even the page table entries) without necessarily
loading the entire file (or large mmap()ed portion) into memory. Such
an extension might be useful to hide the memory management details from
the application. Accesses to memory that was not physically mapped
would be handled by the normal page-fault mechanism. This could be done
without making the API incompatible simply by adding a flag value
(DELAY_ALLOCATE???).
Parallel with the above would be a flag extension for msync() to allow
the application to communicate to the kernel that a region of a file is
unlikely to be used in the near future and can be given priority for
dropping (AGE_PAGES???).
Such might be useful for applications with heavy file activity (i.e.,
applications which would use mmap() to avoid file buffer memory copy
delays) possibly providing better memory management. (It might be more
appropriate/easier to tune the kernel for the charactieristics of a
system's memory than to tune individual applications.)
A further (msync()?) flag extension might be provided to
'touch'/pre-fetch an mmap()ed memory location, allowing the application
to continue while the kernel handles a (future) page fault.
This would almost make the file system an extension of the memory
hierarchy while maintaining the old API.
Paul A. Clayton
just a fool, not in love
------------------------------
From: [EMAIL PROTECTED] (At150bogomips)
Date: 18 May 2001 15:05:54 GMT
Subject: Sharing the virtual address space?
Would it be possible and reasonable for applications to share a common
virtual address space?
For current architectures, this might have very limited usefulness; but
it might allow a future architecture to use virtual addresses in caches.
A 64-bit address space might be large enough (for some time) to fully
support even virtually mapping the entire filesystem into memory (16 *
(1024^6) is a _large_ memory space).
Aside from allowing virtually-addressed caches (without flushing on
process switches), such could be used (with compilation system support)
to remove register jumps for shared library code. (Again current
architectures would not support this, though fixed relative jumps could
be supported for shared libraries by reserving, say, the first 64MB of
code space for shared libraries. The compilation system would place
program code into the space just above that shared library space and
PC-releative jumps could access that space. This would require an
install-time linking of programs to the resident libraries--presumably
using some kind of address database.) An architecture which allowed
direct jumps into any of four code segments would be able to use a
shared virtual address space. Avoiding indirect jumps can improve
performance.
Paul A. Clayton
just a fool, not in love
------------------------------
From: Josef Moellers <[EMAIL PROTECTED]>
Subject: Re: isa mem in 0xA0000-0xFFFFFF, Paging fault?
Date: Fri, 18 May 2001 17:13:19 +0200
"Jason M. LaPenta" wrote:
> =
> Hello,
> =
> I'm trying to access some memory located at 0xE0500 on a custom built
> 16bit isa card. I'm using the asm/io.h macro readw( 0xE0500 ) and I
> get
> the following error reported to dmesg (after my user program
> segfaults
> );
> =
> Unable to handle kernel paging request at virtual address 000e0500
> printing eip:
> c89191c2
> *pde =3D 00000000
> Oops: 0000
> =
> ....
> =
> Any ideas?
Yes, the kernel uses virtual addresses to access main memory.
If you look at the eip, you'll notice that it starts with "c". Usually
the kernel maps all physical memory (at least the first Gig iof it) to
virtual addresses 0xc0000000...
You need to use the function/macro ioremap_nocache() to convert physical
addresses to virtual ones. Look at aic7xxx.c for an example of how toi
use it.
Josef
-- =
Josef M=F6llers (Pinguinpfleger bei FSC)
If failure had no penalty success would not be a prize
-- T. Pratchett
------------------------------
From: Josef Moellers <[EMAIL PROTECTED]>
Subject: Re: Sharing the virtual address space?
Date: Fri, 18 May 2001 17:14:29 +0200
At150bogomips wrote:
> =
> Would it be possible and reasonable for applications to share a common
> virtual address space?
This is called "shared memory".
Also, applications executing the same code share the same virtual
address space of the code.
-- =
Josef M=F6llers (Pinguinpfleger bei FSC)
If failure had no penalty success would not be a prize
-- T. Pratchett
------------------------------
Subject: Re: mmap() and msync() extensions?
From: Dragan Cvetkovic <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Date: 18 May 2001 11:34:25 -0400
[EMAIL PROTECTED] (At150bogomips) writes:
> Would it be reasonable to extend mmap() to include a flag indicating
> that the memory area is not intended to be used in its entirety
> immediately but the application desires to use memory addressing rather
> than (buffered) file I/O operations?
You mean something like madvise(3C)? Here is the part of the man page for
madvise on Solaris 8:
The madvise() function advises the kernel that a region of
user mapped memory in the range [addr, addr + len) will be
accessed following a type of pattern. The kernel uses this
information to optimize the procedure for manipulating and
maintaining the resources associated with the specified map-
ping range.
Values for advice are defined in <sys/mman.h> as:
#define MADV_NORMAL 0x0 /* No further special treatment */
#define MADV_RANDOM 0x1 /* Expect random page references */
#define MADV_SEQUENTIAL 0x2 /* Expect sequential page references */
#define MADV_WILLNEED 0x3 /* Will need these pages */
#define MADV_DONTNEED 0x4 /* Don't need these pages */
#define MADV_FREE 0x5 /* Contents can be freed */
Bye, Dragan
--
Dragan Cvetkovic,
To be or not to be is true. G. Boole
------------------------------
From: Angry Bob <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.setup
Subject: Re: Raid A0 patch with Kernel 2.2.17 and ReiserFS
Date: 18 May 2001 15:39:07 GMT
What would you like to read? [comp.os.linux.setup or *?]
This is a [EMAIL PROTECTED] scroll! it says:
> 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.
you should check out the tux2 filesystem.... <smile>
--
AngryBob Systems Consultant - http://www.trellisinc.com
"Our relation to the universe certainly depends
on what's in it."
--Ben Oppenheimer of the University of California-Berkeley
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: USB Development
Date: Fri, 18 May 2001 16:07:03 +0000 (UTC)
--20443624.990202021758.JavaMail.nobody@www-a21
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
>Does anyone know of any resources on the above subject
>I have an ACM communications device which doesn't
>work with the existing acm driver, and I need to know
>how to access the notification pipe.
>The kernel based acm driver doesn't fully implement the
>control interface, anyone know where I can find
>out how to do this?
Specifically I am wondering how to obtain the response
to control messages I send using usb_control_msg .
=====
Be passionate about your email
Just click here: http://another.com
--20443624.990202021758.JavaMail.nobody@www-a21--
--
Posted from www.funmail.co.uk [212.62.7.9]
via Mailgate.ORG Server - http://www.Mailgate.ORG
------------------------------
** 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
******************************
