Linux-Development-Sys Digest #54, Volume #8 Sun, 30 Jul 00 11:13:14 EDT
Contents:
Re: GCC 2.95.2 problems on RedHat 6.2 -- help anyone ? (Grant Edwards)
problem with open files (Shankar)
problem with open files (Shankar)
Re: problem with open files (Let China Blue Sleep)
Module usecount probs with 2.4.0-test5 (Alexander Schulz)
Re: exec*() and argv[0] ([EMAIL PROTECTED])
Re: siginfo->si_pid and siginfo->si_gid always zero? ("Frank V. Castellucci")
Re: RedHat 6.1 kernel module oddities (Bill Waddington)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Grant Edwards)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: GCC 2.95.2 problems on RedHat 6.2 -- help anyone ?
Date: Sun, 30 Jul 2000 02:05:20 GMT
On Sat, 29 Jul 2000 22:27:02 +0200, Michael Meding <[EMAIL PROTECTED]> wrote:
>During compile of XF4.01 some targets are not made and I can't find out
>why. I have also problems bootstrapping gcc 2.95.2. Sometimes gcc
>bootstrapped fine, another run right after this stopped with sig11.
Randomly ocurring sig11's is the classic symptom of various
hardware issues. There's a sig11 FAQ at
http://metalab.unc.edu/pub/Linux/docs/faqs/GCC-SIG11-FAQ
Often it's flakey memory (either DRAM or cache). Others have
reported the same symptom for flakey PCI bus controllers or
disk controllers. Still others have reported that it was due
to CPU overheating.
>I have attached configuration files. Maybe I screwed up during
>the upgrade from egcs 1.1.2 to gcc 2.95.2 or there is a missing
>link to header or library files that I am not aware of that
>could possibly explain my problems.
I really think it's a hardware problem due to the fact that you
don't get repeatible errors.
--
Grant Edwards grante Yow! My NOSE is NUMB!
at
visi.com
------------------------------
From: Shankar <[EMAIL PROTECTED]>
Subject: problem with open files
Date: Sun, 30 Jul 2000 12:58:39 +0530
hi
I will be quick.
I got this code that needs to write and delete 16 1GB files four times
into a Cheetah SCSI 70 GB HDD. The code however does not close the files
when it has to delete these files.
On the hard disk now, df shows 100% usage while a du of the partition
shows only 35GB has been used up. Now is it because of the no. of open
files occupying space?
How do I fix the situation since I need to restart the experiment and I
can't reformat the hard disk
Thanks in advance
shankar.
------------------------------
From: Shankar <[EMAIL PROTECTED]>
Subject: problem with open files
Date: Sun, 30 Jul 2000 13:04:58 +0530
hi
I have a 70 GB SCSI HDD. I need to write and consequently delete
16 1 GB files four times each.
Now, the code does not close the files before it deletes the files
(it does this by a system("rm ...")).
What has happened is that although only 35GB has been used up,
a 100% usage is reported by df and no more free space is available. Is it
because of the open files, and how do I remedy the situation?
Thanks in advance.
shankar
------------------------------
From: [EMAIL PROTECTED] (Let China Blue Sleep)
Subject: Re: problem with open files
Date: Sun, 30 Jul 2000 00:32:17 -0700
/ On the hard disk now, df shows 100% usage while a du of the partition
/ shows only 35GB has been used up. Now is it because of the no. of open
/ files occupying space?
Yes, a deleted file will continue to exist until all opens are closed
(implicitly or explicitly). I think du only looks at directory entries; an
open file can exist after its last directory entry is deleted (which is
trick used somtimes for temporary files).
/ How do I fix the situation since I need to restart the
experiment and I
/ can't reformat the hard disk
Close or compress your files so you aren't using 64GB on 70GB disk?
--
CACS: Collective Against Consensual Sanity v0.123
Now a text site map http://www.tsoft.com/~wyrmwif/cacs/
pretty? http://www.geocities.com/SoHo/Studios/5079/
:)-free zone. Cthulu in '00: .../cacs/politics.html
------------------------------
From: Alexander Schulz <[EMAIL PROTECTED]>
Subject: Module usecount probs with 2.4.0-test5
Date: 30 Jul 2000 09:51:07 GMT
Hello,
I tried to port two of my older modules from 2.0 to 2.4. After changing some
prototypes and stuff, the first one seems to work ok, except every time I
run a program on it, the usecount is incremented by one. I have one
MOD_INC_USE_COUNT in the open- and one MOD_DEC_USE_COUNT in the
release-function. That always worked. I used GET_USE_COUNT to print the
usecount and it is always 2 when open is called, and thus 3 when release is
called. My MOD_DEC_USE_COUNT decrements it to 2, something after that
decrements it to one. But that is still too much, of course.
When the module is opened and another program tries to open it, open returns
-EBUSY without incrementing the usecount. But what happens is this: open is
called with usecount=5 (again incremented by 2) and leaves it at 4 after it
returned the error.
Can anybody tell me what is changing my usecount here? Other modules
(smc-ultra, sensors, lm75 etc.) seem to work correctly, so probably it's
something with my module but I really can't find it.
I am usig modutils 2.3.11, kernel 2.4.0-test5, glibc 2.1.3, gcc 2.95.2,
binutils 2.9.5, the module is compiled with:
gcc -O2 -Wall -DMODULE -D__KERNEL__ -D__SMP__ -I/usr/src/linux/include
-fomit-frame-pointer -c devicenet.c
Any ideas?
Thanks in advance
Alexander
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: exec*() and argv[0]
Date: Sun, 30 Jul 2000 11:14:03 GMT
On Fri, 28 Jul 2000 17:45:22 -0700 John Reiser <[EMAIL PROTECTED]> wrote:
| In general, a process that tries to infer any information from the
| pathname that was exec()ed is doomed to failure. There simply is
| no guarantee about whether that pathname still has any relevance at all.
| Any number of unlink, chdir, unmount, chroot, etc. (by this process
| or any other) could have taken place between the exec() and the
| attempted inference. Do not attempt to infer an "installation
| directory", the location of any "preferences file", etc., from
| the pathname to exec(). [Also remember /proc/self/exe, for what
| it is worth.]
|
| If you _really_ want to know what the pathname was, Linux helps
| you by putting it at the fixed end of the stack. On common x86
| systems where the stack ends at 0xc0000000, then 0xbffffffc has
| 32 bits of 0, and 0xbffffffb has the '\0' which terminates the
| pathname. So search backwards for another '\0', and the pathname
| lies between.
I've wondered why a few programs have sometimes operated in a goofy
way, now I know.
We're not talking about the path to the script becoming irrelevant,
we're talking about the path to the interpreter, as seen by that
interpreter. If a script makes a reference to a different version
of an interpreter by means of a specific path, that interpreter should
have, in a convenient and PORTABLE way, the actual path used to invoke
it. The interpreter may need access to private libraries or locale
data or anything else specific to its function. Those files may have
an entirely different format, layout, or semantics, in the new version
of the interpreter. This could also be the case for older versions
where scripts have not been upgraded.
So what if unlink, chdir, unmount, chroot, or other functions are done.
If the interpreter does them in a way that impacts the path, then it is
responsible for that. If you or someone who has cracked into your
system does those things on the side, then you deserve what you get.
The kernel should not cripple a useful facility just to protect a few
lame interpreter programmers, or mindless sysadmins, or systems that
are left wide open by other means.
If you'd like to suggest a PORTABLE way, that works across all machine
architectures of Linux, as well as on all other UNIX systems where the
intended design is to provide useful information, then I am interested.
Make that suggestion in the form of how it might be done as an interface
as part of a standard like POSIX, and I will consider it to be serious.
But you have utterly failed to justify why the interpreter path should
be ignored by the interpreter (however it might manage to get it).
--
| Phil Howard - KA9WGN | My current websites: linuxhomepage.com, ham.org
| phil (at) ipal.net +----------------------------------------------------
| Dallas - Texas - USA | [EMAIL PROTECTED]
------------------------------
Date: Sun, 30 Jul 2000 07:51:54 -0400
From: "Frank V. Castellucci" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: siginfo->si_pid and siginfo->si_gid always zero?
Yes, I had the same problem (sample code at end), although I was trying
to use it with 'clone' not 'fork'.
What I had done was interperet the last argument and found that the
process id of the child thread was in two places (although I forget
which, but if you compile and run this it will show you).
/* semaphore.c --- simple illustration of dijkstra's semaphore analogy
*
* We fork() a child process so that we have two processes running:
* Each process communicates via a semaphore.
* The respective process can only do its work (not much here)
* When it notices that the semaphore track is free when it returns to
0
* Each process must modify the semaphore accordingly
*/
#include <stdio.h>
#include <sys/types.h>
#include <sys/ipc.h>
#include <sys/sem.h>
#include <signal.h>
#include <stdio.h>
#include <stdlib.h>
#include <fcntl.h>
#include <linux/unistd.h>
#define STACKSIZE 16384
#define CSIGNAL 0x000000ff /* signal mask to be sent at
exit */
#define CLONE_VM 0x00000100 /* set if VM shared between
processes */
#define CLONE_FS 0x00000200 /* set if fs info shared between
processes */
#define CLONE_FILES 0x00000400 /* set if open files shared
between processes */
#define CLONE_SIGHAND 0x00000800 /* set if signal handlers shared
*/
int start_thread(void (*fn)(void *), void *data)
{
long retval;
void **newstack;
/*
* allocate new stack for subthread
*/
newstack = (void **) malloc(STACKSIZE);
if (!newstack)
return -1;
/*
* Set up the stack for child function, put the (void *)
* argument on the stack.
*/
newstack = (void **) (STACKSIZE + (char *) newstack);
*--newstack = data;
/*
* Do clone() system call. We need to do the low-level stuff
* entirely in assembly as we're returning with a different
* stack in the child process and we couldn't otherwise
guarantee
* that the program doesn't use the old stack incorrectly.
*
* Parameters to clone() system call:
* %eax - __NR_clone, clone system call number
* %ebx - clone_flags, bitmap of cloned data
* %ecx - new stack pointer for cloned child
*
* In this example %ebx is CLONE_VM | CLONE_FS | CLONE_FILES |
* CLONE_SIGHAND which shares as much as possible between parent
* and child. (We or in the signal to be sent on child
termination
* into clone_flags: SIGCHLD makes the cloned process work like
* a "normal" unix child process)
*
* The clone() system call returns (in %eax) the pid of the
newly
* cloned process to the parent, and 0 to the cloned process. If
* an error occurs, the return value will be the negative errno.
*
* In the child process, we will do a "jsr" to the requested
function
* and then do a "exit()" system call which will terminate the
child.
*/
// __asm__ __volatile__(
// "int $0x80\n\t" /* Linux/i386 system call */
// "testl %0,%0\n\t" /* check return value */
// "jne 1f\n\t" /* jump if parent */
// "call *%3\n\t" /* start subthread function */
// "movl %2,%0\n\t"
// "int $0x80\n" /* exit system call: exit
subthread */
// "1:\t"
// :"=a" (retval)
// :"0" (__NR_clone),"i" (__NR_exit),
// "r" (fn),
// "b" (CLONE_VM | CLONE_FS | CLONE_FILES |
CLONE_SIGHAND | SIGCHLD),
// "c" (newstack));
retval = clone(fn,newstack,CLONE_VM | CLONE_FS | CLONE_FILES |
CLONE_SIGHAND | SIGCHLD,0);
if (retval < 0) {
errno = -retval;
retval = -1;
}
return retval;
}
int show_same_vm;
void threadTerminated( int aNum, siginfo_t *vInfo, void *vPtr )
{
unsigned long *p = (unsigned long *)vPtr;
printf("%d\n",p[0]);
printf("%d\n",p[1]);
printf("%d\n",p[2]);
printf("%d\n",p[3]);
printf("%d\n",p[4]);
printf("%d\n",p[5]);
printf("%d\n",p[6]);
printf("%d\n",p[7]);
printf("%d\n",p[8]);
printf("%x\n",p[9]);
printf("%d\n",p[10]);
printf("%x\n",p[11]);
printf("%x\n",p[12]);
printf("%d\n",p[13]);
printf("%d\n",p[14]);
printf("%x\n",p[15]);
printf("%d\n",p[16]);
/*
(unsigned long *)vPtr[0];
(unsigned long *)vPtr[1];
(unsigned long *)vPtr[2];
(unsigned long *)vPtr[3];
(unsigned long *)vPtr[4];
(unsigned long *)vPtr[5];
(unsigned long *)vPtr[6];
(unsigned long *)vPtr[7];
(unsigned long *)vPtr[8];
(void * ) (unsigned long *)(vPtr)[9];
(unsigned long *)(vPtr)[10];
(void * ) (unsigned long *)(vPtr)[11];
(void * ) (unsigned long *)(vPtr)[12];
(unsigned long *)vPtr[13];
(unsigned long *)(vPtr)[14];
(void * ) (unsigned long *)(vPtr)[15];
(unsigned long *)(vPtr)[16];
*/
printf("Terminate received\n");
}
void cloned_process_starts_here(void * data)
{
printf("child:\t got argument %d as fd\n", (int) data);
show_same_vm = 5;
printf("child:\t vm = %d\n", show_same_vm);
close((int) data);
}
int main()
{
int fd, pid,status;
struct sigaction sa;
memset(&sa,0,sizeof(sa));
sa.sa_sigaction = threadTerminated;
sa.sa_flags = SA_SIGINFO;
if( sigaction(SIGCHLD,&sa,NULL) == -1 )
perror("sigaction");
fd = open("/dev/null", O_RDWR);
if (fd < 0) {
perror("/dev/null");
exit(1);
}
printf("mother:\t fd = %d\n", fd);
show_same_vm = 10;
printf("mother:\t vm = %d\n", show_same_vm);
pid = start_thread(cloned_process_starts_here, (void *) fd);
if (pid < 0) {
perror("start_thread");
exit(1);
}
else
{
printf("Child thread id = %d\n",pid);
}
waitpid(pid,&status,0);
printf("mother:\t vm = %d\n", show_same_vm);
if (write(fd, "c", 1) < 0)
printf("mother:\t child closed our file descriptor\n");
}
Noam Koren wrote:
>
> The kernel version is 2.2.14-5.0
> Noam
>
> Frank V. Castellucci wrote:
>
> > Noam Koren wrote:
> > >
> > > Hi,
> > >
> > > I wrote a signal handler that uses the SA_SIGINFO flag and was installed
> > > using the sa_sigaction parameter. I did this in order to make use of the
> > > siginfo_t which should be passed to the handler (see: man sigaction).
> > > However, when the handler is invoked (after a kill(pid,SIGUSR1) in a
> > > child process), only the si_signo is filled correctly in the siginfo_t
> > > struct (si_uid and si_pid are 0).
> > >
> > > Any ideas?
> > >
> > > The handler begins like this:
> > > void handler(int signo, siginfo_t * siginfo,ucontext * uc){
> > > int a;
> > > pid_t b;
> > > uid_t c;
> > >
> > > a=siginfo->si_signo;
> > > b=siginfo->si_pid; // this always returns 0
> > > c=siginfo->si_uid; // this always returns 0 (yes, even when I am not
> > > root...)
> > > ...
> > > ...
> > >
> > > }
> > >
> > > Thanks in advance,
> > > Noam
> >
> > What kernel version, distributions, etc. are you working with?
> >
> > --
> > Frank V. Castellucci
--
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux
http://PythPat.sourceforge.net
Pythons Pattern Package
------------------------------
From: Bill Waddington <[EMAIL PROTECTED]>
Subject: Re: RedHat 6.1 kernel module oddities
Date: Sun, 30 Jul 2000 14:46:13 GMT
In article <8lums6$hi9$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Donald Becker) wrote:
> In article <[EMAIL PROTECTED]>,
> Richard Bonomo <[EMAIL PROTECTED]> wrote:
> >Villy Kruse wrote:
> >>
> >> On Fri, 07 Jul 2000 17:39:31 -0500, Richard Bonomo
<[EMAIL PROTECTED]> wrote:
> >> >While calls to "inb" and "outb" worked just fine
> >> >in a privileged user program, and while gcc -c <name>
> >> >produces no errors, attempts to load the module
> >> >(with insmod) immediately generates messages to the
> >> >effect that outb and inb are not recognized symbols (!!).
> >>
> >> ioremap is an inline function, and that works only if you
> >> compile with -O2. Same for inb and outb.
> >>
> >> These inline functions are defined in <asm/io.h>.
> >
> >Yes, I know they are defined in <asm/io.h>, but the
> >subtlety about -O being REQUIRED had escaped me.
>
> I used to get a dozen or so emails a day with people that didn't
follow the
> compile instructions until I put the following lines in my drivers:
>
> #ifndef __KERNEL__
> #define __KERNEL__
> #endif
> #if !defined(__OPTIMIZE__)
> #warning You must compile this file with the correct options!
> #warning See the last lines of the source file.
> #error You must compile this driver with "-O".
> #endif
>
> >P.S. Do you know if there is a "sleep" or "usleep"
> >function (or equivalent) available to the kernel, or
> >is it necessary to employ a do-nothing loop to put
> >in a delay?
>
> Use 'usleep()', but only if you are delaying for a under 50 usec.
*total*.
> (Not in a loop.) If you need to wait longer, set a timer and return
from
> the interrupt or reschedule().
>
> Never, ever write a loop that does "while (jiffies < endtime) ;"
unless you
> understand everything about the kernel.
>
> (I have seen this style of delay loop called at interrupt time. It
might
> work some of the time, but consider nested interrupts or shared
interrupts.)
>
Hello Donald,
Are you recommending against
while (jiffies < wait_j) schedule();
anywhere in a driver module, or just in interrupt context? I use this
kind of delay in init_module() to wait for on board eeprom to initialize
a bus interface chip. It seems to work just fine, but I wonder if I'm
on shaky ground?
Thanks,
Bill
--
Bill Waddington
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
** 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
******************************
