aboutsummaryrefslogtreecommitdiff
path: root/Documentation/scsi/ChangeLog.sym53c8xx_2
diff options
context:
space:
mode:
authorRuss Anderson <rja@sgi.com>2007-09-19 16:58:31 -0500
committerTony Luck <tony.luck@intel.com>2007-10-12 15:19:02 -0700
commite1b1eb011e15190eb859bad0bcae67679bda7d50 (patch)
treed86d48627b32051ec57ec3dbd47e9bcbd01a40e5 /Documentation/scsi/ChangeLog.sym53c8xx_2
parent2bc5c282999af41042c2b703bf3a58ca1d7e3ee2 (diff)
[IA64] Fix race when multiple cpus go through MCA
Additional testing uncovered a situation where the MCA recovery code could hang due to a race condition. According to the SAL spec, SAL sends a rendezvous interrupt to all but the first CPU that goes into MCA. This includes other CPUs that go into MCA at the same time. Those other CPUs will go into the linux MCA handler (rather than the slave loop) with the rendezvous interrupt pending. When all the CPUs have completed MCA processing and the last monarch completes, freeing all the CPUs, the CPUs with the pended rendezvous interrupt then go into the ia64_mca_rendez_int_handler(). In ia64_mca_rendez_int_handler() the CPUs get marked as rendezvoused, but then leave the handler (due to no MCA). That leaves the CPUs marked as rendezvoused _before_ the next MCA event. When the next MCA hits, the monarch will mistakenly believe that all the CPUs are rendezvoused when they are not, opening up a window where a CPU can get stuck in the slave loop. This patch avoids leaving CPUs marked as rendezvoused when they are not. Signed-off-by: Russ Anderson <rja@sgi.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
Diffstat (limited to 'Documentation/scsi/ChangeLog.sym53c8xx_2')
0 files changed, 0 insertions, 0 deletions