[fedora-arm] Just in case you don't read Slashdot :)

[Jon Masters]

On 10/06/2012 05:47 AM, Jon Masters wrote:
> On 10/05/2012 07:34 AM, Josh Boyer wrote:
>> On Fri, Oct 5, 2012 at 3:50 AM, Peter Robinson <pbrobinson at gmail.com> wrote:
>>> For Fedora 18 with 3.7 it should (whether it works out in time or we
>>> start with F-19 and roll it back) mean we can support more devices
>>> with a couple of less kernels. The mvebu platform is the Marvell
>>
>> F18 is going to GA with 3.6.x.  We'll rebase to 3.7 at some point, but
>> it won't be until after the release.  If you're wanting to do this on a
>> release boundary, F19 would be your target.  If you're OK with rolling
>> it out as an update, then F18 is doable.  Just an FYI.
> 
> We're planning on a 3.7 update in F18. The thing is that this is likely
> to be a disruptive upgrade as certain platforms (even without a unified
> kernel) will need to have a working device tree. Hence, the moment there
> is an -rc1 to poke at, we'll make sure this is lined up.
> 
> A quick update on the kernel, since I've been giving it love (and will
> allocate time each week to do so going forward). I currently believe
> that the latest test build fixes everything but USB on PandaBoard (that
> issue is likely to be a USB hub initialization problem - there are two
> possible GPIOs and one clock source Dave Anders is looking into as the
> TI maintainer involved - because the smsc95xx is on an internal bus):
> 
> http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=1175808
> 
> I just need Josh to fix the module signing patch per kernel@

David, Paul: please test this kernel on Highbank in particular, and if
it ceases to generate BUG() warnings (which it should), have Peter pull
the patch I posted on IRC that is also in this test kernel.

The patch reverts a commit from Will Deacon that adds a (technically
correct) warning in put_user. There is a real, heretoforce, silent bug
that does need fixing and is being looked into upstream. As a very brief
summary of the impact, ARMv7 allows missaligned accesses except to
things like stm/ldm (load/store) multiple which are supposed to be
aligned accesses. The compiler is doing the right thing because it
believes the structs in question (IP packet headers) are aligned
correctly, but they aren't necessarily at runtime. Even with a patch to
have the alignment fault handler dtrt there is still a performance
impact with taking so many faults, and that is also being poked at.

FWIW, lots of this stuff goes away in v8, which is very tolerant of
miss-aligned accesses (replacing ldm/stm with pair operations), except
in the case of exclusive access, which is relatively rare (locks).

Jon.