Messages in this thread | | | Date | Thu, 9 Oct 2014 22:41:01 +0200 | From | Rabin Vincent <> | Subject | Re: RCU bug with v3.17-rc3 ? |
| |
On Thu, Oct 09, 2014 at 11:26:56AM -0500, Felipe Balbi wrote: > alright, it's pretty deterministic however. Always on the same test, no > matter which USB controller, no matter if backing store is RAM or MMC. > > Those two undefined instructions on the disassembly caught my attention, > perhaps I'm facing a GCC bug ?
The undefined instructions are just ARM's BUG() implementation.
But did you see the question I asked you yesterday in your other thread? http://www.spinics.net/lists/arm-kernel/msg368634.html
Here it is again:
What GCC version are you using?
4.8.1 and 4.8.2 are known to miscompile the ARM kernel and these find_get_entry() crashes with 0xffffffff involved smell a lot like the earlier reports from kernels build with those compilers: https://lkml.org/lkml/2014/6/25/456 https://lkml.org/lkml/2014/6/30/375 https://lkml.org/lkml/2014/6/30/660 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58854 https://lkml.org/lkml/2014/5/9/330
Also, I didn't see any public email making a definitive link between GCC PR 58854 that Nathan pointed out in https://lkml.org/lkml/2014/6/30/660 and the earlier find_get_entry() crashes, but I just built GCC 4.8.1 and an ARM kernel with that, and the GCC bug is clearly seen in radix_tree_lookup_slot() which returns the pointer which find_get_entry() is dereferencing:
<radix_tree_lookup_slot>: e1a0c00d mov ip, sp e92dd800 push {fp, ip, lr, pc} e24cb004 sub fp, ip, #4 e24dd008 sub sp, sp, #8 e3a02000 mov r2, #0 e24b3010 sub r3, fp, #16 ebffffc5 bl c0176ab8 <__radix_tree_lookup> e24bd00c sub sp, fp, #12 <--- sp moved up e3500000 cmp r0, #0 151b0010 ldrne r0, [fp, #-16] <--- load from under sp e89da800 ldm sp, {fp, sp, pc}
Please check your compiler to make sure it's not the same problem.
| |