Linux-Development-Sys Digest #47, Volume #8      Wed, 26 Jul 00 12:13:20 EDT

Contents:
  Re: Reproducable crashing linux-2.2.16 (Martin Kahlert)
  linux bridge support... (Graduate)
  Re: request_irq problem (Daniel Etzold)
  Re: Reproducable crashing linux-2.2.16 (Thomas Zajic)
  Re: A good IDE (cLIeNUX user)
  /tmp/kfm_503* and /tmp/kio_503* ([EMAIL PROTECTED])
  Re: /tmp/kfm_503* and /tmp/kio_503* (peter katzmann)
  problem with Soundblaster PCI 128 (OEM) & Suse 6.3 (Vreught)
  Re: problem with Soundblaster PCI 128 (OEM) & Suse 6.3 
(=?iso-8859-1?Q?Rasmus_B=F8g_Hansen?=)
  Re: where is "clear" source?? (Thomas Dickey)
  Problems with gdb and threads ([EMAIL PROTECTED])
  ioctl porting problem (works under Solaris) (Cyrille Artho)
  Re: request_irq problem (Frank Haverkamp)
  Re: TCP/IP (Grant Edwards)
  Re: Problems with gdb and threads (Bryan Hackney)

----------------------------------------------------------------------------

From: [EMAIL PROTECTED] (Martin Kahlert)
Subject: Re: Reproducable crashing linux-2.2.16
Date: 26 Jul 2000 07:37:59 GMT
Reply-To: [EMAIL PROTECTED]

[Posted and mailed]

In article <[EMAIL PROTECTED]>,
        [EMAIL PROTECTED] (Thomas Zajic) writes:
> On 25 Jul 2000 10:48:16 GMT, Martin Kahlert wrote:
> 
>> Could anybody check this (it would be best *not* to try it on a
>> production machine...)
>> [ ... ]
>> gcc -o crash crash.c
>> ./crash 30
> 
>    [zlatko@sphere]:~/tmp/scratch$ ./crash 30
>    Segmentation fault
> No crash, though. Kernel 2.2.16, gcc-2.95.2, glibc-2.1.2 (Slack 7.0).
Try 'ulimit -s unlimited' before.

Bye,
Martin.

PS: The segfault isn't a good thing either! If i get a pointer from alloca,
    i should be able to use the memory chunk - at least according to the
    manpage. (Otherwise allocae should return 0)

-- 
The early bird gets the worm. If you want something else for       
breakfast, get up later.

------------------------------

From: Graduate <[EMAIL PROTECTED]>
Subject: linux bridge support...
Date: 26 Jul 2000 07:39:25 GMT

In linux source tree net/bridge, we have some C programs.
According to page 378 in Rubini's book, Linux Device Driver, 
these files implement an optimized Ethernet bridging support 
according to IEEE spec.

Now, here is my problem, is there any exported interface that
ap or other system software must explicitly code to take
full use of the linux bridge layer, or the layer automatically
take care of everything that is transparent to upper 
layer?

Any reference to this?

Thanks for your time.

------------------------------

From: Daniel Etzold <[EMAIL PROTECTED]>
Subject: Re: request_irq problem
Date: Wed, 26 Jul 2000 11:14:49 +0200

It is interrupt 11 of a digital I/O card.


naveen gogineni wrote:

> What is the interrupt number that you are trying to handle ?
> Daniel Etzold wrote:
>
> > My system hangs whenever the INTERRUPT occurs.
> > Where is the problem?
> >
> > [...]
> > ret = request_irq(INTERRUPT, irq_handler, 0, "myirq", NULL);
> > [...]
> >
> > void irq_handler(int irq, void *dev_id, struct pt_regs *regs)
> > {
> >     // do nothing
> > }
> >
> > ------------------------------------------------
> > Daniel Etzold
> >
> >    ~
> >   � �
> >   /V\
> >  // \\
> > /(   )\
> >  ^`~'^

--

================================================
Daniel Etzold
([EMAIL PROTECTED] / [EMAIL PROTECTED])

FRMII +49 (0)89 / 289 14664

   ~
  � �
  /V\
 // \\
/(   )\
 ^`~'^




