[PATCH] shared processor hcalls use wrong cpu id?

[Nathan Lynch]

Hi-

During cpu hotplug stress runs on shared processor configurations, we're
seeing what looks like kernel stack corruption and sometimes deadlocks.
  The platform documentation is not terribly explicit about this, but
the shared processor-related hcalls which take a processor number
parameter (H_REGISTER_VPA, H_CONFER, H_PROD) expect that number to be
the "hardware" id -- that is, the number taken from the
ibm,ppc-interrupt-server#s property of the cpu's OF device node.  Right
now, we're passing the Linux "logical" cpu id to these calls.

We're still running tests to determine whether this fixes some of the
issues we're seeing; but I thought this was important enough to get out
for review and to make sure I'm on the right track.  The patch is pretty
rough (e.g. I don't think we want to panic if H_CONFER fails for some
reason).

Also note that I changed the H_CONFER call in the lock code to pass -1
(all cpus) since it's not very clear to me how the lock holder is
recorded in the spinlock.

Nathan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vpa_fix_cpu_id.patch
Type: text/x-patch
Size: 2588 bytes
Desc: not available
Url : http://ozlabs.org/pipermail/linuxppc64-dev/attachments/20040607/0ad6bf65/attachment.bin