On 07/22/2010 11:38 AM, Thomas Gleixner wrote:

On Thu, 22 Jul 2010, Darren Hart wrote:

quoted

Also of interest is that this path
cpu_idle()->cpu_die()->pseries_mach_cpu_die() to start_secondary()
enters with a preempt_count=1 if it wasn't corrupted across the hcall.

That triggers the problem as well. preempt_count needs to be 0 when
entering start_secondary(). So I really wonder how that ever worked.

quoted

The early boot path from _start however appears to call
start_secondary() with a preempt_count of 0.

Which is correct.

quoted

The following patch is most certainly not correct, but it does eliminate

It is correct, but i think it is incomplete as other portions of the
thread_info on the stack might be in some weird state as well.

Just FYI, I took a look at the stack pointers as well as all the fields 
in the thread_info struct. The only one that changes is preempt_count. 
The previous value of preempt_count doesn't impact the value after cede. 
An initial value of 0, 1, or 4 all result in an after-cede value of 
0xffffffff. I also added 32 bits of padding on either side of the 
preempt_count in case the change was accidental - it wasnt', the padded 
values remained unchanged across the cede call while the preempt_count 
still changed to 0xffffffff.


-- 
Darren Hart
IBM Linux Technology Center
Real-Time Linux Team