------------------------------

From: [EMAIL PROTECTED] (Thomas Zajic)
Subject: Re: Reproducable crashing linux-2.2.16
Reply-To: [EMAIL PROTECTED] (Thomas Zajic)
Date: Wed, 26 Jul 2000 09:38:08 GMT

On 26 Jul 2000 07:37:59 GMT, Martin Kahlert wrote:

> In article <[EMAIL PROTECTED]>,
>       [EMAIL PROTECTED] (Thomas Zajic) writes:
> > [ ... ]
> >    [zlatko@sphere]:~/tmp/scratch$ ./crash 30
> >    Segmentation fault
> > No crash, though. Kernel 2.2.16, gcc-2.95.2, glibc-2.1.2 (Slack 7.0).
>
> Try 'ulimit -s unlimited' before.

I did (after a /sbin/telinit 1, to be on the safe side :-). It ran for a
few seconds (I could still log in on a different VT in that time), then
started to spew

   VM: do_try_to_free_pages failed for crash...
   VM: do_try_to_free_pages failed for bash...
   VM: do_try_to_free_pages failed for kswapd...
   VM: do_try_to_free_pages failed for bash...
   VM: do_try_to_free_pages failed for crash...
   VM: do_try_to_free_pages failed for bash...
   VM: do_try_to_free_pages failed for kupdate...
   VM: do_try_to_free_pages failed for bash...
   VM: do_try_to_free_pages failed for crash...
   VM: do_try_to_free_pages failed for crash...
   VM: do_try_to_free_pages failed for bash...
   VM: do_try_to_free_pages failed for bash...
   VM: do_try_to_free_pages failed for crash...
   VM: do_try_to_free_pages failed for crash...
   VM: do_try_to_free_pages failed for bash...
   VM: do_try_to_free_pages failed for bash...
   VM: do_try_to_free_pages failed for init...
   VM: do_try_to_free_pages failed for init...

Still, no crash - I was able to switch back to the VT it was running on
and simply Ctrl-C it.

> PS: The segfault isn't a good thing either! If i get a pointer from
>     alloca, i should be able to use the memory chunk - at least
>     according to the manpage. (Otherwise allocae should return 0)

Well, agreed. Seems to be a memory overcommitment issue. Try to find
a machine that *really* has 1 GB of RAM (throw in some more MB for
good measure, just to be on the safe side :-) and see if it works
there. Did you try what happens with memory overcommitment turned off?

OTOH, /usr/src/linux/Documentation/sysctl/vm.txt suggests that the
overcommit mechanism only works for malloc(), so that could be the
reason why it fails for alloca(). Plus, memory overcommitment seems
to be turned off by default anyway (at least it is on my machine),
so it might not be related to this specific problem at all.

Thomas
-- 
=-------------------------------------------------------------------------=
-  Thomas "ZlatkO" Zajic   <[EMAIL PROTECTED]>    Linux-2.2.16/slrn-0.9.6.2+  -
-  "It is not easy to cut through a human head with a hacksaw."  (M. C.)  -
=-------------------------------------------------------------------------=

------------------------------

From: [EMAIL PROTECTED] (cLIeNUX user)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.hardware
Subject: Re: A good IDE
Date: 26 Jul 2000 10:41:46 GMT

