From: "Matt D. Robinson" <yakker@alacritech.com>
To: linux-kernel@vger.kernel.org
Subject: smp_send_stop() and disable_local_APIC()
Date: Thu, 03 May 2001 10:49:11 -0700 [thread overview]
Message-ID: <3AF19A17.19C2741F@alacritech.com> (raw)
It looks like around 2.3.30 or so, someone added the call
disable_local_APIC() to smp_send_stop(). I'm not sure what the
intention was, but I'm getting some strange behavior as a result
based on some code I'm writing.
Basically, I'm doing the following ...
panic()
{
/* do whatever you want, notifier list, etc. */
smp_send_stop();
write_system_memory();
/* then do whatever */
}
write_system_memory() does a write of all system memory pages to some
block device. It uses kiobufs as the way to get the pages to disk,
doing brw_kiovec() on those pages (using either the IDE or SCSI
driver to write the data).
The wierd behavior I see is that sometimes, smp_send_stop()
being called causes the system to hang up (not every time). If
we don't call smp_send_stop() on those systems, everything works fine.
This looks to be directly caused by the disabling of the APIC, which
we may need to dump pages to local disk. This only applies to some
people's systems -- not everyone displays the same behavior.
I'm sure it's good to disable the APIC, but there's no clean way to
wait on disabling the APIC until after I'm done writing pages out.
My questions are:
1) Why was disable_local_APIC() added to stop_this_cpu()
and smp_send_stop()? Completeness?
2) Is there a better way around this to disable all the
other CPUs without disabling the APIC?
Thanks for any feedback.
--Matt
next reply other threads:[~2001-05-03 17:58 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-05-03 17:49 Matt D. Robinson [this message]
2001-05-04 15:58 ` smp_send_stop() and disable_local_APIC() Eric W. Biederman
2001-05-04 17:29 ` Matt D. Robinson
2001-05-05 5:50 ` Eric W. Biederman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3AF19A17.19C2741F@alacritech.com \
--to=yakker@alacritech.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox