On Thu, Nov 05, 2015 at 12:52:25PM -0500, Lennart Sorensen wrote:
> On Thu, Nov 05, 2015 at 12:24:52PM -0500, Lennart Sorensen wrote:
> > On Thu, Nov 05, 2015 at 06:14:19PM +0100, Gilles Chanteperdrix wrote:
> > > On Thu, Nov 05, 2015 at 11:57:50AM -0500, Lennart Sorensen wrote:
> > > > On Thu, Nov 05, 2015 at 05:25:14PM +0100, Gilles Chanteperdrix wrote:
> > > > > I am sure. Xenomai does not use H_DMA on armv7, so, it is not used
> > > > > if your code, it is not used at all.
> > > >
> > > > Well we are using it for one allocation for talking to a network port.
> > > >
> > > > If I remove it, I get a NULL pointer dereference, so it clearly matters
> > > > to something in our code.
> > > >
> > > > > > It does appear that when LPAE is enabled H_DMA does do something on
> > > > > > arm,
> > > > > > but only when LPAE is enabled since that enables ZONE_DMA.
> > > > >
> > > > > I never said that H_DMA did nothing.
> > > >
> > > > OK I misunderstood then.
> > > >
> > > > Setting /proc/cpu/alignment to 0 gives the kernel message:
> > > > alignment: ignoring faults is unsafe on this CPU. Defaulting to fixup
> > > > mode.
> > > >
> > > > Apparently armv6+ with CR_U set is not allowed to turn off fixups.
> > >
> > > If you have an armv7, you want to turn off all armv6 processors in
> > > the kernel configuration so that the kernel does not try to be
> > > compatible with these obsolete processors.
> >
> > I thought I had. Maybe not quite:
> >
> > # CONFIG_ARCH_MULTI_V6 is not set
> > CONFIG_ARCH_MULTI_V7=y
> > CONFIG_ARCH_MULTI_V6_V7=y
> >
> > I wonder if I can turn off CONFIG_ARCH_MULTI_V6_V7 somehow, not that I
> > see anything in the kernel code that would change beecause of it.
> > Of course LPAE being on pretty much also excludes ARMv6 support.
> >
> > Certainly as far as I can tell, on any armv6+ with CR_U set (which all
> > armv7 have hardwired), CR_A appears to always be cleared by the kernel, so
> > I don't think it is causing the issue.
> >
> > I think our problem is that we have allocated some memory that isn't
> > considered normal and hence isn't allowed unaligned accesses and with
> > gcc-4.6 that wasn't a problem, but with 4.9 it is (since it now does
> > generate unaligned accesses by default)
> >
> > I just have to figure out why there was any reason to allocate 'weird'
> > memory. I can't figure out why that would have been neccesary, but I
> > didn't write that code. I am just trying to fix it.
>
> So when I change the one allocation from H_DMA to H_NONCACHED I get:
>
> [ 55.340237] rcksapi: DTB node=int_sm_sw, physical slot number=0, virtual
> IRQ=245
> [ 55.395419] Unable to handle kernel NULL pointer dereference at virtual
> address 00000002
> [ 55.411662] pgd = eded4ec0, hw pgd = eded4ec0
> [ 55.420397] [00000002] *pgd=adde8003, *pmd=add49003, *pte=00000000
> [ 55.432824] Internal error: Oops: 207 [#1] SMP ARM
> [ 55.442431] Modules linked in: ebtable_filter ebtables ip6table_filter
> ip6_tables 8021q garp stp mrp llc l2tp_ip6 l2tp_ip l2tp_eth l2tp_netlink
> ip_gre ip_tunnel gre l2tp_core macvlan mpls ti_pru_eth rcksapi_layer2(O)
> xhci_plat_hcd xhci_hcd iptable_nat nf_conntrack_ipv4
> nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack dummy xeno_posix xeno_rtdm
> xeno_native dwc3 max6369_wdt phy_ti_pipe3 phy_omap_usb2 omap_aes_driver
> dwc3_omap at24 omap_des lm75 iptable_filter ip_tables x_tables
> [ 55.527108] CPU: 0 PID: 2944 Comm: StartTask Tainted: G O
> 3.14-2-am5726 #1 Debian 3.14.56-0.1RR1
> [ 55.546483] task: ee9a3200 ti: edece000 task.ti: edece000
> [ 55.557325] PC is at get_free_range+0x60/0x1a8
> [ 55.566234] LR is at xnheap_alloc+0x4a4/0x538
> [ 55.574971] pc : [<c00f2d78>] lr : [<c00f47ec>] psr: 200d0093
> [ 55.574971] sp : edecfdd8 ip : 00000002 fp : 00000002
> [ 55.598008] r10: ef4a9d00 r9 : 00000ffe r8 : 00000000
> [ 55.608485] r7 : 00001000 r6 : 00000002 r5 : f2051e30 r4 : ffff0f00
> [ 55.621578] r3 : 00001002 r2 : 00000002 r1 : 0004c000 r0 : f2051e30
> [ 55.634675] Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment
> user
> [ 55.649163] Control: 30c5387d Table: aded4ec0 DAC: fffffffd
> [ 55.660687] Process StartTask (pid: 2944, stack limit = 0xedece240)
> [ 55.673258] Stack: (0xedecfdd8 to 0xeded0000)
> [ 55.681992] fdc0:
> f2051e54 00000000
> [ 55.698402] fde0: ffff0f00 f2051e30 c0793cc0 c073eb1c 00000001 f2051e60
> 15e6a4da 00000000
> [ 55.714812] fe00: eeb1e000 00000002 ee259c00 c04ae6fc 00000000 0000119c
> 0004c000 c0730cd8
> [ 55.731223] fe20: 15e6a4da 00000000 eefb5b38 eeb14500 c073eb1c c0756160
> c0793cc0 c073eb1c
> [ 55.747633] fe40: 00000003 00000000 f2051e00 0004b900 00000000 bf099660
> 00000001 eefb9a80
> [ 55.764043] fe60: c010b03c c0733a80 e5d24aa6 0000000c c0733a80 c0731ecc
> c073e5d4 c0793cc0
> [ 55.780453] fe80: ffffffff ffffffff 00208040 f2051e00 00000000 00000000
> edecffb0 edece030
> [ 55.796864] fea0: c0793cc0 c0756160 00000000 bf084d90 edecfeec c04ac3a8
> 000099ca c007b794
> [ 55.813274] fec0: 00000000 2e886000 00000135 00000000 ffff0f00 c073eb1c
> ee9a3200 c08121fc
> [ 55.829683] fee0: 00000001 00000000 00000000 00000000 ffffffff ffffffff
> ee259c38 00000083
> [ 55.846093] ff00: f2051e30 b56e4000 00095000 f0abb000 b56e4000 00000022
> 00000001 edecffb0
> [ 55.862504] ff20: 00000218 c0812220 c08121fc f2041a10 edece038 c010b318
> c010b268 00001198
> [ 55.878912] ff40: 00000000 c07bbcc0 c072fb38 c0793cc0 c0731e78 c07bbcc0
> c073eb1c c00c857c
> [ 55.895323] ff60: c073eb1c eefb5b38 0000119c c00c7428 000f0abb e5a56840
> c073eb1c c0793cc0
> [ 55.911733] ff80: c07bbcc0 edecffb0 e5a56840 b6a6ecbc 00000000 000000c0
> 000f0042 c0020d68
> [ 55.928144] ffa0: edece000 00000002 b68036d8 c0020cbc 4301022b b68e8250
> 0004b900 b6a6ec80
> [ 55.944553] ffc0: b6a6ecbc 00000000 000000c0 000f0042 000000c0 b68036e4
> b68037bc b68036d8
> [ 55.960964] ffe0: b6f8c221 b6a6ec80 0007b98f b6f8c264 000d0030 4301022b
> 403ac0c4 e34a4d10
> [ 55.977383] [<c00f2d78>] (get_free_range) from [<eeb1e000>] (0xeeb1e000)
> [ 55.990829] Code: e1a02003 9a000016 e1a0c002 e0823007 (e69c4009)
> [ 56.003053] ---[ end trace 1dcd48b94aa9e4b5 ]---
>
> So clearly that is upsetting xenomai. Or at least making it look like
> it is upsetting xenomai given the xnheap_alloc+0x4a4/0x538.
>
> I wish I could figure out why the backtraces aren't working, since they
> are such a nice debug feature to have.
OK blowing up here:
/*
* Search for a range of contiguous pages in
* the free page list of the current
* extent. The range must be 'bsize' long.
*/
do {
lastpage = freepage;
----> freepage = *((caddr_t *) freepage);
freecont += heap->pagesize;
}
while (freepage == lastpage + heap->pagesize
&& freecont < bsize);
I wonder if I am getting to the end of the list and trying to derefence
a NULL pointer as a result. I see nothing in the code to make sure it
doesn't try to do that, although I hope I am just misreading the code.
Maybe the heap allocated to the application is too small.
--
Len Sorensen
_______________________________________________
Xenomai mailing list
[email protected]
http://xenomai.org/mailman/listinfo/xenomai
