[Crash-utility] crash warnings

[Badari Pulavarty]

On Tue, 2006-04-25 at 14:42 -0400, Dave Anderson wrote:
> 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().
> 

I did little more digging around :)

crash -d1 shows me

crash: get_netdump_panic_task: crashing_cpu: 1
crash: get_netdump_panic_task: failed
crash: get_active_set_panic_task: failed


Looking at get_netdump_panic_task(), there is no code to handle
EM_X86_64 ? I see checks for


                if (nd->elf64->e_machine == EM_386) {
		..
		} 
                if (nd->elf64->e_machine == EM_PPC64) {
		...
		}
		

Elf64_Ehdr:
                e_ident: \177ELF
      e_ident[EI_CLASS]: 2 (ELFCLASS64)
       e_ident[EI_DATA]: 1 (ELFDATA2LSB)
    e_ident[EI_VERSION]: 1 (EV_CURRENT)
      e_ident[EI_OSABI]: 0 (ELFOSABI_SYSV)
 e_ident[EI_ABIVERSION]: 0
                 e_type: 4 (ET_CORE)
              e_machine: 62 (EM_X86_64)
              e_version: 1 (EV_CURRENT)
                e_entry: 0
                e_phoff: 40
                e_shoff: 0
                e_flags: 0
               e_ehsize: 40
            e_phentsize: 38
                e_phnum: 5
            e_shentsize: 0
                e_shnum: 0
             e_shstrndx: 0