Nguyen Dinh-R00091 <R00091@...> writes: > > Hi, > > On the Freescale i.MX35 3DS board, there is a total of 256MB of DDR2 and the configuration is 128MB on > Chip-select 0 and 128MB on chip-select 1. So physically, the memory is not contiguous, so we boot up the > system with these mem= parameters(mem=128M <at> 0x80000000 mem=128M <at> 0x90000000). The system seems to be > operating fine and passes stress testing using memtester and oprofile, except for USB. > > Running a USB copy stress test on USB mass storage between a USB HDD and an SD/MMC card causes the system to > hang. The hang can occur at any time between 10 minutes to 2 hours. The hang is much harder to re-create if > logs or delays are introduced. > > A few data points from my debugging: > 1) If I run the system at 128MB(either at physical 0x80000000 or 0x90000000) then the hang never occurs. > 2) Running the same test on a Freescale i.MX53 with a similar memory configuration also does not exhibit the error. > 3) This failure can be reproduced on the both the Freescale BSP and the kernel.org BSP for MX35-3DS system. > 4) I'm suspecting a memory abort access when the USB HW is DMA-ing its qtd and buffers, but I can't seem to trap > on this condition. Any logs that I introduce into the EHCI driver seems to make the hang go away. > > If anyone has any idea on how I can further debug, or better yet a suggested fix, I would greatly appreciate > it. Also I am available to work with anyone to fix this problem if anyone is interested. > > Thanks and best regards, > > Dinh > > -- > To unsubscribe from this list: send the line "unsubscribe linux-usb" in > the body of a message to majordomo@... > More majordomo info at http://vger.kernel.org/majordomo-info.html > > we also are having a similar problem, its our own hardware based on the 3DS stack, we get problems playing a video in loop with the 256megs enabled from SDCARD. It stops all clocks to the display and memory. We can make the problem worse by disabling L2 cache, we can make it go away by having only 128megs enabled. we can make it worse by blit blitting to the screen using hardware blts about 70fps. if we do 20fps it can run for days with L2c cache on. we have tried many DDR ram settings , including running the DDR2 checker tool, and it shows no problems (though it only tests a very small chunk of memory). I will try one bit sdcard instead of 4 bit to see if that helps. Did you get any further? I suggest you turn off l2 cache and see it you test last more than 5 seconds. If not , we could be debugging the same thing. Greg. -- 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
