[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
make install
PATH=/some/path/bin:$PATH
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
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
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.
Eric