discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] Segfault


From: Philip Balister
Subject: Re: [Discuss-gnuradio] Segfault
Date: Wed, 14 Mar 2012 15:51:20 -0400
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16

On 03/14/2012 01:42 PM, Stefan Ott wrote:
> Hey list
> 
> I managed to build gnuradio 3.5.1 and (almost) got it working on the
> USRP E110. However, when I try to run uhd_rx_cfile.py (with
> --samp-rate 10e6 -f 97.7e6) it segfaults. You will find the log below.
> 
> The system that I'm running on the USRP has been compiled from scratch
> and is using Linux 3.1.10 with the USRP driver from
> https://github.com/balister/linux-omap-philip/commit/9c409f8e4aad357b09c
> with uClibc 0.9.32 and AFAICT the latest versions of all the gnuradio
> dependencies.
> 
> Does anyone have a clue about what I might be doing wrong?

Besides completely voiding the warranty :) :) :)  <- Note smileys, I
actually enjoy people doing crazy stuff.

When you say Linux 3.1.0, is that mainline?

If you do want to update your kernel to something more recent, try
starting from here:

http://www.sakoman.com/cgi-bin/gitweb.cgi?p=linux-omap-2.6.git;a=shortlog;h=refs/heads/omap-3.2

Finally, there are docs on the web for working out where in the code the
oops really occurs. Can you try working through that procedure and see
if it happens in the driver, or elsewhere.

Philip

> 
> 
> ---------- dmesg ----------
> usrp_e open called, use_count = 0
> rx_dma->ch 0
> tx_dma->ch 1
> usrp: leaving open
> Unable to handle kernel NULL pointer dereference at virtual address 000004fc
> pgd = c3440000
> [000004fc] *pgd=86c88831, *pte=00000000, *ppte=00000000
> Internal error: Oops: 817 [#2]
> Modules linked in:
> CPU: 0    Tainted: G      D      (3.1.10 #1)
> pc : [<c01392c0>]    lr : [<401d137c>]    psr: 80000013
> sp : c4fdbeb0  ip : 00000000  fp : c4fdbef4
> r10: 00000000  r9 : c4fda000  r8 : c000d9c4
> r7 : dc490ac0  r6 : 00000003  r5 : 00000001  r4 : be9fbfd0
> r3 : c4fdbeb8  r2 : c0342bd0  r1 : 000004fc  r0 : 00000000
> Flags: Nzcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
> Control: 10c5387d  Table: 83440019  DAC: 00000015
> Process python (pid: 1595, stack limit = 0xc4fda2e8)
> Stack: (0xc4fdbeb0 to 0xc4fdc000)
> bea0:                                     000004fc 00000001 00000000 0032e9c8
> bec0: 00000028 401bb7e4 00329dc0 00000011 42156824 00021a20 401048b4 401d137c
> bee0: c6d12228 be9fbfd0 c4fdbf04 c4fdbef8 c01393f8 c0139224 c4fdbf7c c4fdbf08
> bf00: c0090afc c0139378 40908178 003371c8 c03123b0 c4fda000 c4fda000 00000000
> bf20: ffffffff 00000000 c4fdbf5c c4fdbf38 c0046f68 c0008c60 ffffffff df8a801c
> bf40: df861140 c6d990c0 c03123b0 c4fda000 c4fdbf74 c4fdbf60 00000003 40307522
> bf60: be9fbfd0 dc490ac0 c000d9c4 c4fda000 c4fdbfa4 c4fdbf80 c0090bb0 c0090658
> bf80: 003371c8 00000000 be9fbfd0 40307522 00000003 00000036 00000000 c4fdbfa8
> bfa0: c000d840 c0090b7c be9fbfd0 40307522 00000003 40307522 be9fbfd0 00000000
> bfc0: be9fbfd0 40307522 00000003 00000036 be9fd88c 0032e8f0 4219f660 be9fd500
> bfe0: 4219f938 be9fbe98 420ef69c 40180b9c 60000010 00000003 6d726f66 0228745f
> Backtrace:
> Function entered at [<c0139218>] from [<c01393f8>]
>  r5:be9fbfd0 r4:c6d12228
> Function entered at [<c013936c>] from [<c0090afc>]
> Function entered at [<c009064c>] from [<c0090bb0>]
>  r9:c4fda000 r8:c000d9c4 r7:dc490ac0 r6:be9fbfd0 r5:40307522
> r4:00000003
> Function entered at [<c0090b70>] from [<c000d840>]
>  r7:00000036 r6:00000003 r5:40307522 r4:be9fbfd0
> Code: e5b3c004 e5900048 e0811105 e2855001 (e780c001)
> ---[ end trace 689a22803bf4f530 ]---
> usrp_e release called
> Waiting for DMA to become inactive
> Freeing gpio irq's
> Freeing DMA channels
> ---------- end ----------
> 
> 
> cheers



reply via email to

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