On Fri, Sep 18, 2015 at 10:47:17AM +0100, Felipe Tonello wrote: > Hi Peter, > > On Fri, Sep 18, 2015 at 6:39 AM, Peter Chen <peter.chen@xxxxxxxxxxxxx> wrote: > > On Wed, Sep 16, 2015 at 02:48:50PM +0530, maitysanchayan@xxxxxxxxx wrote: > >> On 15-09-16 15:54:21, Peter Chen wrote: > >> > On Wed, Sep 16, 2015 at 02:18:49PM +0530, maitysanchayan@xxxxxxxxx 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. > > This looks exactly the same error I am having with MIDI gadget. In my > case in the udc driver the add_td_to_list() is returning an error > after a dma_pool_alloc() failed. In this case I believe is something > related to f_midi not releasing properly the usb request. > I don't think it is the same, this case is memory corruption, you can try to enable linked list debug to see if it is the same. Kernel hacking ---> [*] Debug linked list manipulation Besides, try to enable some memory debug options and see if there are some hints for us. -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
