Re: [Crash-utility] Re: [RFC] Patch for fixing 'files' command: TAKE 3
by anderson＠prospeed.net
> Hi Dave
>
> I see your point. Sorry for all the confusion.
> I now discard using THIS_KERNEL_VERSION(), and
> use VALID_MEMBER() instead.
>
> Sending along the revised patch. Kindly review.
>
> Thanks
> Rachita
Hi Rachita,
This looks good -- the only thing I'll change is to print out the
offsets unconditionally in dump_offset_table() -- I actually
want to see everything in the table, including the -1's for
the invalid members.
Red Hat's on a break until January 3rd, so I probably won't
get to it unti then.
Thanks,
Dave
18 years, 11 months
Re: [Crash-utility] gdb patch for Alpha
by anderson＠prospeed.net
> The gdb-6.1.tar.gz needs to be patched in order to fix an "invalid
> lvalue in assignment" bug on newer compilers on Alpha that prevents
> crash from building.
>
> This patch is the one in upstream gdb that resolves the issue:
Yep -- we're seeing those kinds of gdb-compile issues with the newer
compilers on other processors as well. I'm going to create a
"gdb-6.1.patch" in the top-level directory, create a stanza for its
application in the Makefile, and invoke it during the initial build.
I wish I had done that years ago for the handful of gdb files that
are modified, instead of keeping their changes in CVS, but I'll
just keep updating a per-gdb-release patch file in place from now on.
Nice to hear somebody's still using alphas...
Thanks,
Dave
18 years, 11 months
gdb patch for Alpha
by Troy Heber
The gdb-6.1.tar.gz needs to be patched in order to fix an "invalid
lvalue in assignment" bug on newer compilers on Alpha that prevents
crash from building.
This patch is the one in upstream gdb that resolves the issue:
retrieving revision 1.20
retrieving revision 1.21
diff -u -r1.20 -r1.21
--- src/bfd/coff-alpha.c 2004/04/30 14:23:39 1.20
+++ src/bfd/coff-alpha.c 2004/06/11 14:19:32 1.21
@@ -1455,7 +1455,7 @@
amt = sizeof (struct ecoff_section_tdata);
lita_sec_data = ((struct ecoff_section_tdata *)
bfd_zalloc (input_bfd, amt));
- ecoff_section_data (input_bfd, lita_sec) = lita_sec_data;
+ lita_sec->used_by_bfd = lita_sec_data;
}
if (lita_sec_data->gp != 0)
Thanks,
Troy
18 years, 11 months
crash version 4.0-2.17 is available
by Dave Anderson
- Fix to resurrect LKCD version 8 support, inadvertently broken in
4.0-2.15. (troy.heber(a)hp.com)
- Fix for "net -S" failures in certain 2.6 kernels that failed with
"net: cannot determine what an inet_sock structure is" message;
shows embedded sock structure instead of failing. (anonymous donor)
- Fix for erroneous "net -s" source/destination address and port
values in certain 2.6 kernels; added "net -s" source/destination
address and port values for IPv6 sockets. (anderson(a)redhat.com)
18 years, 11 months
CA SEOS module causes heartburn for crash(1)
by Kurtis D. Rader
I was asked to look at a s390 SUSE dump which had the Computer Associates
SEOS product modules loaded (seos and ksymadd). They exported symbols
with addresses well below the address space for modules. For example,
"dynamic_Seos_syscall_num" with an address of 0x4f90dc0 which is well
below the base of the first module at 0x7880d000. This results in crash
trying to mmap an anonymous 1.9 GB region. Which naturally fails on a
s390 system where the address space is only 2 GiB in size.
Anyone else run across this? Should crash be able to deal with this or
should I simply tell the customer to stop using CA's SEOS product if they
want us to look at their crash dumps?
--
Kurtis D. Rader, Level 3 Linux Support
ABC Service Center, Linux Change Team
T/L 775-3714, DID +1 503-578-3714
18 years, 11 months
crash version 4.0-2.16 is available
by Dave Anderson
- Fix for the x86_64 backtrace code to search all of the exception
stacks for the origin of the active tasks' backtrace when the
information is not available in the dumpfile header. Up until now,
the search was made in the process stack, the per-cpu IRQ stack,
and the per-cpu NMI exception stack; this patch looks at all 3
exception stacks in 2.4 kernels (NMI, STACKFAULT and DOUBLEFAULT),
and all 5 exception stacks in 2.6 kernels (NMI, STACKFAULT,
DOUBLEFAULT, DEBUG and MCE).
- Fix to remove erroneous warning message re: the task cpu not being
the same as the IRQ or exception stack cpu, which was displayed when
doing a non-context-sensitive "bt -E" on an x86_64.
18 years, 11 months
Two x86_64 specific patches to be applied
by Dave Anderson
FYI...
I will be updating the x86_64 backtrace code to search all of the
exception stacks for the origin of the active tasks' backtrace
when the info is not available in the dumpfile header.
Currently it first searches in the task's process stack, then the
per-cpu IRQ stack, and lastly the per-cpu NMI stack. This patch
looks at all 3 exception stacks in 2.4 kernels (NMI, STACKFAULT
and DOUBLEFAULT), and all 5 exception stacks in 2.6 kernels
(NMI, STACKFAULT, DOUBLEFAULT, DEBUG and MCE).
The patch also removes an erroneous warning message re: the
task cpu not being the same as the IRQ or exception stack cpu
that gets displayed when doing a non-context-sensitive "bt -E",
again only on an x86_64.
Dave
--- x86_64.c.orig 2005-12-08 16:20:02.000000000 -0500
+++ x86_64.c 2005-12-08 16:21:30.000000000 -0500
@@ -1490,7 +1490,7 @@ x86_64_in_exception_stack(struct bt_info
(rsp < (ms->stkinfo.ebase[c][i] +
ms->stkinfo.esize))) {
estack = ms->stkinfo.ebase[c][i];
- if (c != bt->tc->processor)
+ if (CRASHDEBUG(1) && (c != bt->tc->processor))
error(INFO,
"task cpu: %d exception stack cpu: %d\n",
bt->tc->processor, c);
@@ -1523,7 +1523,7 @@ x86_64_in_irqstack(struct bt_info *bt)
if ((rsp >= ms->stkinfo.ibase[c]) &&
(rsp < (ms->stkinfo.ibase[c] + ms->stkinfo.isize))) {
irqstack = ms->stkinfo.ibase[c];
- if (c != bt->tc->processor)
+ if (CRASHDEBUG(1) && (c != bt->tc->processor))
error(INFO,
"task cpu: %d IRQ stack cpu: %d\n",
bt->tc->processor, c);
@@ -2311,7 +2311,7 @@ static void
x86_64_get_dumpfile_stack_frame(struct bt_info *bt_in, ulong *rip, ulong *rsp)
{
int panic_task;
- int i, panic, stage;
+ int i, estack, panic, stage;
char *sym;
struct syment *sp;
ulong *up;
@@ -2326,6 +2326,7 @@ x86_64_get_dumpfile_stack_frame(struct b
ms = machdep->machspec;
ur_rip = ur_rsp = 0;
stage = 0;
+ estack = -1;
panic_task = tt->panic_task == bt->task ? TRUE : FALSE;
@@ -2372,7 +2373,7 @@ next_stack:
return;
}
- if ((stage == 2) &&
+ if ((estack >= 0) &&
(STREQ(sym, "nmi_watchdog_tick") ||
STREQ(sym, "default_do_nmi"))) {
sp = x86_64_function_called_by((*up)-5);
@@ -2444,25 +2445,30 @@ skip_stage:
bt->stackbase = ms->stkinfo.ibase[bt->tc->processor];
bt->stacktop = ms->stkinfo.ibase[bt->tc->processor] +
ms->stkinfo.isize;
+ console("x86_64_get_dumpfile_stack_frame: searching IRQ stack at %lx\n",
+ bt->stackbase);
bt->stackbuf = ms->irqstack;
alter_stackbuf(bt);
stage = 1;
goto next_stack;
/*
- * Check the NMI exception stack.
+ * Check the exception stacks.
*/
case 1:
- bt->stackbase = ms->stkinfo.ebase[bt->tc->processor][NMI_STACK];
- bt->stacktop = ms->stkinfo.ebase[bt->tc->processor][NMI_STACK] +
- ms->stkinfo.esize;
+ if (++estack == 7)
+ break;
+ bt->stackbase = ms->stkinfo.ebase[bt->tc->processor][estack];
+ bt->stacktop = ms->stkinfo.ebase[bt->tc->processor][estack] +
+ ms->stkinfo.esize;
+ console("x86_64_get_dumpfile_stack_frame: searching %s estack at %lx\n",
+ x86_64_exception_stacks[estack], bt->stackbase);
+ if (!(bt->stackbase))
+ goto skip_stage;
bt->stackbuf = ms->irqstack;
alter_stackbuf(bt);
- stage = 2;
goto next_stack;
- case 2:
- break;
}
/*
18 years, 11 months
crash version 4.0-2.15 is available
by Dave Anderson
- Applied Kurt Rader's (kdrader(a)us.ibm.com) patch for SUSE SLES 9
"bigsmp" kernel LKCD dumpfiles, to fix "conflicting page" abort
caused by a dumpfile header that is larger than the formerly
hard-wired header size.
- Fix for ppc64-only segmentation violation when running "bt" on the
panic task when run against a dumpfile created by the diskdump
facility's new compressed format.
18 years, 12 months
