Linux-Development-Sys Digest #930, Volume #7 Fri, 2 Jun 00 19:13:15 EDT
Contents:
Re: A problem with LinuxPthreads (Kaz Kylheku)
Re: Why compiling "-static" creates HUGE binary??? (bill davidsen)
Periodic Timers in Linux Kernel module development? (Christopher Rumpf)
Re: A problem with LinuxPthreads (John McKown)
Re: Periodic Timers in Linux Kernel module development? (Kaz Kylheku)
Re: Linux pthreads and a safe read/write with timeout (Tom Roberts)
Re: Why compiling "-static" creates HUGE binary??? (Kent A Vander Velden)
Re: Program: Output protokoll to a serial interface and to a file ? (Mario Klebsch)
Re: Kernel panic: aic7xxx: unrecoverable BRKADRINT. In swapper task - not syncing.
(palito)
kernal panic on RH6.2 no init found (kat)
Re: HELP: dirt-simple net driver panic (Tom Roberts)
Re: Why compiling "-static" creates HUGE binary??? (Andreas Kahari)
Can't compile a module under Mandrake 7.0 (Marc Framboisier)
volume serial number ("Marco")
Re: Linux pthreads and a safe read/write with timeout (Christian Plattner)
Re: awful performance of SysV shared memory on Linux (Stefaan A Eeckels)
Re: Writing driver for AMCC 5933 based PCI card ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: A problem with LinuxPthreads
Reply-To: [EMAIL PROTECTED]
Date: Fri, 02 Jun 2000 17:34:01 GMT
On Fri, 02 Jun 2000 12:09:02 -0400, James Connell <[EMAIL PROTECTED]> wrote:
>Hello,
>
>I've been having a problem compiling a program using LinuxPthreads (0.8
>as included with RedHat 6.0) for quite some time. In the program I am
>making use of the non-portable call "pthread_mutexattr_setkind_np" to
>setup a recursive mutex as below:
>
>[snip]
>#include <pthread.h>
>...
>pthread_mutexattr_t attr;
>
>pthread_mutexattr_init(&attr);
>pthread_mutexattr_setkind_np(&attr, PTHREAD_MUTEX_RECURSIVE_NP);
>
>[end snip]
>
>The main problem is that g++ will generate a warning stating that
>"pthread_mutexattr_setkind_np" is not defined. I attempted to remedy
>this by defining the function as it is declared in the appropriate
>manpage. After doing this, I cannot link the library as the symbol for
>"pthread_mutexattr_setkind_np" is undefined.
This function is obsolete; The Single UNIX Specification defines a function
called ``pthread_mutexattr_settype'' which does the same thing. To enable this
function in the header file, you need to have -D_XOPEN_SOURCE=500 on the
compiler command line.
The pthread_mutexattr_setkind_np does not appear in the header file. It is in
the library presumably for the sake of providing binary compatibility to older
glibc applications that used it.
>I looked at /lib/pthread.so and sure enough the symbol was defined as a
>weak symbol.
Did you forget to use extern "C" in the declaration? If so, your declaration
declares a C++ function, and will not resolve to the C function in the library.
--
#exclude <windows.h>
------------------------------
From: [EMAIL PROTECTED] (bill davidsen)
Crossposted-To: alt.os.linux,linux.dev.c-programming,linux.dev.gcc
Subject: Re: Why compiling "-static" creates HUGE binary???
Date: 2 Jun 2000 17:48:49 GMT
In article <nqsZ4.1271$[EMAIL PROTECTED]>,
RMain <[EMAIL PROTECTED]> wrote:
| with gcc as follows:
|
| gcc -m386 -O2 -Wall -fomit-frame-pointer -static -o test test.c
|
| I get a 940KB binary????
|
| If I remove "-static" from the command line, the binary reduces to 11.5 KB.
Strip it, and use the option --strip-all (or try --strip-debug) to get
out the symbols. Try less optimization, down to -O0, since one thing the
optimizer does in unroll loops.
I hate to say Microsoft did something right, but their old (v6?)
compiler let you choose optimize for speed or size. I don't really see
this in gcc.
--
bill davidsen <[EMAIL PROTECTED]> CTO, TMR Associates, Inc
"Doing interesting things with little computers since 1979"(tm)
The hardest test of maturity is knowing the difference between
resisting temptation and missing a once-in-a-lifetime opportunity.
------------------------------
From: Christopher Rumpf <[EMAIL PROTECTED]>
Subject: Periodic Timers in Linux Kernel module development?
Date: Fri, 02 Jun 2000 13:59:26 -0400
I'm having some difficulty implementing a reliable periodic timer for my
linux kernel module. I thought that I could write a routing that would
basically be called when the timer popped, called the necessary callback
function needed and then reschedule the timer basically as follows:
void SetPeriodicTimer(struct timer_list *Timer, unsigned exp_time)
{
Timer->function = PeriodicHandler;
Timer->data = (unsigned long)Timer;
Timer->expires = exp_time;
}
void PeriodicHandler(void *Context)
{
struct timer_list *tp = (struct timer_list *)Context;
/* do something useful here*/
add_timer(tp);
}
Ok, so it seems when the timer pops, I get into the "PeriodicHandler()"
but when it tries to add the timer again, my box hangs. Any idea what
this is about or if there's a better way to implement a periodic timer
functionality?
Thanks,
Chris Rumpf
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (John McKown)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: A problem with LinuxPthreads
Date: Fri, 2 Jun 2000 12:58:44 -0500
On Fri, 02 Jun 2000 12:09:02 -0400, James Connell <[EMAIL PROTECTED]> wrote:
>Hello,
>
>I've been having a problem compiling a program using LinuxPthreads (0.8
[snip]
>
>The main problem is that g++ will generate a warning stating that
>"pthread_mutexattr_setkind_np" is not defined. I attempted to remedy
>this by defining the function as it is declared in the appropriate
>manpage. After doing this, I cannot link the library as the symbol for
>"pthread_mutexattr_setkind_np" is undefined.
[snip]
My version of libpthread (0.8) does have this function. It appears to be a
part of glibc-2.1.90-13. I also checked the current 6.2 glibc which is
2.1.3-15. It also appears to have this function. Please note that you
can run this version on your RedHat 6.0 system. That is what I am really
running. Unfortunately, I can't remember what other rpms that I had to
install as well. There may be dependencies.
Anyway, try to find either of those rpms, along with the -devel and
-profile rpms as well. Note - I think the 2.1.90-13 version is in the "rawhide"
directories. I'm not sure where you can get it - check the RedHat web site
for mirrors.
WARNING!!! Do NOT install glibc-2.1.90-11! I installed this
and had all sorts of hell. Basically, any program that tried to run with
a setuid or setgid would seg fault. Luckily, rpm did not do this & I was
able to get ahold of the -13 that I installed and am now running successfully.
Also, these rpms total up to about 24Mb for all three. If you're not on
a high-speed connection, this can be boring & error prone.
Good luck,
John
Another possibility is to just get the 6.2 CDs from http://www.cheapbytes.com
for about US$5.00
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: Periodic Timers in Linux Kernel module development?
Reply-To: [EMAIL PROTECTED]
Date: Fri, 02 Jun 2000 18:28:15 GMT
On Fri, 02 Jun 2000 13:59:26 -0400, Christopher Rumpf <[EMAIL PROTECTED]> wrote:
>void PeriodicHandler(void *Context)
>{
> struct timer_list *tp = (struct timer_list *)Context;
>
> /* do something useful here*/
>
> add_timer(tp);
>}
Oops; you forgot to set the expiry time of the timer. The expiry is
an absolute time, rather than a relative interval. If it is not
set at the time the alarm goes off, it will indicate that the alarm
is overdue.
This might cause infinite looping; remember, the caller to ``PeriodicHandler''
is a function which iterates over the list of timers. If you keep adding a
fresh timer to that list from within that function, it's possible that the
iteration might not terminate.
--
#exclude <windows.h>
------------------------------
From: Tom Roberts <[EMAIL PROTECTED]>
Subject: Re: Linux pthreads and a safe read/write with timeout
Date: Fri, 02 Jun 2000 13:36:05 -0500
root wrote:
> pthread_testcancel();
> retcode = read(fd, buffer, length);
> pthread_testcancel();
> but what happens if the signals is beeing delivered _between_ the first
> pthread_testcancel() and the read call?
> I think the signal will get "lost", since the read call is not a
> cancelation point. -> there will be no timeout on the read?!?
> anybody has code fragment, that works 100%?
I don't think there is a race-free way to do it this way.
Instead, do your best this way, but have the read thread also
acknowledge that it has received the cancel by modifying some global
variable associated with itself. Have the timeout thread send
repeated signals until acknowledged. Now you have a different problem
-- how can the read thread proceed after receiving a cancel without
getting a spurious cancel on its next read? -- have the timeout
thread clear the acknowledgement, and after a cancel the read thread
should acknowledge it and then wait until it is cleared (using a
spin loop with a short sleep).
In my system, the "cancel" is really an abort, so no
acknowledgement is needed -- the read thread simply exits
and the timeout thread repeatedly does pthread_kill()
until it fails (indicating the read thread has exited).
The timeout thread only wakes up once per second, so the
multiple pthread_kill()-s are separated.
While the use of threads can simplify some tasks, it can greatly
complicate others, especially when multiple threads need to
cooperate.
Tom Roberts [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Kent A Vander Velden)
Crossposted-To: alt.os.linux,linux.dev.c-programming,linux.dev.gcc
Subject: Re: Why compiling "-static" creates HUGE binary???
Date: 2 Jun 2000 19:31:32 GMT
In <[EMAIL PROTECTED]> [EMAIL PROTECTED] (Andreas Kahari) writes:
>And by the way, don't ever compile a program into something with the
>same name as a shell builtin... Some of my student got really confused
>when their 'test' program didn't produce the output they wanted, no
>matter how they changed the code... ;-)
Who would ever have '.' in their path? Wouldn't you always
run ./test anyway? :)
--
Kent Vander Velden
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Mario Klebsch)
Subject: Re: Program: Output protokoll to a serial interface and to a file ?
Date: Fri, 2 Jun 2000 20:24:09 +0200
"Rachid Broum" <[EMAIL PROTECTED]> writes:
>Does somebody find out witch Programm use the output protokoll to a serial
>interface and in the same time link that output to a file ?
tee(1) ?
73, Mario
--
Mario Klebsch [EMAIL PROTECTED]
------------------------------
Subject: Re: Kernel panic: aic7xxx: unrecoverable BRKADRINT. In swapper task - not
syncing.
From: palito <[EMAIL PROTECTED]>
Crossposted-To: linux.redhat.install
Date: Fri, 02 Jun 2000 13:19:09 -0700
i have the same problem with a HP Netserver LC! is there any
workaround?
tia,
Ram�n
In article <8g1v3i$rmh$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(Ed Moore) wrote:
>Reinhold J. Gerharz" > (PostNoEmail<[EMAIL PROTECTED]) wrote:
>: > The above is the error I get on the first screen when
trying to install
>: Red
>: > Hat Linux 6.2
>: >
>: > Any ideas what it means?
>: >
>: > Thanks!
>
>: PS. Oops! Forgot to mention: Its on an EISA 486 PC with AHA-
2742, ATI Ultra
>: Graphics Pro, and slot 4 is vacant. The PC just locks up!
>
>This is the behavior observed on HP NetServer LC EISA Pentium
systems
>with onboard SCSI equivalent to AHA-2740.
>
>: PPS. RH Linux 6.1 installed just fine...
>
>Likewise on the NetServers. RH 5.2 had a similar installation
problem
>with AHA-2740, but RH quickly released a new boot diskette that
solved
>that problem. RH has an updated boot diskette for 6.2 at
><http://www.redhat.com/support/errata/RHBA-2000010-01.html>,
but it
>does not help on the systems I've tried.
>
>
>
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
From: kat <[EMAIL PROTECTED]>
Subject: kernal panic on RH6.2 no init found
Date: Fri, 02 Jun 2000 20:30:07 GMT
Hi.. I'm in need of some help and researching has gotten me lil more than
nowhere...
I have been setting up a development server for my work, mind you I have
very little knowledge of what I'm doing, (my senior programmer put me on
the job to learn) and I've come upon what seems a fairly serious problem I
can find no documentation on.
My senior programmer requested I set up the ftp to allow anonymous login,
as I had previously disabled it, and to model it after another server we
rent space on. In the /home/ftp dir there were lib, etc, bin, and pub
directories in my ftp tree. On the server I am modelling after, there was
all but the lib directory, out of stupidity after changing permissions on
the folder and decided that still didn't feel secure, I moved it up to the
/home directory. That felt completely wrong and in trying to move it back,
everything went haywire. No commands could be found, and eventually the
server froze. When I tried rebooting, I got the error, 'kernel panic! no
init found. try passing init= to the kernel" so after some more research I
found the proper syntax for passing the init= to the kernel, yet it
wouldn't give me a bash prompt. so.... I'm now on the boot diskette, using
'linux rescue' at the bash prompt and the files I originally moved seemed
to be in the proper places, however, nothings fixed.. I'm thoroughly lost
and searches upon searches have revealed nothing. Would anyone have any
advice for me? Or even a link to some documentation? Am I screwed?
please help and thank you in advance..
Best,
-Kate
--
Posted via CNET Help.com
http://www.help.com/
------------------------------
From: Tom Roberts <[EMAIL PROTECTED]>
Subject: Re: HELP: dirt-simple net driver panic
Date: Fri, 02 Jun 2000 15:38:43 -0500
Tom Roberts wrote:
> I am trying to write a network driver for Linux to talk to our board.
> It panics the kernel.
Well, I found it. Remarkably the unlikely procedure of randomly
changing the code actually worked!!
The offending line in the init function is:
dev->hard_header_len = 0;
Removing it solved the problem. Don't ask me why (because I have
do-nothing header functions). My device has no hardware header,
but I guess the ethernet support functions really insist on
pretending it does.
Tom Roberts [EMAIL PROTECTED]
------------------------------
Crossposted-To: alt.os.linux,linux.dev.c-programming,linux.dev.gcc
Subject: Re: Why compiling "-static" creates HUGE binary???
From: [EMAIL PROTECTED] (Andreas Kahari)
Date: 2 Jun 2000 23:46:06 +0100
In article <8h922k$dut$[EMAIL PROTECTED]>,
Kent A Vander Velden <[EMAIL PROTECTED]> wrote:
>In <[EMAIL PROTECTED]> [EMAIL PROTECTED] (Andreas
>Kahari) writes:
>
>>And by the way, don't ever compile a program into something with the
>>same name as a shell builtin... Some of my student got really confused
>>when their 'test' program didn't produce the output they wanted, no
>>matter how they changed the code... ;-)
>
> Who would ever have '.' in their path? Wouldn't you always
>run ./test anyway? :)
>
>--
>Kent Vander Velden
>[EMAIL PROTECTED]
Some people get tired of putting that './' before every program they
run so they put '.' in their $PATH. This alright and bearable if they
put it *last* in their $PATH, but some people don't care about such
trifles.
/A
--
# Andreas K�h�ri, <URL:http://hello.to/andkaha/>.
# All junk e-mail is reported to the
# appropriate authorities, no exceptions.
------------------------------
From: [EMAIL PROTECTED] (Marc Framboisier)
Subject: Can't compile a module under Mandrake 7.0
Date: Fri, 02 Jun 2000 22:38:27 GMT
Reply-To: [EMAIL PROTECTED]
Hi all,
I tried to compile a module under Linux Mandrake 7.0 and I had a lot
of parsing error while including <linux/sched.h> file. I compiled with
-c option :
gcc -c toto.c
Here is the includes of my c file :
#define __KERNEL__
#define MODULE
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/sched.h>
#include <linux/string.h>
#include <linux/timer.h>
#include <linux/ptrace.h>
#include <linux/errno.h>
#include <linux/ioport.h>
#include <linux/malloc.h>
#include <linux/interrupt.h>
#include <linux/pci.h>
#include <asm/processor.h>
#include <asm/bitops.h>
#include <asm/unaligned.h>
#include <asm/io.h>
Here is what I got.
In file included from /usr/include/linux/fs.h:270,
from /usr/include/linux/capability.h:13,
from /usr/include/linux/binfmts.h:5,
from /usr/include/linux/sched.h:8,
from toto.c:23:
/usr/include/linux/hpfs_fs_i.h:5: parse error before `ino_t'
/usr/include/linux/hpfs_fs_i.h:5: warning: no semicolon at end of
struct or union
/usr/include/linux/hpfs_fs_i.h:12: parse error before `:'
In file included from /usr/include/linux/fs.h:272,
from /usr/include/linux/capability.h:13,
from /usr/include/linux/binfmts.h:5,
from /usr/include/linux/sched.h:8,
from toto.c:23:
/usr/include/linux/msdos_fs_i.h:36: parse error before `off_t'
/usr/include/linux/msdos_fs_i.h:36: warning: no semicolon at end of
struct or union
In file included from /usr/include/linux/fs.h:273,
from /usr/include/linux/capability.h:13,
from /usr/include/linux/binfmts.h:5,
from /usr/include/linux/sched.h:8,
from toto.c:23:
/usr/include/linux/umsdos_fs_i.h:62: field `msdos_info' has incomplete
type
/usr/include/linux/umsdos_fs_i.h:69: parse error before `off_t'
/usr/include/linux/umsdos_fs_i.h:69: warning: no semicolon at end of
<.............>
more thansands of lines like these.
Is there any body who guess what happened.
thanx
Marc.
Ciao.
--
Marc Framboisier
[EMAIL PROTECTED]
------------------------------
From: "Marco" <[EMAIL PROTECTED]>
Subject: volume serial number
Date: Fri, 2 Jun 2000 14:31:09 +0200
Is it possible to get format date from the volume serial number of a win98
partition?
this because I need to know when a partition was formatted.
tnks evry1, is a dead or alive question.
by all
------------------------------
From: Christian Plattner <[EMAIL PROTECTED]>
Subject: Re: Linux pthreads and a safe read/write with timeout
Date: Sat, 03 Jun 2000 01:13:52 +0200
Thanks for the answer,
>
> In my system, the "cancel" is really an abort, so no
> acknowledgement is needed -- the read thread simply exits
> and the timeout thread repeatedly does pthread_kill()
> until it fails (indicating the read thread has exited).
> The timeout thread only wakes up once per second, so the
> multiple pthread_kill()-s are separated.
>
Well, that's a safe way to guarantee the reception of the signal :)
Shortly after I posted the question, I asked myself: Why not use the
select call? It is implemented (the timeout) in the kernel directly, so
we don't
have to mess around with signals.
What do you think about this code? It has the advantage, that the
thread can exit "nicely" on timeout. (and we don't need an alarm thread)
timeout.tv_sec = 2;
timeout.tv_usec = 0;
...put fd in readfdset...
do {
res = select(...,readfset,..., &timeout); // linux updates timeout
after an interrupt
while ((res < 0)&&(errno == EINTR)&&((timeout.tv_sec>0) ||
(timeout.tv_usec>0)))
if (res>0) {
// it is safe now to read from the descriptor, the call won't block
read(fd,...)
}else{
// timeout, abort)
}
- Christian
------------------------------
From: [EMAIL PROTECTED] (Stefaan A Eeckels)
Crossposted-To: comp.os.linux.development
Subject: Re: awful performance of SysV shared memory on Linux
Date: Sat, 3 Jun 2000 00:34:09 +0200
In article <8h9356$ais$[EMAIL PROTECTED]>,
"Mladen Adamovic" <[EMAIL PROTECTED]> writes:
> I create 4 processes and comunicate with them using shared memory for doing
> pseudo-concurrent executation of program equivalent to this one:
>
> #include <stdio.h>
> int main(void)
> {
> for(int i=0;i<1000;i++)
> {
> printf("%d\n",i);
> }
> return 0;
> }
>
> Time to execute this program presudo-concurrent was 10 minutes!!!
> See attach.
>
> Is SysV concepts of IPC under Linux implemented so bad, or I am wrong?
I compiled and ran the attached program, with the following results:
$ time ./shm
serve
serve client:1 with n:3
serve client:2 with n:4
reg_client
reg_client
serve client:3 with n:5
serve client:2 with n:6
reg_client
serve client:1 with n:7
serve client:1 with n:8
serve client:2 with n:9
serve client:3 with n:10
serve client:1 with n:11
serve client:1 with n:12
serve client:1 with n:13
serve client:1 with n:14
serve client:1 with n:15
serve client:1 with n:16
serve client:1 with n:17
serve client:1 with n:18
serve client:1 with n:19
serve client:1 with n:20
client 1 has 2039432 idle loops
client 2 has 1862139 idle loops
serve client:1 with n:212 : 2
client 3 has 1235355 idle loops
3 : 3
4 : 4
5 : 5
6 : 6
7 : 7
8 : 8
9 : 9
10 : 10
11 : 11
12 : 12
13 : 13
14 : 14
15 : 15
16 : 16
17 : 17
18 : 18
19 : 19
server has 355980 idle loops
0.080u 0.000s 0:00.31 25.8% 0+0k 0+0io 84pf+0w
This is on a bi-processor PentiumII/266 with 256MB of memory.
On a uni-processor PIII/450 with 192MB:
0.170u 0.000s 0:00.79 21.5% 0+0k 0+0io 86pf+0w
I wonder where your 10 minutes come from...
Take care,
--
Stefaan
--
--PGP key available from PGP key servers (http://www.pgp.net/pgpnet/)--
Ninety-Ninety Rule of Project Schedules:
The first ninety percent of the task takes ninety percent of
the time, and the last ten percent takes the other ninety percent.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Writing driver for AMCC 5933 based PCI card
Date: Fri, 02 Jun 2000 22:26:16 GMT
In article
<[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Julian Back wrote:
> >
> > Thanks for reading my post Bill.
> >
> > >What version(s) of Linux? DMA to/from
kernel or user buffer? Does it
> > >fail after ~ the same number of transfers
each time? ...
> >
> > I'm developing on Red Hat 6.1 which I think
is kernel 2.2.12 but I've also
> > 2.2.14, it made no difference.
> >
> > I'm DMAing to and from kernel buffers
allocated with get_free_page(GFP_KERNEL).
> > I've tried adding the GFP_DMA flag but it
makes no difference and my
> > understanding is that this is only necessary
for ISA DMA.
> >
> > The number of transfers before crashing can
vary a lot. Sometimes it has done
> > 3 million transfers before crashing other
times it crashes almost immediately.
> >
> > Julian
> >
>
> I don't know the AMCC5933, but PLX published a
6-page list of mostly DMA
> related bugs in their PCI9080. A few of them
could be responsible for
> this kind of problems. Maybe ask AMCC for known
bugs/workarounds?
Thanks for the tip. There are some AMCC related
problems that could be responsible for this.
I've just got to convince the hardware designer
that it's hardware rather than software that's at
fault. I have tried to capture the problem
occurring on a PCI analyser but without much luck
yet. After the lockup the PCI bus is in a funny
state, if I remember rightly IRDY is asserted but
MRDY is not.
Thanks
Julian
>
> Regards,
>
> Iwo
>
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
******************************
