[Crash-utility] crash warnings

[Dave Anderson]

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