On Wed, Sep 16, 2015 at 02:48:50PM +0530, [email protected] wrote: > On 15-09-16 15:54:21, Peter Chen wrote: > > On Wed, Sep 16, 2015 at 02:18:49PM +0530, [email protected] wrote: > > > Hello Peter, > > > > > > > > > > > Enable CONFIG_DEBUG_LIST, it has below position if you > > > > run make menuconfig > > > > Kernel hacking ---> > > > > [*] Debug linked list manipulation > > > > > > > > > > Sorry for the delay. When I enabled this config the first time my test > > > application ran for 24 hours or so and I did not get any stack traces. > > > > > > I restarted the test again and finally got the trace below. You were > > > spot on, its a list corruption issue. I modified the trace a bit after > > > copying to remove the sprinkled debug messages throughout the trace > > > from my test application. > > > > > > [ 622.204134] WARNING: CPU: 0 PID: 0 at lib/list_debug.c:59 > > > __list_del_entry+0xc4/0xe8() > > > [ 622.212870] list_del corruption. prev->next should be 8db63600, but > > > was 36008db6 > > > > You see the higher 16 bits were swapped with lower 16 bits, and the > > virtual memory address should begin from 0x8xxxxxxxx, right? > > Yes, I saw that but beats me how this happens. > > > > > Check with Vybrid errata to see if all ARM/memory system have applied. > > What do you mean by "all ARM/memory system have applied" ? I checked with the > Vybrid errata > and I do not see anything related. >
Just system level errata, like ARM Cortex A5, memory (L1/L2 Cache), etc. Would you please do more tests to see if the error pattern is always the same? And print the address to store prev-next. -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
