On Thu, Apr 14, 2005 at 10:08:27PM +0200, Harald Welte wrote:
> Hi!
>
> When running the 'test_usrp_standard_rx' or _tx programs contained in
> the usrp-0.8 tarball, I get
>
> [EMAIL PROTECTED]/7 (21:54) 2.5/usrp-0.8/host/apps > ./test_usrp_standard_rx
> RX d'board A: Basic Rx
> RX d'board B: TV Rx
> fusb::pending_remove: failed to find urb in pending_rqsts: (nil)
> zsh: 10309 segmentation fault ./test_usrp_standard_rx
>
> This is on a dual opteron 246, running debian-amd64 and a vanilla
> 2.6.12-rc2 kernel.
>
> strace'ing the program, I get the following last lines:
>
> ioctl(3, USBDEVFS_SUBMITURB, 0xd1c940) = 0
> ioctl(3, USBDEVFS_CONTROL, 0x7fffff800630) = 0
> ioctl(3, USBDEVFS_CONTROL, 0x7fffff800670) = 4
> getrusage(RUSAGE_SELF, {ru_utime={0, 6998}, ru_stime={0, 8998}, ...}) = 0
> ioctl(3, USBDEVFS_REAPURBNDELAY, 0x7fffff7fc630) = -1 EAGAIN (Resource
> temporarily unavailable)
> ioctl(3, USBDEVFS_REAPURB, 0x7fffff7fc630) = 0
> write(2, "fusb::pending_remove: failed to "..., 65fusb::pending_remove:
> failed to find urb in pending_rqsts: (nil)) = 65
>
> So it seems like the REAPURB ioctl returns a NULL-pointer and aborts.
>
> Does anyone have an idea what's going on?
Haven't seen this before.
Take a look in fusb_linux.cc at the _reap method.
There are only two calls to pending_remove. Try printing out the urb
passed to pending_remove when it prints the message. Perhaps the urb
is not a valid pointer. Also, use gdb to see exactly where it's
segfaulting.
For tips on using gdb to debug gnuradio see
http://www.gnu.org/software/gnuradio/doc/howto-write-a-block.html#debugging
Once it segfaults you'll want to try the "bt" backtrace command.
Eric
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
