Martyn Welch wrote:
Benjamin Herrenschmidt wrote:
commit 64b3d0e8122b422e879b23d42f9e0e8efbbf9744
Author: Benjamin Herrenschmidt <b...@kernel.crashing.org>
powerpc/mm: Rework usage of _PAGE_COHERENT/NO_CACHE/GUARDED
I tried reverting it, but as I had kinda thought, that really
didn't help.
I'm just recompiling to check that I didn't screw-up during the
bisection.
Is this a chip that must not have M set ? Or something else ? You guys
have to help if you CC me, I have about 0 idea what a MPC8661d is :-)
Sorry, my fault. It's a Freescale SOC with two e600 cores. Beyond that,
I'm afraid I'm a little out of my depth.
Also, does 4c456a67f501b8b15542c7c21c28812bf88f484b help ?
I believe that to be included in 2.6.29-rc3 if my (rather rudimentary)
git skills haven't let me down? The problem persists in 2.6.29-rc3.
I've done a bit more investigation:
The primary CPU is spinning in smp_generic_give_timebase() waiting for "!tbsync->ack". The secondary CPU
has made it into smp_generic_take_timebase() and has apparently (according to some printk's I put in there) set
"tbsync->ack=1". After that I don't get any printk's, I guess that the one I have put in the
"!tbsync->handshake" while loop is making it to the print buffer, but with both processors spinning it's
not getting to the serial console.
At a guess, given that commit 64b3d0e8122b422e879b23d42f9e0e8efbbf9744 seems to be the
point that it stopped working correctly, that "tbsync" is now somehow becoming
cached?
Martyn
--
Martyn Welch MEng MPhil MIET (Principal Software Engineer) T:+44(0)1327322748
GE Fanuc Intelligent Platforms Ltd, |Registered in England and Wales
Tove Valley Business Park, Towcester, |(3828642) at 100 Barbirolli Square,
Northants, NN12 6PF, UK T:+44(0)1327359444 |Manchester,M2 3AB VAT:GB 729849476
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
