[linrad] Re: Linrad-02.05

[Leif Asbrink <sm5bsz.com; leif@xxxxxxxxxxxxxxxx>]

Hi Ramiro and Bob,

------------------------------------
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 1145924528 (LWP 6020)]
> 0x080a7bb1 in rx_output ()
> (gdb) where
> #0  0x080a7bb1 in rx_output ()
> #1  0x00000000 in ?? ()
> (gdb) Quit
> (gdb)
------------------------------------
> 
> If I can produce this bug in Xlinrad, I will attempt to use valgrind to 
> locate the error. It might NOT work with this code because of the hand 
> tuned assembly but I will try.
------------------------------------
The routine rx_output is a small simple routine in straight C code.
It does however call some system functions as listed below.
I would think the problem is caused by interrupts not being
correctly separated when happening too frequently.
That would cause ioctl or write to D/A to cause an error.
It could also be a problem related to the Linrad error
handling which still to some extent has 'memories' of
being parts of a simple single threaded structure. If that
is the problem, the dumpfile (see 11 below) will clearly
show it.

On my Pentium 4 computer I can not use the builtin AC97
soundcard since I added a card for USB (the builtin USB 
never worked correctly). I had to add PCI card to get
the system going again. (Without the new USB card, the AC97
was fine)

Her is a list of what routines rx_output makes calls to with 
some short notes what these routines do:

1) current_time() (xsys.c) which returns gettimeofday as a double.
2) lir_get_cpu_time() (xsys.c) which returns time from getrusage 
    as a double. This function is called only for 2.4.xx kernels 
    (see kernver.c) that give CPU load for individual threads. 
    (Very good to have this info sometimes)
3) lir_output_bytes() (lsetad.c) just reports the ioctl result for
   how much empty space there is in the output buffer.
4) make_timing_info() (timing.c) is an internal Linrad routine
   that adds up the amount of data (converted to time) there is
   in each processing buffer. This routine should be very safe.
5) sprintf()
6) lir_text() (xsys.c) This routine transfers font images to
   the internal buffer of Linrad. The buffer content is transferred
   to X11 by another thread at a rate of about 10 Hz to the extent
   that the buffer content is changed.
7) lir_sem_wait() (xsys.c) just calls sem_wait()
8) lir_hline() (xsys.c) puts pixels into the internal buffer of 
    Linrad.
9)  close_rx_sndout() Complicated, but only called when the user
    has changed the output no of channels or word length.
10) open_rx_sndout() Complicated, but only called when the user
    has changed the output no of channels or word length.
11) lirerr(); (xsys.c) Called from various places. It will kill 
    all threads and could lead to unexpected results. There is a 
    tool for tracking it: Set DUMPFILE to 1 in vernr.h and check
    the file "dmp" that xlinrad creates. A call to lirerr will
    be visible.
12) lir_empty_da_device_buffer(); (lsetad.c) This routine issues
    a reset command through ioctl, or if the user asked for it,
    it closes the device and opens it again.
13) lir_dawrite() (lsetad.c) This routine uses ioctl to see
    if there is space in the buffer. It may wait through
    lir_sleep()=usleep() ant finally it makes a write to
    the D/A.
    

I am right now downloading Debian Sarge to try to reproduce
the bug. It might be related to ALSA and I have no idea how
ALSA might differ to Debian Etch.

73

  Leif / SM5BSZ

#############################################################
This message is sent to you because you are subscribed to
  the mailing list <linrad@xxxxxxxxxxxxxxxxxxxxx>.
To unsubscribe, E-mail to: <linrad-off@xxxxxxxxxxxxxxxxxxxxx>
To switch to the DIGEST mode, E-mail to <linrad-digest@xxxxxxxxxxxxxxxxxxxxx>
To switch to the INDEX mode, E-mail to <linrad-index@xxxxxxxxxxxxxxxxxxxxx>
Send administrative queries to  <linrad-request@xxxxxxxxxxxxxxxxxxxxx>


LINRADDARNIL