[EMAIL PROTECTED] 
>cLIeNUX user ([EMAIL PROTECTED]) wrote:
>
>: The "IDE" feature I use the most is "+", which is supported by Pico and
>: the "most" pager. When gcc says 
>:      gcc:238:You_lose.c:  HAHAHAHHAHAHAHAA   You call that C?? HAHAHHA
>: I then do 
>:      pico +238 You_lose.c
>: and I'm Integrated and Developing in my Environment.
>
>: If "best" means "get the most work done", you just need to learn to use
>: what you've already got.
>
>Well, emacs can do that too.  Even better, you can do M-x compile,
>and C-x ` (that's a backquote) takes you to the next error in the
>output, opening files as necessary.

IFF your code is all set up right for emacs. Mine isn't. 

Rick Hohensee
[EMAIL PROTECTED]



>
>  ==Jake

------------------------------

From: [EMAIL PROTECTED]
Subject: /tmp/kfm_503* and /tmp/kio_503*
Date: Wed, 26 Jul 2000 11:15:40 GMT

Hi All

I thought, files placed in /tmp can be removed without any problem.
Currently I am not that sure anymore.

There are some directories with names like kfm_503* or kio_503*

I removed almost all files and directories in /tmp a couple of days ago,
and now some pprogramms have problems.

What kind of data are in these directories?

thx


Sent via Deja.com http://www.deja.com/
Before you buy.

------------------------------

From: peter katzmann <[EMAIL PROTECTED]>
Subject: Re: /tmp/kfm_503* and /tmp/kio_503*
Date: Wed, 26 Jul 2000 14:10:09 +0200
Reply-To: [EMAIL PROTECTED]

[EMAIL PROTECTED] wrote:
> 
> I thought, files placed in /tmp can be removed without any problem.
> Currently I am not that sure anymore.
> 
> There are some directories with names like kfm_503* or kio_503*
> 
> I removed almost all files and directories in /tmp a couple of days ago,
> and now some pprogramms have problems.
> 
> What kind of data are in these directories?
Sockets of running kde programms kfm -> kde file manager

------------------------------

From: [EMAIL PROTECTED] (Vreught)
Subject: problem with Soundblaster PCI 128 (OEM) & Suse 6.3
Date: 26 Jul 00 13:20:04 GMT

Hi, I have a problem with Soundblaster PCI 128 (OEM) & Suse 6.3. I can
compile the kernel and the modules without a problem but if I try to use
the /dev/dsp I can stuff like:

Jul 26 15:05:28 linux modprobe: modprobe: Can't locate module sound-slot-0
Jul 26 15:05:28 linux modprobe: modprobe: Can't locate module sound-service-0-3
Jul 26 15:05:28 linux modprobe: modprobe: Can't locate module sound-slot-1
Jul 26 15:05:28 linux modprobe: modprobe: Can't locate module sound-service-1-3
Jul 26 15:05:28 linux modprobe: modprobe: Can't locate module sound-slot-2
Jul 26 15:05:28 linux modprobe: modprobe: Can't locate module sound-service-2-3
Jul 26 15:05:28 linux modprobe: modprobe: Can't locate module sound-slot-3
Jul 26 15:05:28 linux modprobe: modprobe: Can't locate module sound-service-3-3

And still no sound... :-( Under NT 4.0 it works fine, but that is not what
I want to use at all.

What do I do wrong? Since my newsfeed is a bit shaky (there is more
news than that we can handle), please replay to me ([EMAIL PROTECTED] or
[EMAIL PROTECTED]; well replying should go OK).

Suse 6.3 runs Linux 2.2.13 on a pentium III 500 MHz with 128 MB.

crw-rw-rw-   1 root     audio     14,   3 Dec 15  1999 /dev/dsp

I've used make xconfig in in the sound section I've put:
CONFIG_SOUND=y
CONFIG_SOUND_OSS=y
CONFIG_SOUND_DMAP=y
CONFIG_SOUND_SB=m
CONFIG_SOUND_SOFTOSS=m
CONFIG_SOUND_YM3812=m
CONFIG_SOUND_VMIDI=m

I have compiled the kernel & the modules according the latest Kernel-HOWTO.
--
Hans de Vreught

------------------------------

From: =?iso-8859-1?Q?Rasmus_B=F8g_Hansen?= <[EMAIL PROTECTED]>
Subject: Re: problem with Soundblaster PCI 128 (OEM) & Suse 6.3
Date: Wed, 26 Jul 2000 15:41:20 +0200

On 26 Jul 2000, Vreught wrote:

> Hi, I have a problem with Soundblaster PCI 128 (OEM) & Suse 6.3. I can
> compile the kernel and the modules without a problem but if I try to use
> the /dev/dsp I can stuff like:
> 
> Jul 26 15:05:28 linux modprobe: modprobe: Can't locate module sound-slot-0
> Jul 26 15:05:28 linux modprobe: modprobe: Can't locate module sound-service-0-3
> Jul 26 15:05:28 linux modprobe: modprobe: Can't locate module sound-slot-1
> Jul 26 15:05:28 linux modprobe: modprobe: Can't locate module sound-service-1-3
> Jul 26 15:05:28 linux modprobe: modprobe: Can't locate module sound-slot-2
> Jul 26 15:05:28 linux modprobe: modprobe: Can't locate module sound-service-2-3
> Jul 26 15:05:28 linux modprobe: modprobe: Can't locate module sound-slot-3
> Jul 26 15:05:28 linux modprobe: modprobe: Can't locate module sound-service-3-3
> 
> And still no sound... :-( Under NT 4.0 it works fine, but that is not what
> I want to use at all.
> 
> What do I do wrong? Since my newsfeed is a bit shaky (there is more
> news than that we can handle), please replay to me ([EMAIL PROTECTED] or
> [EMAIL PROTECTED]; well replying should go OK).
> 
> Suse 6.3 runs Linux 2.2.13 on a pentium III 500 MHz with 128 MB.
> 
> crw-rw-rw-   1 root     audio     14,   3 Dec 15  1999 /dev/dsp
> 
> I've used make xconfig in in the sound section I've put:
> CONFIG_SOUND=y
> CONFIG_SOUND_OSS=y
> CONFIG_SOUND_DMAP=y
> CONFIG_SOUND_SB=m
> CONFIG_SOUND_SOFTOSS=m
> CONFIG_SOUND_YM3812=m
> CONFIG_SOUND_VMIDI=m
> 
> I have compiled the kernel & the modules according the latest Kernel-HOWTO.
> --
> Hans de Vreught

Oops. What you really want is the Ensoniq audioPCI 1371 driver, which is
the chip on SB PCI 128 (on a few cards I think it is the 1370 chip?) and
not the sb module, which is for SB 16/PRO/AWE32.

So you should instead compile the es1371 module (or 1370?) and put:

alias char-major-14 es1371

in your /etc/modules.conf (or perhaps /etc/conf.modules).

Rasmus B�g Hansen


------------------------------

From: Thomas Dickey <[EMAIL PROTECTED]>
Subject: Re: where is "clear" source??
Date: 26 Jul 2000 13:56:01 GMT

Zirong Wang <[EMAIL PROTECTED]> wrote:
> Hi dan,

> try printf(stdout, "\033\143");

resetting the terminal is a bad idea (a real vt100 would disconnect)

-- 
Thomas E. Dickey <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
http://dickey.his.com
ftp://dickey.his.com

------------------------------

From: [EMAIL PROTECTED]
Subject: Problems with gdb and threads
Date: Wed, 26 Jul 2000 13:57:10 GMT

Hi all

Just wondering...has anyone out there had lots of problems trying to use
gdb in an application which is multi-threaded and running on a
multi-processor system?

I am running RH 6.1 on a dual 733 mhz Dell Precision 220 workstation. I
have been having loads of trouble getting gdb to work properly...or
sometimes even to work at all!

I have a simple application that creates a user specified number of
threads, each of which does nothing but execute a
pthread_cond_timedwait for a few seconds.

When I run this program without gdb, everything works
fine... output looks like:

Creating new team base with 3 threads
Thread 0 awoke. rc is ETIMEDOUT( 110 )
Thread 0 awoke. rc is ETIMEDOUT( 110 )
Thread 1 awoke. rc is ETIMEDOUT( 110 )
Thread 0 awoke. rc is ETIMEDOUT( 110 )
Thread 2 awoke. rc is ETIMEDOUT( 110 )
Thread 0 awoke. rc is ETIMEDOUT( 110 )
Thread 1 awoke. rc is ETIMEDOUT( 110 )
Thread 0 awoke. rc is ETIMEDOUT( 110 )
Thread 0 awoke. rc is ETIMEDOUT( 110 )
Thread 1 awoke. rc is ETIMEDOUT( 110 )
Thread 2 awoke. rc is ETIMEDOUT( 110 )
Thread 0 awoke. rc is ETIMEDOUT( 110 )
Thread 0 awoke. rc is ETIMEDOUT( 110 )
Thread 1 awoke. rc is ETIMEDOUT( 110 )
Thread 0 awoke. rc is ETIMEDOUT( 110 )
Thread 2 awoke. rc is ETIMEDOUT( 110 )

so the kernel seems to be behaving properly. But if I try to run
this application under gdb, the results
vary...on one run I saw:

Creating new team base with 3 threads
[New Thread 16254 (manager thread)]
[New Thread 16253 (initial thread)]
[New Thread 16255]
[New Thread 16256]
Thread 0 awoke. rc is EINTR( 4 )
Thread 0 awoke. rc is EINTR( 4 )
[New Thread 16257]
Thread 0 awoke. rc is EINTR( 4 )
Thread 1 awoke. rc is EINTR( 4 )
Thread 0 awoke. rc is EINTR( 4 )
Thread 1 awoke. rc is EINTR( 4 )
Thread 1 awoke. rc is EINTR( 4 )

at this point, the system was hung.

Running with 4 threads I often see:

Creating new team base with 4 threads
[New Thread 16261 (manager thread)]
[New Thread 16260 (initial thread)]
[New Thread 16262]
[New Thread 16263]
Thread 0 awoke. rc is EINTR( 4 )
[New Thread 16264]
Thread 0 awoke. rc is EINTR( 4 )
[New Thread 16265]
Thread 1 awoke. rc is EINTR( 4 )
[Switching to Thread 16264]

Program received signal SIGSEGV, Segmentation fault.
__pthread_unlock (lock=0x804fd40) at spinlock.c:84
84      spinlock.c: No such file or directory.
Current language:  auto; currently c

NOTE the EINTR return code from the pthread_cond_timedwait. This was the
problem I was originally trying to track down.

When I run this program with the single processor kernel instead of the
smp kernel,
I still see the occasional EINTR return code from the
pthread_cond_timedwait,
but not the crashes as above.

Anyone know anything about this problem?

Any info appreciated.

Ed Friedman







Sent via Deja.com http://www.deja.com/
Before you buy.

------------------------------

From: Cyrille Artho <[EMAIL PROTECTED]>
Subject: ioctl porting problem (works under Solaris)
Date: Wed, 26 Jul 2000 16:43:52 +0200

This is a multi-part message in MIME format.
==============AD23CC3B481688C8BC68AA1B
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

My problem is that I want to use a
ioctl(outPipe, I_SRDOPT, RMSGD)
call on a named pipe, but Linux returns an error 22 (EINVAL). The ioctl
call is present in the /usr/include/stropts.h list, but it does not
work.

This means that (if I choose to ignore the error), when I write 2*n
bytes to a named pipe, the message boundaries are not preserved under
Linux. If I subsequently read from the pipe, I get 2*n bytes in one
message rather than n + n bytes in two messages.
I have attached a small test program which was compiled under:
Linux linux1 2.2.14-SMP #1 SMP Mon Mar 13 10:50:23 GMT 2000 i686 unknown
with
gcc pipetest.c -o pipetest
gcc version 2.95.2 19991024 (release)

Run under Solaris, it works like this:
% ./pipetest
^Z
[1]+  Stopped                 ./pipetest
% echo foo >/tmp/testpipe
% echo bar >/tmp/testpipe
% fg
./pipetest
Read 3 bytes.
foo
Read 1 bytes.


Read 3 bytes.
bar
Read 1 bytes.


^C
As you can see, there are four messages (because echo seems to write the
final \n in a new message). Under Linux, I get:
% ./pipetest
Error in I_SRDOPT call: 22.
Error in I_FLUSH call: 22.

[1]+  Stopped                 ./pipetest
% echo foo >/tmp/testpipe
% echo bar >/tmp/testpipe
% fg
Read 8 bytes.
foo
bar

^C
As you can see, Linux merges the four messages (possibly there are only
two if echo works differently) into one.
--
Regards,
Cyrille Artho - http://artho.com
A classic is something that everyone wants to have read
and nobody wants to read.
                -- Mark Twain, "The Disappearance of Literature"
==============AD23CC3B481688C8BC68AA1B
Content-Type: text/plain; charset=us-ascii;
 name="pipetest.c"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="pipetest.c"

#include <assert.h>
#include <stdio.h>
#include <sys/stat.h>
#include <sys/fcntl.h>
#include <stropts.h>
#include <errno.h>

int main() {
   int outPipe, inPipe;
   
   const char* path = "/tmp/testpipe";
   char inbuf[65];
   int n;

   unlink(path);
   if (mkfifo(path, S_IFIFO | 0666) == -1) {   
      exit(errno);
   }

   chmod(path, 0666);                   
                                        
   outPipe = open(path, O_RDWR);                

   if (outPipe == -1) {
      fprintf(stderr, "Could not create pipe %s.\n", path);
      exit();
   }

   if (ioctl(outPipe, I_SRDOPT, RMSGD) == -1) { 
      fprintf(stderr, "Error in I_SRDOPT call: %d.\n", errno);
   }
  
   if (ioctl(outPipe, I_FLUSH, FLUSHRW) == -1) { 
      fprintf(stderr, "Error in I_FLUSH call: %d.\n", errno);
   }

   inPipe = open(path, O_RDONLY);

   while (n = read(inPipe, inbuf, sizeof(inbuf)-1)) {
      printf("Read %d bytes.\n", n);
      inbuf[n] = '\0';
      printf("%s\n", inbuf);
   }
}

==============AD23CC3B481688C8BC68AA1B==


------------------------------

From: Frank Haverkamp <[EMAIL PROTECTED]>
Subject: Re: request_irq problem
Date: Wed, 26 Jul 2000 18:11:11 +0200

Hi,

did you try to disable the interrupt in the interrupt service
routine? I had the case where when I did not handle the interrupt
source the isr was called ever and ever again. The result was
that my system crashed. Then I disabled the interrupt writing some
value to the interrupt control register, like I did enabling it,
and I had the chance to debug my program.

Frank

> > > My system hangs whenever the INTERRUPT occurs.
> > > Where is the problem?
> > >
> > > [...]
> > > ret = request_irq(INTERRUPT, irq_handler, 0, "myirq", NULL);
> > > [...]
> > >
> > > void irq_handler(int irq, void *dev_id, struct pt_regs *regs)
> > > {
> > >     // do nothing
> > > }

------------------------------

From: [EMAIL PROTECTED] (Grant Edwards)
Subject: Re: TCP/IP
Date: Wed, 26 Jul 2000 15:29:32 GMT

In article <[EMAIL PROTECTED]>, Amit Utreja wrote:

>I want to trace TCP/IP header on Linux Machine, to extract both TCP and
>IP header from the packet received by the kernel. How should i proceed?
>Is there any source or software available to read TCP/IP headers ?
>Thanks in advance.

          library: libpcap
     command line: tcpdump
          X11 app: ethereal

-- 
Grant Edwards                   grante             Yow!  My nose feels like a
                                  at               bad Ronald Reagan movie...
                               visi.com            

------------------------------

From: Bryan Hackney <[EMAIL PROTECTED]>
Subject: Re: Problems with gdb and threads
Date: Wed, 26 Jul 2000 11:09:04 -0500

[EMAIL PROTECTED] wrote:
> 
> Hi all
> 
> Just wondering...has anyone out there had lots of problems trying to use
> gdb in an application which is multi-threaded and running on a
> multi-processor system?
> 

Or uni-processor system. Make sure to use gdb 5.x. 4.17 has problems
with threads.


-- 
                                 Bryan Hackney / BHC / [EMAIL PROTECTED]
                                        http://www.FreeClassAds.com/
                                        http://bhconsult.com/
                                        http://bhconsult.com/bh/pgp.key

------------------------------


** 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
******************************

Reply via email to