From: "Luck, Tony" <tony.luck@intel.com>
To: linux-ia64@vger.kernel.org
Subject: [Linux-ia64] CONFIG_IA64_NEW_UNWIND
Date: Wed, 07 Mar 2001 00:48:07 +0000 [thread overview]
Message-ID: <marc-linux-ia64-105590693005250@msgid-missing> (raw)
I'm running 2.4.0 with a couple of patches on 2-CPU Bigsur.
I have a problem where a cpu apparently hangs when a process
dumps core. The "hang" is caused when do_copy_regs() in
arch/ia64/kernel/process.c picks up random values for RSE
backing store addresses, and sits in this loop:
for (addr = pt->ar_bspstore; addr < ar_bsp; addr += 8)
if (ia64_peek(pt, current, addr, &val) = 0)
access_process_vm(current, addr, &val, sizeof(val),
1);
for a really long time (last time I caught it "addr" was 0x000003e2_47fbf540
and "ar_bsp" was 0x00006000_00000000 ... every call to ia64_peek() failed
with EIO ... but I calculated that it would have taken over six weeks to
complete the loop).
Looking back at where do_copy_regs() digs these values out of the
stack, I think that the problem lies in these lines:
unw_get_sp(info, &sp);
pt = (struct pt_regs *) (sp + 16);
We pick up a perfectly reasonable "sp" in the first line, but I
can't see why the code believes that that there would be a pt_regs
structure 16 bytes further up. I think that the frame looks like
this at this point
[high addresses]
frame for ia64_elf_core_copy_regs() <- "unw_get_sp(info, &sp)"
switch_stack structure (pushed by unw_init_running)
unw_frame_info structure (pushed by unw_init_running)
[low addresses]
The CONFIG_IA64_NEW_UNWIND=n version seems to make more
sense (it just uses the pt_user structure that was passed
to ia64_elf_core_copy_regs()).
A quick scan of 2.4.2 shows no apparent changes here.
Any clues?
-Tony Luck
next reply other threads:[~2001-03-07 0:48 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-03-07 0:48 Luck, Tony [this message]
2001-03-07 16:53 ` [Linux-ia64] CONFIG_IA64_NEW_UNWIND David Mosberger
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=marc-linux-ia64-105590693005250@msgid-missing \
--to=tony.luck@intel.com \
--cc=linux-ia64@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.