1:42 p.m.
Badari Pulavarty wrote:
Hi,
I get following crash warnings on x86-64 machine. Wondering why ?
And also, its not showing stacks correctly.
Thanks,
Badari
# ./crash /var/log/dump/2006-04-24-08:02/vmcore /usr/src/linux/vmlinux
crash 4.0-2.23
Copyright (C) 2002, 2003, 2004, 2005, 2006 Red Hat, Inc.
Copyright (C) 2004, 2005, 2006 IBM Corporation
Copyright (C) 1999-2006 Hewlett-Packard Co
Copyright (C) 2005 Fujitsu Limited
Copyright (C) 2005 NEC Corporation
Copyright (C) 1999, 2002 Silicon Graphics, Inc.
Copyright (C) 1999, 2000, 2001, 2002 Mission Critical Linux, Inc.
This program is free software, covered by the GNU General Public
License,
and you are welcome to change it and/or distribute copies of it under
certain conditions. Enter "help copying" to see the conditions.
This program has absolutely no warranty. Enter "help warranty" for
details.
GNU gdb 6.1
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "x86_64-unknown-linux-gnu"...
WARNING: possibly bogus exception frame
WARNING: possibly bogus exception frame
WARNING: possibly bogus exception frame
WARNING: possibly bogus exception frame
WARNING: possibly bogus exception frame
WARNING: possibly bogus exception frame
WARNING: possibly bogus exception frame
WARNING: possibly bogus exception frame
WARNING: possibly bogus exception frame
WARNING: possibly bogus exception frame
WARNING: possibly bogus exception frame
WARNING: possibly bogus exception frame
WARNING: possibly bogus exception frame
WARNING: possibly bogus exception frame
WARNING: possibly bogus exception frame
WARNING: possibly bogus exception frame
WARNING: possibly bogus exception frame
WARNING: possibly bogus exception frame
WARNING: possibly bogus exception frame
WARNING: possibly bogus exception frame
WARNING: possibly bogus exception frame
WARNING: possibly bogus exception frame
WARNING: possibly bogus exception frame
WARNING: possibly bogus exception frame
WARNING: possibly bogus exception frame
WARNING: possibly bogus exception frame
KERNEL: /usr/src/linux/vmlinux
DUMPFILE: /var/log/dump/2006-04-24-08:02/vmcore
CPUS: 2
DATE: Mon Apr 24 08:02:03 2006
UPTIME: 00:06:31
LOAD AVERAGE: 0.00, 0.00, 0.00
TASKS: 63
NODENAME: elm3a242
RELEASE: 2.6.16-20-smp
VERSION: #1 SMP Mon Apr 10 04:51:13 UTC 2006
MACHINE: x86_64 (3000 Mhz)
MEMORY: 4.6 GB
PANIC: "SysRq : Trigger a crashdump"
PID: 0
COMMAND: "swapper"
TASK: ffffffff80335340 (1 of 2) [THREAD_INFO:
ffffffff8045c000]
CPU: 0
STATE: TASK_RUNNING (ACTIVE)
crash> bt
PID: 0 TASK: ffffffff80335340 CPU: 0 COMMAND: "swapper"
#0 [ffffffff8045dee8] schedule at ffffffff802cf6fa
It's hard to debug this from here, but...
Two things look strange, (1) it's not finding the proper starting
point for the panicking (?) idle thread -- and possibly not even finding
the correct panic task, and (2) the "possibly bogus exception
frame" messages are due to the x86_64.c x86_64_eframe_verify()
function finding something irregular in the exception frames (the
pt_regs) of several processes while it made a search of all
possible processes for the panic task.
I would guess that if you do a "foreach bt", you will see the
"possibly bogus" messages associated with the user-space
exception frames of all user-space generated processes
(i.e. not kernel threads). It would be interesting to see what
those frames look like, and why they are considered strange,
probably a new cs or ss value that's never been used before?
As far as the determination of the panic task, I'm presuming
that this was generated from a kdump dumpfile. The netdump.c
get_netdump_panic_task() function, which has a bunch of
kdump-specific code, is failing to find the panic task from the
data in the ELF header notes. Running "crash -d1 ..." will indicate
how crash is trying to determine the panic task. I don't know
whether the idle task was even the one that took the sysrq,
or whether it just defaulted to that task because it couldn't find
any other likely suspects. You'll have to debug it from your
end, starting from get_netdump_panic_task().
Dave