On 07/22/2010 11:38 AM, Thomas Gleixner wrote:
On Thu, 22 Jul 2010, Darren Hart wrote:
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.
The early boot path from _start however appears to call
start_secondary() with a preempt_count of 0.
Which is correct.
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
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
