Booting 2.6.29-rc3 on mpc8661d_hpcn failing

[Martyn Welch]

Martyn Welch wrote:
> Benjamin Herrenschmidt wrote:
>>>>> commit 64b3d0e8122b422e879b23d42f9e0e8efbbf9744
>>>>> Author: Benjamin Herrenschmidt <benh at 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