RE: 2.6.29 and SDP3430 now 2.6.30-rc2, q3-2007 compiler error
From: Shilimkar, Santosh Sent: Monday, April 20, 2009 11:39 PM Thanks Richard for root casing the issue. Yes I also did observed this. Second time when framework calls omap2_gp_timer_set_mode set the periodic mode, R0 contains 0 (CLOCK_EVT_MODE_UNUSED) instead of 2(CLOCK_EVT_MODE_PERIODIC). The assembly generated looks shocking because it prepares the second function arguments in register R1 as expected and then 'pop' destroys it. A push before a function call is reasonable but this not quite understandable. Can this be taken up with Codesorcery team to check what is triggering compiler to generate such an assembly ? The compiler version is old enough I wouldn't anticipate they would do a fix unless someone was using this for production. Typically they release some for pay fix ups around a base. This may or may not be fixed in one of those. If anyone is using it they should speak up. The compiler probably noticed it could optimize away the function return point (can ret back to caller from called function instead of present one after call. It then messed up). Regards, Richard W. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: 2.6.29 and SDP3430
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Mark Brown Sent: Thursday, April 09, 2009 4:34 PM To: Menon, Nishanth Cc: Woodruff, Richard; Jarkko Nikula; linux-omap Subject: Re: 2.6.29 and SDP3430 On Thu, Apr 09, 2009 at 01:32:27PM -0500, Menon, Nishanth wrote: implementor 41 architecture 3 part 30 variant c rev 1 regulator_init_complete: incomplete constraints, leaving VAUX3 on That last message shouldn't be a problem - it means that if the machine init code had requested it the regulator core would've powered off the VAUX3 regulator since it has no users. Well, I just disabled TWL4030 regulator support (CONFIG_REGULATOR_TWL4030) and now it boots without problem... I'm using a SDP3430 VG9.0.0 with an ES3.1 chip. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: 2.6.29 and SDP3430 now 2.6.30-rc2, q3-2007 compiler error
Thanks Richard for root casing the issue. Yes I also did observed this. Second time when framework calls omap2_gp_timer_set_mode set the periodic mode, R0 contains 0 (CLOCK_EVT_MODE_UNUSED) instead of 2(CLOCK_EVT_MODE_PERIODIC). The assembly generated looks shocking because it prepares the second function arguments in register R1 as expected and then 'pop' destroys it. A push before a function call is reasonable but this not quite understandable. Can this be taken up with Codesorcery team to check what is triggering compiler to generate such an assembly ? -Original Message- From: Woodruff, Richard Sent: Tuesday, April 21, 2009 6:34 AM To: Aguirre Rodriguez, Sergio Alberto; Mark Brown; Menon, Nishanth; Tony Lindgren Cc: Jarkko Nikula; linux-omap; Shilimkar, Santosh; Pandita, Vikram Subject: RE: 2.6.29 and SDP3430 now 2.6.30-rc2, q3-2007 compiler error So using defconfig and float I debugged around a bit and for q3-2007 I see what looks to be compiler error. The parameter in R1 which sets PERIODIC mode for call to clockevnet_set_mode()is destroyed. See PNG. I did make sure at start_kernel the correct opcode was in place (no overwrite later, no cache flush issue). If I apply hacks to reduce optimization scope the code does go past hang. See attached hack. It seems kind of odd this would bite now after a lot of new use. Perhaps the new mix of functions and layout triggered it. Regards, Richard W. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: 2.6.29 and SDP3430
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Jarkko Nikula Sent: Thursday, April 09, 2009 2:04 AM just messing around with tony's master branch on SDP3430, just did a defconfig and a build with 2007q3-51 codesourcery compiler, I see it hang around: Kernels built with this compiler stuck into delay loop calibration. No idea why, but 2008q3-66 was working for me. I wonder if the timer stopped ticking. If you connect with emulator take a look at GPT1 registers and see if time base is moving. Another quick test is to shut off tickles, nohz=off. Calibration code is just is spinning and counting interrupts. Regards, Richard W. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: 2.6.29 and SDP3430
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Woodruff, Richard Sent: Thursday, April 09, 2009 8:00 AM From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Jarkko Nikula Sent: Thursday, April 09, 2009 2:04 AM just messing around with tony's master branch on SDP3430, just did a defconfig and a build with 2007q3-51 codesourcery compiler, I see it hang around: Kernels built with this compiler stuck into delay loop calibration. No idea why, but 2008q3-66 was working for me. Using the following: arm-none-linux-gnueabi-gcc (Sourcery G++ Lite 2008q3-72) 4.3.2 I am past the lockup on calibration, but it now gets stuck as follows: NET: Registered protocol family 15 RPC: Registered udp transport module. RPC: Registered tcp transport module. Disabling unused clock gpt2_ick Disabling unused clock gpt2_fck Disabling unused clock wdt2_ick Disabling unused clock wdt2_fck Disabling unused clock dpll4_m6x2_ck Disabling unused clock dpll4_m5x2_ck Disabling unused clock dpll3_m3x2_ck Disabling unused clock sys_clkout1 variant c rev 1 implementor 41 architecture 3 part 30 variant c rev 1 regulator_init_complete: incomplete constraints, leaving VAUX3 on I wonder if the timer stopped ticking. If you connect with emulator take a look at GPT1 registers and see if time base is moving. Another quick test is to shut off tickles, nohz=off. nohz=off did not work with either 2007q3 or 2008q3.. have'nt looked at the GPT regs though.. Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: 2.6.29 and SDP3430
I wonder if the timer stopped ticking. If you connect with emulator take a look at GPT1 registers and see if time base is moving. Another quick test is to shut off tickles, nohz=off. nohz=off did not work with either 2007q3 or 2008q3.. have'nt looked at the GPT regs though.. Hmm, something is broke. Can put bad SDP kernel and vmlinux on a share and send me link? I'm feeling lazy, but could take a quick peek as it's curious :) Thanks, Richard W. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.29 and SDP3430
On Thu, Apr 09, 2009 at 01:32:27PM -0500, Menon, Nishanth wrote: implementor 41 architecture 3 part 30 variant c rev 1 regulator_init_complete: incomplete constraints, leaving VAUX3 on That last message shouldn't be a problem - it means that if the machine init code had requested it the regulator core would've powered off the VAUX3 regulator since it has no users. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
