Boot hang regression 3.10.0-rc4 -> 3.10.0

Tony Lindgren tony at atomide.com
Fri Jul 5 07:59:59 EDT 2013


* Bedia, Vaibhav <vaibhav.bedia at ti.com> [130705 01:17]:
> On Thu, Jul 04, 2013 at 21:30:14, Mark Jackson wrote:
> > On 04/07/13 16:14, Mark Jackson wrote:
> > > On 04/07/13 14:25, Mark Jackson wrote:
> > >> Our custom AM335x board has been booting just fine under 3.10.0-rc4.
> > >>
> > >> I've just done a git pull to update to 3.10 (now that it's released)
> > >> and the board now hangs.
> > >>
> > >> Before I start trying to bisect the issue, does anyone have an clues ?
> > > 
> > > Okay ... I've now bisected it to:-
> > > 
> > > a630fbfbb1beeffc5bbe542a7986bf2068874633 is the first bad commit
> > > commit a630fbfbb1beeffc5bbe542a7986bf2068874633
> > > Author: Tony Lindgren <tony at atomide.com>
> > > Date:   Mon Jun 10 07:39:09 2013 -0700
> > > 
> > >     serial: omap: Fix device tree based PM runtime
> > 
> > However, reverting the commit does *not* fix the issue, weird !!
> > 
> > But I have now tested:-
> > 
> > v3.10-rc4     -> works
> > v3.10-rc5     -> works
> > v3.10-rc6     -> works
> > v3.10-rc7     -> works
> > v3.10         -> works
> > origin/master -> hangs
> > 
> > Any ideas ?
> 
> I just checked the behavior on my AM335x-EVM. Current mainline boots fine
> provided I don't use earlyprintk.  The offending patch [1] in this case is the one
> that tries to get rid of omap_serial_early_init() for DT boot. This change inadvertently
> also results in the console UART getting reset and idled during bootup and that's where
> the boot stops for you. I think if you skip earlyprintk from the bootargs you should see
> the system booting fine. 
> 
> I guess we need to retain the NO_IDLE and NO_RESET aspect for the console UART in
> omap_serial_early_init() to get earlyprintk working again.

Hmm nothing should get idled while earlyprintk is running, and then when the
serial driver kicks in it should not idle anything by default. And for DT based
booting we should not have mach-omap2/serial.c initialize anything.

I wonder if this is because the timeouts get now initialized to 0 instead
of -1 for the serial driver?

Regards,

Tony
 
> [1] http://www.spinics.net/lists/linux-omap/msg91825.html
> 



More information about the linux-arm-kernel mailing list