Hi Tony, Thanks again. I'm really starting to think the GPMC almost has to be contributing. In our setup, we have 2 separate versions of a baseboard for the TAM. One version has the LAN9221 as a secondary Ethernet, while the other does not. Otherwise, they're basically the same. I can run the same code on both. It seems from our testing that the vast majority of the crashes occur on the module with the LAN9221. Even with the SMSC just idle, it seems the one with that extra port is most likely to fail. As I mentioned previously, I'm far from a GPMC expert. I posted a thread to the TI E2E forums asking them for comments on my LAN9221 GPMC settings (http://e2e.ti.com/support/dsp/sitara_arm174_microprocessors/f/416/p/172157/690750.aspx#690750). I began to question what I had after some Google searches pulled up other patches which showed disparities between what I'm using and what others are using. Do you folks know of a good reference for properly calculating these GPMC settings? When I did the EMIF4 stuff, I was very pleased to find TI had a great set of resources online (http://processors.wiki.ti.com/index.php/Setting_up_AM35x_SDRC_registers), including an Excel spreadsheet that helped generate the register values for me. I've found the following links on the GPMC, but have not been nearly as impressed as I was with the information on the EMIF4: http://processors.wiki.ti.com/index.php/AM3517/05_GPMC_Subsystem http://processors.wiki.ti.com/index.php/Ethernet_Connectivity_via_GPMC http://e2e.ti.com/support/dsp/sitara_arm174_microprocessors/f/416/t/49394.aspx The only other thing I know I have on the GPMC is the NAND flash, and it is taking the default settings along with several other boards in the AM35xx family (<x-loader>/include/asm/arch-omap3/mem.h): /* for L3 = 165MHz & 16-bit NAND */ # define M_NAND_GPMC_CONFIG1 0x00001800 # define M_NAND_GPMC_CONFIG2 0x00080800 # define M_NAND_GPMC_CONFIG3 0x00080800 # define M_NAND_GPMC_CONFIG4 0x06000600 # define M_NAND_GPMC_CONFIG5 0x00070808 # define M_NAND_GPMC_CONFIG6 0x000003cf # define M_NAND_GPMC_CONFIG7 0x00000848 Any thoughts on that? Thanks again. Your help is *greatly* appreciated. ----- Original Message ----- From: Tony Lindgren <tony@xxxxxxxxxxx> To: "Shilimkar, Santosh" <santosh.shilimkar@xxxxxx> Cc: CF Adad <cfadad@xxxxxxxxxxxxxx>; "linux-omap@xxxxxxxxxxxxxxx" <linux-omap@xxxxxxxxxxxxxxx> Sent: Wednesday, June 6, 2012 3:10 AM Subject: Re: Please help! AM35xx mm/slab.c BUG * Shilimkar, Santosh <santosh.shilimkar@xxxxxx> [120605 23:41]: > > I don't know the AMXX architecture that well but looking at the > crash-log, am not sure GPMC should play in role here. > What I think is, it is mostly memory corruption and can be caused by > many reasons as Tony outlined. Bad GPMC timings can cause corruption on the smsc fifo, which can cause random oopses especially with nfsroot. I was seeing that on my zoom3 with nfsroot with bad muxing for GPMC until we applied bce492c0 (ARM: OMAP2+: UART: Fix incorrect population of default uart pads). That's easy to test by leaving out GPMC. > To ensure that, your memory is in good state, can you run memtester > for long duration and see that you > are not getting any memory failures. Try to give the maximum memory > size as a an input to memtester. Yes and that should be left running for a few weeks on a group of devices to verify things work once you think you have all the issues fixed. Regards, Tony > You can download one from [1] > > Regards > Santosh > [1] http://pyropus.ca/software/memtester/ -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
