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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
