Eric W. Biederman wrote:
quoted text
> Mark Lord <lkml@rtr.ca> writes:
>> Comments?  Eric?
> 
> Sorry -EBUSY.
> 
> The trylock on call_lock is a recent thing (.22), added to keep panic
> from hanging.   It probably makes more sense to move bust_spinlocks(0)
> down a few lines in kernel/panic.c and to test oops_in_progress in
> smp_send_stop and make all screwy locking behavior depend on that.

I've seen this issue (to a much lessor extent) on 2.6.17 as well.
So if earlier kernels had the regular spin_lock() there (rather than trylock)
then this is still *an* issue, but not *the* issue.  And in my specific
case (only 2 CPUs), the trylock cannot be the problem here.
But with more cores it definitely could be an issue.

quoted text
> As for not waiting until cpus are in their stop loop that looks easy
> enough to remedy.  I don't know if any of those is our culprit but
> it certainly looks worth cleaning up.  If you are interested in
> testing I will cook up a patch.

I suspect this one more, as there really are not many other possibilities.
One thing to try might be to just have the power_off() code do msleep(1000)
before the ACPI poweroff call.  That would give enough time for the other
core to "halt", and is easy enough to try for diagnosis purposes.

I'm off rock climbing for a week or so, but if you cook something up
in the meanwhile then I'll test it on return.

quoted text
> I haven't had a chance yet to walk through the other possible x86
> sysdev devices to see if there are any other canidates.

Cheers!

-
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/