[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] PCI-DAS4020/12 problem roundup

From: Eric Blossom
Subject: Re: [Discuss-gnuradio] PCI-DAS4020/12 problem roundup
Date: Fri, 20 Jun 2003 19:22:44 -0700
User-agent: Mutt/1.4i

On Fri, Jun 20, 2003 at 11:06:41AM -0500, Steven Franke wrote:
> I tried Sergio's patch also.  I believe that the reason that the graphs 
> displayed zero signal is because Sergio changed the ADC channel from 3 
> to 0 in his code (or vice versa, I forget!).  His approach does prevent 
> the lockups, provided one is willing to let the program fall through 
> the main loop eventually so that it calls the destructor. It would be 
> even more useful if someone can provide a clue for incorporating his 
> fix so that the desructor is called after hitting the "Quit" button on 
> the displayed GUI panel.
> In a correspondence with Eric, we noticed that when I compiled the 0.7 
> driver I received more compilation errors than he does.  This is 
> apparently because I used the prerelease version of gcc 3.3 in the SuSE 
> 8.2 distribution.  Perhaps this is a clue?

Is every one who's having the problem running gcc 3.3?

If so, perhaps trying gcc 3.2.2 would be worth a shot.

Building gcc is no big deal (from memory)

     ./configure --prefix=/some/path
     make install


Then make clean && ./configure && make install the driver

Can one of you folks who's having the problem, reproduce this outside
of the GNU Radio framework.  E.g., using test-adc or mc4020-read-adc?
It'll remove one layer of hair in tracking down the problem.

It may be that there is some kind of an interaction between killing
the process, releasing the memory and closing the driver.

A few well placed printk's in the driver might shed some light.
Try mc4020_open, mc4020_release, free_buffer.  Also, I suggest 
#defining VERBOSE_DEBUG to 1 then watching /var/log/kernel/* or
where ever /etc/syslog.conf directs kernel debugging output

Try to figure out what's different between the working and the
non-working cases.  Where does the flow of control differ?
That'll help track down the problem.

You may want to watch your memory and swap usage between runs with

   $ cat /proc/meminfo

Perhaps we're still leaking memory when exiting via the non-normal
path.  One odd thing is that I don't see the problem with either of my
two machines.  FWIW, they're both running Mandrake 9.0 with
2.4.19-16mdk kernels.

This is the output of make on my system...

address@hidden mc4020]$ gcc --version
gcc (GCC) 3.2 (Mandrake Linux 9.0 3.2-1mdk)
Copyright (C) 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
address@hidden mc4020]$ make 2>&1 | tee make.log
for dir in kernel user; do make  -C $dir all; done
make[1]: Entering directory `/home/eb/mc4020/kernel'
gcc -DMODULE=1 -I/include -I/lib/modules/2.4.19-16mdk/build/include -O2 
-mpreferred-stack-boundary=2 -march=i586 -DLINUX -Wall -Wstrict-prototypes 
-fomit-frame-pointer -pipe -DMC4020_BUILD -D__KERNEL__   -c -o mc4020.o mc4020.c
mc4020.c:1970: warning: `dump_plx_regs' defined but not used
mc4020.c:1980: warning: `dump_regs' defined but not used
make[1]: Leaving directory `/home/eb/mc4020/kernel'
make[1]: Entering directory `/home/eb/mc4020/user'
gcc -I../kernel -O2 -g -Wall    mc4020-read-adc.c   -o mc4020-read-adc
gcc -I../kernel -O2 -g -Wall    mc4020-set-dac.c   -o mc4020-set-dac
gcc -I../kernel -O2 -g -Wall    test-get-cal-data.c   -o test-get-cal-data
g++ -I../kernel -O2 -g -Wall    test-adc.cc   -o test-adc
make[1]: Leaving directory `/home/eb/mc4020/user'

I also tried a Mandrake 9.1 system with a 2.4.21-rc7-ac1 kernel and
gcc 3.2.2. The output from the compilation was the same.  It's
a laptop, so there's no way to actually see if the driver was working.

Please keep me posted.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]