Hi Afzal, I just wanted to follow back up. We are still trying to find this slab bug, but so far we've not found any smoking guns. Less than stable power is our current main suspect. As has been the custom however, the error was here 2 weeks ago nearly non-stop, and then as suddenly as it came it went nearly silent. We've had a very hard time reproducing it since! Anyway, we have advanced our kernel to today's latest l-o (3.5-rc2). Though we are not considering the GPMC a likely source of the error at this moment, I'm considering exploring this patchset. Unfortunately, the NAND is very critical to our current efforts. So I'm trying to find a time where it would be OK to disable it as you suggested to try this. Since these values are being set now in Linux, do I need to rework my bootloaders as well? In my current case, these settings are all done in u-boot. I do not believe Linux did anything with them. Do I need to remove those in order to use your patches? If I do, do I not lose access to those things while in the bootloaders? Thanks ----- Original Message ----- From: "Mohammed, Afzal" <afzal@xxxxxx> To: CF Adad <cfadad@xxxxxxxxxxxxxx> Cc: "linux-omap@xxxxxxxxxxxxxxx" <linux-omap@xxxxxxxxxxxxxxx>; Tony Lindgren <tony@xxxxxxxxxxx>; "Shilimkar, Santosh" <santosh.shilimkar@xxxxxx> Sent: Tuesday, June 12, 2012 7:14 AM Subject: RE: Please help! AM35xx mm/slab.c BUG Hi, On Fri, Jun 08, 2012 at 01:20:13, CF Adad wrote: > Thanks for your thoughts! I may try fiddling a bit just to see if that helps. 5 series of patches for gpmc modifications [1-5] has been posted, In case it helps in resolving your issue, please let me know. You will have to use the new interface to make use of runtime calculation of smsc911x timing, [5.x] can be referred for how to do board modifications for smsc911x (please comment out any other gpmc peripheral initialization in your board code, seems you have nand, comment out nand initialization, even nand can be made to work with new changes, but avoiding it will probably reduce your burden) As your eth is 9221, either you can provide the timings based on it from board file or apply [6] over [1-5] (base: 3.5-rc1) Regards Afzal [1] http://www.mail-archive.com/linux-omap@xxxxxxxxxxxxxxx/msg69501.html [2] http://www.mail-archive.com/linux-omap@xxxxxxxxxxxxxxx/msg69881.html [3] http://www.mail-archive.com/linux-omap@xxxxxxxxxxxxxxx/msg69891.html [4] http://www.mail-archive.com/linux-omap@xxxxxxxxxxxxxxx/msg69897.html [5] http://www.mail-archive.com/linux-omap@xxxxxxxxxxxxxxx/msg69917.html [5.x] http://www.mail-archive.com/linux-omap@xxxxxxxxxxxxxxx/msg69924.html [6] diff --git a/arch/arm/mach-omap2/gpmc-smsc911x.c b/arch/arm/mach-omap2/gpmc-smsc911x.c index 4bfe721..34816b9 100644 --- a/arch/arm/mach-omap2/gpmc-smsc911x.c +++ b/arch/arm/mach-omap2/gpmc-smsc911x.c @@ -105,12 +105,12 @@ static void gpmc_smsc911x_timing(struct gpmc_time_ctrl *time_ctrl, { struct gpmc_timings t; /* SMSC 9220 timings */ - unsigned tcycle_r = 165; + unsigned tcycle_r = 45; unsigned tcsl_r = 32; unsigned tcsh_r = 133; unsigned tcsdv_r = 30; unsigned tdoff_r = 9; - unsigned tcycle_w = 165; + unsigned tcycle_w = 45; unsigned tcsl_w = 32; unsigned tcsh_w = 133; unsigned tdsu_w = 7; -- 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
