Eric W. Biederman wrote:
Mark Lord <[email protected]> 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.
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.
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!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
