[Top][All Lists]
[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: |
Mon, 02 Apr 2012 09:43:42 -0700 |
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 04/02/2012 09:27 AM, Stefan Ott wrote:
> Hey
>
> Just curious, have you had a chance to look at this?
>
> Also, in the meantime I tried using your kernel tree
> (e100-3.0-pm-2-fixes-from-review) which seems to have a newer version
> of the usrp_e driver, built with the kernel configuration that I took
> from a working USRP image. However, when trying to modprobe the usrp-e
> module, I get:
That branch is not done yet :)
I just updated github to match the current shipping kernel (from last
week) See the e100-3.0-pm-2-bugfixes branch. In particular, I added some
code to do some range checking on the values passed to the ioctl in:
https://github.com/balister/linux-omap-philip/commit/057c170c1bae5f036c9b37838405b9d1d773ab84
Philip
>
> usrp_e entering driver initialization
> Unable to handle kernel NULL pointer dereference at virtual address 0000003c
> pgd = c9554000
> [0000003c] *pgd=9f843831, *pte=00000000, *ppte=00000000
> Internal error: Oops: 817 [#1]
> Modules linked in: usrp_e(+)
> CPU: 0 Not tainted (3.0.0 #1)
> PC is at usrp_e_init+0x84/0x1c4 [usrp_e]
> LR is at usrp_e_init+0x84/0x1c4 [usrp_e]
> pc : [<bf004084>] lr : [<bf004084>] psr: 60000013
> sp : c954deb0 ip : 00000000 fp : 00000000
> r10: 0000001c r9 : 00000024 r8 : 00000001
> r7 : bf001a38 r6 : bf001b70 r5 : 00000000 r4 : 00000000
> r3 : 00000000 r2 : c954dea4 r1 : bf001914 r0 : 0000000b
> Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
> Control: 10c5387d Table: 89554019 DAC: 00000015
> Process modprobe (pid: 57, stack limit = 0xc954c2f0)
> Stack: (0xc954deb0 to 0xc954e000)
> dea0: bf004000 00000000 00000000 bf001a38
> dec0: bf004000 00000000 c94e6680 c003737c c0569858 00000001 bf001a38 bf001a38
> dee0: 00000001 bf001a38 00000001 bf001a80 c94e6680 00000001 00000024 c0088550
> df00: bf001a44 000203c0 0065f11c 00000124 c0086288 c03c70bc bf001b5c 0065b018
> df20: c943bc28 e08ae000 000246d5 e08c7aac e08c7891 e08d20cc c94950c0 00001b84
> df40: 000020e4 00000000 00000000 00000032 00000033 0000001c 00000019 00000017
> df60: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 c0511494
> df80: 00000000 401955b0 00000000 00000000 00000080 c003c484 c954c000 00000000
> dfa0: 0065b018 c003c300 401955b0 00000000 401bc008 000246d5 0065b018 bebf89e4
> dfc0: 401955b0 00000000 00000000 00000080 00016f50 000203c0 0065f11c 0065b018
> dfe0: 40143cd8 bebf89e4 0000c25c 40143ce8 20000010 401bc008 e1a06007 1afffff7
> [<bf004084>] (usrp_e_init+0x84/0x1c4 [usrp_e]) from [<c003737c>]
> (do_one_initca)
> [<c003737c>] (do_one_initcall+0x90/0x160) from [<c0088550>]
> (sys_init_module+0x)
> [<c0088550>] (sys_init_module+0x1628/0x181c) from [<c003c300>]
> (ret_fast_syscal)
> Code: eb48b539 e5860010 e59f011c eb4ee213 (e584503c)
> ---[ end trace 784c802e29369acf ]---
> Segmentation fault
>
> This seems to happen in usrp_e.c on line 854: atomic_set(&p->mapped,
> 0); - I assume that, for some reason, "p" isn't properly initialized.
> You wouldn't by any chance have some idea about what might be wrong
> there?
>
> Furthermore, sorry for the nagging :)
>
> cheers