Re: Open issues after 2.6.38 merge window

[Tony Lindgren <tony@atomide.com>]

* Russell King <rmk@arm.linux.org.uk> [110117 04:24]:
> On Mon, Jan 17, 2011 at 05:49:00PM +0530, Santosh Shilimkar wrote:
> > > -----Original Message-----
> > > From: Russell King [mailto:rmk@arm.linux.org.uk]
> > > Sent: Monday, January 17, 2011 5:42 PM
> > > To: Santosh Shilimkar
> > > Cc: Aaro Koskinen; Tony Lindgren; linux-omap@vger.kernel.org
> > > Subject: Re: Open issues after 2.6.38 merge window
> > >
> > > On Mon, Jan 17, 2011 at 05:29:01PM +0530, Santosh Shilimkar wrote:
> > > > > On Fri, 14 Jan 2011, Tony Lindgren wrote:
> > > > > > Before I update out master branch, let's try to summarize the
> > > > > > open issues after the merge window. Here's a list of issues
> > > > > > in omap-fixes-for-linus that I'm aware of:
> > > > > >
> > > > > > - NFS root oopses while mounting root
> > > > > >
> > > > > > - omap4430 es1.0 hangs if L2X0 cache is enabled
> > > > > >
> > > > > > - omap4 panda powers down after boot (watchdog?)
> > > > > >
> > > > > > - omap3 ldp board powers down after boot?
> > >
> > > This doesn't happen for me.

OK, good to hear that's a separate issue and fixed.

> > > > > >
> > > > > > Any other issues?
> > > > >
> > > > > Amstrad E3 fails during the boot. Bisection points to:
> > > > >
> > > > >  	commit 211baa7016894c02fc18693e21ca479cd08ac0c0
> > > > >  	Author: Russell King <rmk+kernel@arm.linux.org.uk>
> > > > >  	Date:   Tue Jan 11 16:23:04 2011 +0000
> > > > >
> > > > >  	    ARM: sched_clock: allow init_sched_clock() to be called
> > > > > early
> > > > >
> > > > > The board does not have sched_clock(), although HAVE_SCHED_CLOCK
> > > is
> > > > > defined for all OMAP.
> > > > >
> > > > I guess above is sorted out by the attached patch from Paul.
> > >
> > > There's an issue missing from Tony's list:
> > >
> > > - running an omap2plus_defconfig kernel on SMP is unsafe to the
> > > point
> > >   of being data corrupting for filesystems, especially for ext2/ext3
> > >   mounted read-write.
> > >
> > > This is because when CPU_32v6K is disabled - which is required to
> > > build
> > > a kernel to boot on ARMv6, it turns off the SMP safe bitops - the
> > > SMP
> > > safe bitops only use instructions available to ARMv6K and above.
> > > They
> > > are reduced to local-irq-disabling, plain byte loads and stores.
> > >
> > > So, running omap2plus_defconfig on SMP is risking filesystem
> > > corruption.
> > >
> > > Patches for this are being worked on, but they won't be ready for -
> > > rc1.
> > > I strongly suggest someone restores some kind of build or runtime
> > > error
> > > (eg, by removing CPU_32v6K's dependence on !OMAP2 - thereby
> > > _intentionally_
> > > breaking omap2plus_defconfig) before someone ends up with a
> > > corrupted
> > > filesystem.  Or just make sure that everyone is aware that
> > > omap2plus_defconfig can eat filesystems at the moment.
> > >
> > Thanks. I missed your other patch of removing !OMAP2 from
> > CPU_32v6K config.
> 
> With the problems addressed, I think that removal of !OMAP2 is not
> strictly required - but I don't like the idea of disabling CPU_32v6K
> in general as we can't ensure that this kind of thing doesn't happen
> in the future.

For the current -rc cycle, is the spinlock fix is enough while
keeping CPU_32v6K disabled?
 
> Not disabling CPU_32v6K also fixes the swp_emulate build problem too
> (which is why I've never seen it here.)
> 
> There are several V6K bits that need to be addressed (such as a single
> clrex vs two instruction strex) before we can properly build a kernel
> supporting V6 but also containing V6K extensions.

I agree building in the V6K extensions would the best solution in
the long run.

Regards,

Tony