Re: BISECTED: Re: source line numbers with x86_64 modules?
by Dave Anderson
----- "Eric W. Biederman" <ebiederm(a)xmission.com> wrote:
> Dave Anderson <anderson(a)redhat.com> writes:
>
> > Actually it's not a problem with the vmlinux file, but rather with kernel
> > module object files. The crash utility has an embedded gdb module which
> > is invoked as "gdb vmlinux", and to get line numbers, the crash utility
> > simply uses the relevant built-in gdb function to get them. And line
> > numbers work fine with the base kernel code from the vmlinux file.
> >
> > The debuginfo data of kernel modules can be subsequently added to the
> > crash session by doing a gdb "add-symbol-file" command for any or all
> > kernel modules. But getting correct line number information for kernel
> > modules has been a crap-shoot in the past, depending upon architecture
> > and/or kernel version. For example, they don't work with 2.6.9-based
> > RHEL4 x86_64 kernel modules, but work fine with 2.6.18-based RHEL5 x86_64
> > kernels.
> >
> > Looking at Mike's suspect kernel patch list, I don't see anything that
> > would have any relationship to the issue. Perhaps there was a build tool
> > change during the same timeframe?
>
> It look like Mike just built a series of kernels and had a problem,
> which should preclude a tool change.
>
> That said. Does this feature of crash work in 2.6.29? If not is
> there enough interest to track this down, and fix it if it is a
> kernel bug?
>
> If we are going to be using these tools we need them working on the
> latest and greatest kernels, not some weird enterprise branch, for
> fuddy duddies.
Personally I don't know -- I am a fuddy duddy.
I have tinkered with at least 2.6.28-era vmlinux/vmcore pairs, but never
with any kernel modules thereof.
Dave
17 years
BISECTED: Re: source line numbers with x86_64 modules?
by Mike Snitzer
[I've trimmed the wide cc distribution that was inherited when I
forked a different thread]
On Mon, Jan 12, 2009 at 10:19 PM, Eric W. Biederman
<ebiederm(a)xmission.com> wrote:
> "Mike Snitzer" <snitzer(a)gmail.com> writes:
>>
>> Now if only I could fix line numbers when debugging crashes in x86_64
>> modules with the crash utility! :)
>
> It's a userspace problem...
>
> All of the little usability things are userspace problems.
>
> I won't claim that it is trivial because it is a userspace problem, at the same
> time there is no reason to wait for any kernel features to merge etc. Someone
> just has to scratch an itch and go fix it.
Yes, the crash utility (userspace) is clearly having problems getting
line number for symbols in x86_64 modules. But I finally took some
time to bisect the point in the kernel where the crash utility first
started to fail, it appears to be:
commit 7460ed2844ffad7141e30271c0c3da8336e66014
Author: john stultz <johnstul(a)us.ibm.com>
Date: Fri Feb 16 01:28:21 2007 -0800
[PATCH] time: x86_64: re-enable vsyscall support for x86_64
Cleanup and re-enable vsyscall gettimeofday using the generic clocksource
infrastructure.
[akpm(a)osdl.org: cleanup]
Signed-off-by: John Stultz <johnstul(a)us.ibm.com>
Cc: Ingo Molnar <mingo(a)elte.hu>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: Andi Kleen <ak(a)muc.de>
Cc: Roman Zippel <zippel(a)linux-m68k.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
arch/x86_64/Kconfig | 4 +
arch/x86_64/kernel/hpet.c | 6 ++
arch/x86_64/kernel/time.c | 6 --
arch/x86_64/kernel/tsc.c | 7 ++
arch/x86_64/kernel/vmlinux.lds.S | 28 ++++------
arch/x86_64/kernel/vsyscall.c | 119 ++++++++++++++++++++++---------------
include/asm-x86_64/proto.h | 2 -
include/asm-x86_64/timex.h | 1 -
include/asm-x86_64/vsyscall.h | 29 ++--------
9 files changed, 104 insertions(+), 98 deletions(-)
Here is the full bisect log:
git-bisect start
# good: [62d0cfcb27cf755cebdc93ca95dabc83608007cd] Linux 2.6.20
git-bisect good 62d0cfcb27cf755cebdc93ca95dabc83608007cd
# bad: [c8f71b01a50597e298dc3214a2f2be7b8d31170c] Linux 2.6.21-rc1
git-bisect bad c8f71b01a50597e298dc3214a2f2be7b8d31170c
# good: [574009c1a895aeeb85eaab29c235d75852b09eb8] Merge branch
'upstream' of git://ftp.linux-mips.org/pub/scm/upstream-linus
git-bisect good 574009c1a895aeeb85eaab29c235d75852b09eb8
# good: [087d7ecd5273b480d13f4309a159842700afe276] [POWERPC] mpic: set
IPIs to be per-CPU
git-bisect good 087d7ecd5273b480d13f4309a159842700afe276
# bad: [920841d8d1d61bc12b43f95a579a5374f6d98f81] Merge branch
'for-linus' of ssh://master.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6
git-bisect bad 920841d8d1d61bc12b43f95a579a5374f6d98f81
# bad: [892705a1e1b4d0f9f6c5ac57f777b8055525bf68] USB: kernel-doc fixes
git-bisect bad 892705a1e1b4d0f9f6c5ac57f777b8055525bf68
# good: [741673473a5b26497d5390f38d478362e27e22ad] i386 prepare for dyntick
git-bisect good 741673473a5b26497d5390f38d478362e27e22ad
# bad: [ef29498655b18d2bfd69048e20835d19333981ab] Merge
master.kernel.org:/pub/scm/linux/kernel/git/davej/cpufreq
git-bisect bad ef29498655b18d2bfd69048e20835d19333981ab
# bad: [bec50c47aaf6f1f9247f1860547ab394a0802a4c] knfsd: nfsd4: acls:
avoid unnecessary denies
git-bisect bad bec50c47aaf6f1f9247f1860547ab394a0802a4c
# bad: [7460ed2844ffad7141e30271c0c3da8336e66014] time: x86_64:
re-enable vsyscall support for x86_64
git-bisect bad 7460ed2844ffad7141e30271c0c3da8336e66014
# good: [289f480af87e45f7a6de6ba9b4c061c2e259fe98] Add debugging
feature /proc/timer_list
git-bisect good 289f480af87e45f7a6de6ba9b4c061c2e259fe98
# good: [2d0c87c3bc49c60ab5bbac401fb1ef37ff10bbe2] time: x86_64:
hpet_address cleanup
git-bisect good 2d0c87c3bc49c60ab5bbac401fb1ef37ff10bbe2
# good: [1489939f0ab64b96998e04068c516c39afe29654] time: x86_64:
convert x86_64 to use GENERIC_TIME
git-bisect good 1489939f0ab64b96998e04068c516c39afe29654
I used version 4.0-7.6 of the crash utility to test if each commit was
good or bad. I simply checked if ext3's module had correct line
number info for the ext3_get_blocks_handle symbol with: sym
ext3_get_blocks_handle
I tried to revert 7460ed2844ffad7141e30271c0c3da8336e66014 from
v2.6.21 but it had conflicts that I've not yet been able to put
adequate time to resolving.
That aside, I'd be very interested to know how/where this commit is
impacting the crash utility. Has alignment of some module metadata
structure been altered and that is the problem? This isn't my area of
expertise but I have to believe others may have useful insight.
Thanks,
Mike
17 years
netdump issue
by Anirudh Srinivasan
Hi dave and all
Finally worked , i am must really say thanks to dave and the rest of the
people . Its like i was working on this for like 2 weeks and now i feel
relaxed.
Thanks again for all your help folks
Cheers
--
Anirudh Srinivasan
17 years
netdump issue
by Anirudh Srinivasan
Hi dave and all
As i have said to you previously the netdump server i am using is version
redhat 5 , and the netdump client version is a AS 3 redhat.
Now i have reached a stage where i am having the vmcore file of a crashed AS
3 redhat and i am going to run my crash utility on the netdump server
version 5 . I have installed the kernel-debuginfo.2.4.21.40.EL.i686.rpm
which is equvivalent to the crashed kernel version AS 3 .
Dave, as you suggested to look for and execute
crash <path-to>/vmlinux-2.4.21-40.ELsmp
<path-to>/vmlinux-2.4.21-40.ELsmp.debug <path-to>/vmcore
But the fact is i dont have /boot/vmlinux-2.4.21-40.ELsmp , instead i have
/boot/vmlinuz-2.6.18-8.el5 , which make sence because its a redhat version 5
machine.
SO do i need to install secondary kernel version that match the crashed
version?
So what i presume from this is that crash utility can be run on the machine
which run the same version as that of the crashed version .
Is that right or am i wrong , i dont know.
Where do i go from here . Waiting eagerly for a reply .
Regards
--
Anirudh Srinivasan
17 years
Re: [Crash-utility] RE:netdump issue
by Dave Anderson
----- "Anirudh Srinivasan" <srianirudh(a)gmail.com> wrote:
> Hi
>
>
> I have /boot/vmlinuz-2.6.18-8.el5 but not
> /boot/vmlinux-2.4.21-40.ELsmp , and let me make one point clear i have
> rhel version 5 as the netdump server , and the client server that was
> crashed is a version 3 rhel. Dave that so kind of you for a good
> suggestion . But is there any other way i can achieve this.
The fact that the netdump server is running on a RHEL5 machine is irrelevant.
The fact that you mention that you have "/boot/vmlinuz-2.6.18-8.el5" (RHEL%)
leads me to believe that you are looking for the RHEL3 vmlinux file on the
RHEL5 netdump-server instead of on the RHEL3 machine that crashed.
Again, what you need to analyze the RHEL3 vmcore is:
(1) the stripped vmlinux-<release> from the installed kernel package, which in
your case would be: kernel-smp-2.4.21-40.EL.i686.rpm.
(2) its associated vmlinux-<release>.debug from the kernel debuginfo package,
which in your case would be: kernel-debuginfo-2.4.21-40.EL.i686.rpm.
In RHEL3, the stripped vmlinux-<release> file is installed in /boot.
Although, that file is not actually booted -- what actually gets booted is
the vmlinuz-<release> file (with a 'z').
So anyway, the RHEL3 system that crashed was running the 2.4.21.40 kernel
package. Accordingly, the stripped vmlinux-<release> file and the bootable
vmlinuz-<release> file are *both* contained in that package:
$ rpm -qpl kernel-smp-2.4.21-40.EL.i686.rpm | grep -e vmlinux -e vmlinuz
/boot/vmlinux-2.4.21-40.ELsmp
/boot/vmlinuz-2.4.21-40.ELsmp
$
So, look in /boot on the RHEL3 client for the stripped vmlinux-<release>
file. If it's not there, find the kernel-smp-2.4.21-40.EL.i686.rpm binary
package that was installed on the system and extract the stripped vmlinux file.
Dave
17 years
RE:netdump issue
by Anirudh Srinivasan
Hi
I have /boot/vmlinuz-2.6.18-8.el5 but not /boot/vmlinux-2.4.21-40.ELsmp ,
and let me make one point clear i have rhel version 5 as the netdump server
, and the client server that was crashed is a version 3 rhel. Dave that so
kind of you for a good suggestion . But is there any other way i can achieve
this.
Thank you
Regards
--
Anirudh Srinivasan
17 years
Re: Crash-utility Digest, Vol 40, Issue 11
by Anirudh Srinivasan
Yes the netdump server is rhel 5 . As you suggested , i downloaded the rpm
kernel-debuginfo.2.4.21.40.EL.i686.rpm
and found
/usr/lib/debug/boot/vmlinux-2.4.21-40.EL.debug
/usr/lib/debug/boot/vmlinux-2.4.21-40.ELhugemem.debug
/usr/lib/debug/boot/vmlinux-2.4.21-40.ELsmp.debug
Upon running the crash on vmcore now this is what i get :
[root@dump 10.21.14.175-2009-01-22-14:00]# crash
/usr/lib/debug/boot/vmlinux-2.4.21-40.ELsmp.debug
/var/crash/10.21.14.175-2009-01-22-14\:00/vmcore
crash 4.0-3.14
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.
crash: /usr/lib/debug/boot/vmlinux-2.4.21-40.ELsmp.debug: no text and data
contents
crash: The namelist argument supplied in this case is a debuginfo file,
which must be accompanied by the kernel file from which it was derived.
I need further help to proceed with this as i am new to rhel , kidly help me
guide through this. I know close to achieve this just that i need some
proper guidance.
Regards
On Fri, Jan 23, 2009 at 10:35 AM, <crash-utility-request(a)redhat.com> wrote:
> Send Crash-utility mailing list submissions to
> crash-utility(a)redhat.com
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://www.redhat.com/mailman/listinfo/crash-utility
> or, via email, send a message with subject or body 'help' to
> crash-utility-request(a)redhat.com
>
> You can reach the person managing the list at
> crash-utility-owner(a)redhat.com
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Crash-utility digest..."
>
>
> Today's Topics:
>
> 1. netdump issue (Anirudh Srinivasan)
> 2. RE: netdump issue (Vaughn Clinton)
> 3. Re: netdump issue (Dave Anderson)
> 4. Re: netdump issue (Jeff Moyer)
> 5. [PATCH] crash: unwind with LKCD_KERNTYPES (Cliff Wickman)
> 6. Re: [PATCH] crash: unwind with LKCD_KERNTYPES (Dave Anderson)
> 7. Fwd: [PATCH] crash: unwind with LKCD_KERNTYPES (Dave Anderson)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 22 Jan 2009 16:23:19 -0500
> From: Anirudh Srinivasan <srianirudh(a)gmail.com>
> Subject: [Crash-utility] netdump issue
> To: crash-utility(a)redhat.com
> Message-ID:
> <699b436a0901221323h2d6f0c13u1490a27235a7f776(a)mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> I am implementing a netdump . I crashed one sever and got the vmcore file
> in
> /var/crash/vmcore , then i checked the kernel version through
>
> strings vmcore | fgrep -m1 'Linux'
> Linux version 2.4.21-40.ELsmp (bhcompile(a)hs20-bc1-7.build.redhat.com) (gcc
> version 3.2.3 20030502 (Red Hat Linux 3.2.3-54)) #1 SMP Thu Feb 2 22:22:39
> EST 2006
> So now while installing the kernel-debuginfo , it should match the version
> above i.e something like "kernel-debuginfo.2.4.21.40.ELsmp.i368.rpm"
>
> But i installed the closest one and that was
> kernel-debuginfo.2.4.21.40.EL.i386.rpm but after installing them i should
> have /usr/lib/debug/module/vmlinux , which i could'nt see them .
>
> Can anyone give me the link to the rpm i am looking for , or suggest some
> idea. ( the server that i am dumping vmcore is version 5 )
> I have bunch of server with version 2 and version 3 and version 4 in my
> production environment for which i have to configure netdump to collect the
> vmcore in version 5 server .
> --
>
> Regards
> Anirudh Srinivasan
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> https://www.redhat.com/archives/crash-utility/attachments/20090122/45ea77...
>
> ------------------------------
>
> Message: 2
> Date: Thu, 22 Jan 2009 14:27:56 -0700
> From: Vaughn Clinton <vclinton(a)msn.com>
> Subject: RE: [Crash-utility] netdump issue
> To: <crash-utility(a)redhat.com>
> Message-ID: <BAY103-W660A296BC102A4E779286CECE0(a)phx.gbl>
> Content-Type: text/plain; charset="iso-8859-1"
>
>
> Version 5 servers now use kexec with a kdump facility mechanism that will
> allow for remote dumping of the core. I'm not sure if netdump is
> functionally supported in your version of the kernel.
>
> Cheers,
>
> Date: Thu, 22 Jan 2009 16:23:19 -0500
> From: srianirudh(a)gmail.com
> To: crash-utility(a)redhat.com
> Subject: [Crash-utility] netdump issue
>
> I am implementing a netdump . I crashed one sever and got the vmcore file
> in /var/crash/vmcore , then i checked the kernel version through
>
> strings vmcore | fgrep -m1 'Linux'
> Linux version 2.4.21-40.ELsmp (bhcompile(a)hs20-bc1-7.build.redhat.com) (gcc
> version 3.2.3 20030502 (Red Hat Linux 3.2.3-54)) #1 SMP Thu Feb 2 22:22:39
> EST 2006
>
>
> So now while installing the kernel-debuginfo , it should match the version
> above i.e something like "kernel-debuginfo.2.4.21.40.ELsmp.i368.rpm"
>
> But i installed the closest one and that was
> kernel-debuginfo.2.4.21.40.EL.i386.rpm but after installing them i should
> have /usr/lib/debug/module/vmlinux , which i could'nt see them .
>
> Can anyone give me the link to the rpm i am looking for , or suggest some
> idea. ( the server that i am dumping vmcore is version 5 )
> I have bunch of server with version 2 and version 3 and version 4 in my
> production environment for which i have to configure netdump to collect the
> vmcore in version 5 server .
> --
>
> Regards
> Anirudh Srinivasan
>
>
> _________________________________________________________________
> Invite your mail contacts to join your friends list with Windows Live
> Spaces. It's easy!
>
> http://spaces.live.com/spacesapi.aspx?wx_action=create&wx_url=/friends.as...
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> https://www.redhat.com/archives/crash-utility/attachments/20090122/d22dc3...
>
> ------------------------------
>
> Message: 3
> Date: Thu, 22 Jan 2009 17:01:34 -0500 (EST)
> From: Dave Anderson <anderson(a)redhat.com>
> Subject: Re: [Crash-utility] netdump issue
> To: "Discussion list for crash utility usage, maintenance and
> development" <crash-utility(a)redhat.com>
> Message-ID:
> <
> 393446605.1264831232661693989.JavaMail.root(a)zmail02.collab.prod.int.phx2.redhat.com
> >
>
> Content-Type: text/plain; charset=utf-8
>
>
> ----- "Anirudh Srinivasan" <srianirudh(a)gmail.com> wrote:
>
> > I am implementing a netdump . I crashed one sever and got the vmcore
> > file in /var/crash/vmcore , then i checked the kernel version through
> >
> > strings vmcore | fgrep -m1 'Linux'
> > Linux version 2.4.21-40.ELsmp ( bhcompile(a)hs20-bc1-7.build.redhat.com
> > ) (gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-54)) #1 SMP Thu Feb
> > 2 22:22:39 EST 2006
> >
> > So now while installing the kernel-debuginfo , it should match the
> > version above i.e something like
> > "kernel-debuginfo.2.4.21.40.ELsmp.i368.rpm"
> >
> > But i installed the closest one and that was
> > kernel-debuginfo.2.4.21.40.EL.i386.rpm but after installing them i
> > should have /usr/lib/debug/module/vmlinux , which i could'nt see them
> > .
>
> OK, so you're running -- and have crashed -- a RHEL3 i686 smp kernel,
> and the vmcore pinpoints the version as version 2.4.21-40.ELsmp. So
> you need to install the kernel-debuginfo-2.4.21-40.EL.i686.rpm (not
> the "i386" version), which contains the vmlinux debug files for that
> kernel version:
>
> $ rpm -qpl kernel-debuginfo-2.4.21-40.EL.i686.rpm | grep vmlinux
> /usr/lib/debug/boot/vmlinux-2.4.21-40.EL.debug
> /usr/lib/debug/boot/vmlinux-2.4.21-40.ELhugemem.debug
> /usr/lib/debug/boot/vmlinux-2.4.21-40.ELsmp.debug
> $
>
> And the relevant file in your case would be located in
> /usr/lib/debug/boot/vmlinux-2.4.21-40.ELsmp.debug.
>
> >
> > Can anyone give me the link to the rpm i am looking for , or suggest
> > some idea. ( the server that i am dumping vmcore is version 5 )
> >
> > I have bunch of server with version 2 and version 3 and version 4 in
> > my production environment for which i have to configure netdump to
> > collect the vmcore in version 5 server .
>
> That's fine -- one way you can get the specific debuginfo package
> you need is by going to my people page:
>
> http://people.redhat.com/anderson
>
> 1. Click on the "Red Hat Enterprise Linux debuginfo RPMs" link.
> 2. On that next page, in the "Red Hat Enterprise Linux 3" box,
> click on the "AS: i386" link.
>
> That will bring you to the ftp site that contains *all* RHEL3
> packages, so you have to search for:
>
> kernel-debuginfo-2.4.21-40.EL.i686.rpm
>
> Again, make sure you get the "i686" version.
>
> Hope this helps,
> Dave
>
>
>
>
>
> ------------------------------
>
> Message: 4
> Date: Thu, 22 Jan 2009 17:09:57 -0500
> From: Jeff Moyer <jmoyer(a)redhat.com>
> Subject: Re: [Crash-utility] netdump issue
> To: "Discussion list for crash utility usage\, maintenance and
> development" <crash-utility(a)redhat.com>
> Message-ID: <x49sknbdmbu.fsf(a)segfault.boston.devel.redhat.com>
> Content-Type: text/plain; charset=us-ascii
>
> Anirudh Srinivasan <srianirudh(a)gmail.com> writes:
>
> > I am implementing a netdump . I crashed one sever and got the vmcore file
> in
> > /var/crash/vmcore , then i checked the kernel version through
> >
> > strings vmcore | fgrep -m1 'Linux'
> > Linux version 2.4.21-40.ELsmp (bhcompile(a)hs20-bc1-7.build.redhat.com)
> (gcc
> > version 3.2.3 20030502 (Red Hat Linux 3.2.3-54)) #1 SMP Thu Feb 2
> 22:22:39
> > EST 2006
> > So now while installing the kernel-debuginfo , it should match the
> version
> > above i.e something like "kernel-debuginfo.2.4.21.40.ELsmp.i368.rpm"
> >
> > But i installed the closest one and that was
> > kernel-debuginfo.2.4.21.40.EL.i386.rpm but after installing them i should
> > have /usr/lib/debug/module/vmlinux , which i could'nt see them .
>
> Not quite right. If you do:
>
> # rpm -qpl kernel-debuginfo-2.4.21-40.EL.i686.rpm | grep vmlinux
>
> you'll see:
>
> /usr/lib/debug/boot/vmlinux-2.4.21-40.EL.debug
> /usr/lib/debug/boot/vmlinux-2.4.21-40.ELhugemem.debug
> /usr/lib/debug/boot/vmlinux-2.4.21-40.ELsmp.debug
>
> You, of course, want the smp version. I'm assuming you want to examine
> the core file with crash. If so, something like the following should
> work:
>
> crash /usr/lib/debug/boot/vmlinux-2.4.21-40.ELsmp.debug /path/to/vmcore
>
> > Can anyone give me the link to the rpm i am looking for , or suggest some
> > idea. ( the server that i am dumping vmcore is version 5 )
>
> You mean the netdump server is running on a RHEL 5 system? That is
> fine.
>
> > I have bunch of server with version 2 and version 3 and version 4 in my
> > production environment for which i have to configure netdump to collect
> the
> > vmcore in version 5 server .
>
> Right, running the netdump server on a RHEL 5 system is fine. You
> should have no problems collecting vmcores from your AS 2.1, RHEL 3 and
> RHEL 4 systems.
>
> Cheers,
> Jeff
>
>
>
> ------------------------------
>
> Message: 5
> Date: Thu, 22 Jan 2009 17:23:44 -0600
> From: Cliff Wickman <cpw(a)sgi.com>
> Subject: [Crash-utility] [PATCH] crash: unwind with LKCD_KERNTYPES
> To: crash-utility(a)redhat.com
> Message-ID: <E1LQ8tk-0002yp-6Q(a)eag09.americas.sgi.com>
>
>
>
>
> This patch enables stack unwind (on ia64) when using a kerntypes
> file for a namelist.
>
> When using a kerntypes file, we have just the address of variable unw
> and the definition of an unw structure.
>
> As you can see, I didn't change the indentation of the normal code.
> Simple to do, but I didn't want to clutter this patch for a first pass.
>
> I tested this against a live 2.6.16 (sles) kernel.
> Diffed against crash-4.0-7.6
>
> Signed-off-by: Cliff Wickman <cpw(a)sgi.com>
>
> ---
> unwind.c | 34 ++++++++++++++++++++++++++++++++++
> 1 file changed, 34 insertions(+)
>
> Index: crash-4.0-7.6.ia64/unwind.c
> ===================================================================
> --- crash-4.0-7.6.ia64.orig/unwind.c
> +++ crash-4.0-7.6.ia64/unwind.c
> @@ -1395,10 +1395,43 @@ unwind_init_v2(void)
> unwind_init_v3(void)
> #endif
> {
> + int len;
> struct gnu_request request, *req;
>
> req = &request;
>
> + if (LKCD_KERNTYPES()) {
> + if ((len = STRUCT_SIZE("unw")) == 0) {
> + error(WARNING,
> + "cannot determine unw.tables offset; no struct
> unw\n");
> + machdep->flags |= UNW_OUT_OF_SYNC;
> + return;
> + }
> + machdep->machspec->unw_tables_offset =
> + MEMBER_OFFSET("unw", "tables");
> + if (MEMBER_EXISTS("unw", "r0"))
> + machdep->flags |= UNW_R0;
> + /*
> + * no verification of save_order, sw_off, preg_index as
> + * we're purely depending on the structure definition.
> + */
> + if (MEMBER_EXISTS("unw", "pt_regs_offsets")) {
> + machdep->machspec->unw_pt_regs_offsets =
> + MEMBER_OFFSET("unw", "pt_regs_offsets") -
> + machdep->machspec->unw_tables_offset;
> + machdep->machspec->unw_kernel_table_offset =
> + MEMBER_OFFSET("unw", "kernel_table") -
> + machdep->machspec->unw_tables_offset;
> + machdep->flags |= UNW_PTREGS;
> + }
> + if (!load_unw_table(CLEAR_SCRIPT_CACHE)) {
> + error(WARNING,
> + "unwind_init: cannot read kernel unw
> table\n");
> + machdep->flags |= UNW_OUT_OF_SYNC;
> + }
> + machdep->machspec->unw = (void *)&unw;
> + /* fall to common structure size verifications */
> + } else {
> if (get_symbol_type("unw", "tables", req) == TYPE_CODE_UNDEF) {
> /*
> * KLUDGE ALERT:
> @@ -1449,6 +1482,7 @@ unwind_init_v3(void)
>
> machdep->machspec->unw = (void *)&unw;
> }
> + }
>
> verify_common_struct("unw_frame_info", sizeof(struct
> unw_frame_info));
> verify_common_struct("unw_table", sizeof(struct unw_table));
>
>
>
> ------------------------------
>
> Message: 6
> Date: Fri, 23 Jan 2009 10:09:30 -0500 (EST)
> From: Dave Anderson <anderson(a)redhat.com>
> Subject: [Crash-utility] Re: [PATCH] crash: unwind with LKCD_KERNTYPES
> To: Cliff Wickman <cpw(a)sgi.com>
> Cc: crash-utility(a)redhat.com
> Message-ID:
> <
> 2143976042.1441431232723370347.JavaMail.root(a)zmail02.collab.prod.int.phx2.redhat.com
> >
>
> Content-Type: text/plain; charset=utf-8
>
>
> ----- "Cliff Wickman" <cpw(a)sgi.com> wrote:
>
> > This patch enables stack unwind (on ia64) when using a kerntypes
> > file for a namelist.
> >
> > When using a kerntypes file, we have just the address of variable unw
> > and the definition of an unw structure.
> >
> > As you can see, I didn't change the indentation of the normal code.
>
> Nicely segregated. But instead of leaving the indentation screwed up,
> I just inserted a "goto verify" at the bottom of your if statement and
> put the label at the proper location.
>
> > Simple to do, but I didn't want to clutter this patch for a first
> > pass.
>
> With that in place, should I just take the patch for the next release,
> or did you have something else you want to add?
>
> Dave
>
>
> >
> > ---
> > unwind.c | 34 ++++++++++++++++++++++++++++++++++
> > 1 file changed, 34 insertions(+)
> >
> > Index: crash-4.0-7.6.ia64/unwind.c
> > ===================================================================
> > --- crash-4.0-7.6.ia64.orig/unwind.c
> > +++ crash-4.0-7.6.ia64/unwind.c
> > @@ -1395,10 +1395,43 @@ unwind_init_v2(void)
> > unwind_init_v3(void)
> > #endif
> > {
> > + int len;
> > struct gnu_request request, *req;
> >
> > req = &request;
> >
> > + if (LKCD_KERNTYPES()) {
> > + if ((len = STRUCT_SIZE("unw")) == 0) {
> > + error(WARNING,
> > + "cannot determine unw.tables offset; no struct
> unw\n");
> > + machdep->flags |= UNW_OUT_OF_SYNC;
> > + return;
> > + }
> > + machdep->machspec->unw_tables_offset =
> > + MEMBER_OFFSET("unw", "tables");
> > + if (MEMBER_EXISTS("unw", "r0"))
> > + machdep->flags |= UNW_R0;
> > + /*
> > + * no verification of save_order, sw_off, preg_index as
> > + * we're purely depending on the structure definition.
> > + */
> > + if (MEMBER_EXISTS("unw", "pt_regs_offsets")) {
> > + machdep->machspec->unw_pt_regs_offsets =
> > + MEMBER_OFFSET("unw", "pt_regs_offsets") -
> > + machdep->machspec->unw_tables_offset;
> > + machdep->machspec->unw_kernel_table_offset =
> > + MEMBER_OFFSET("unw", "kernel_table") -
> > + machdep->machspec->unw_tables_offset;
> > + machdep->flags |= UNW_PTREGS;
> > + }
> > + if (!load_unw_table(CLEAR_SCRIPT_CACHE)) {
> > + error(WARNING,
> > + "unwind_init: cannot read kernel unw
> table\n");
> > + machdep->flags |= UNW_OUT_OF_SYNC;
> > + }
> > + machdep->machspec->unw = (void *)&unw;
> > + /* fall to common structure size verifications */
> > + } else {
> > if (get_symbol_type("unw", "tables", req) == TYPE_CODE_UNDEF)
> > {
> > /*
> > * KLUDGE ALERT:
> > @@ -1449,6 +1482,7 @@ unwind_init_v3(void)
> >
> > machdep->machspec->unw = (void *)&unw;
> > }
> > + }
> >
> > verify_common_struct("unw_frame_info", sizeof(struct
> > unw_frame_info));
> > verify_common_struct("unw_table", sizeof(struct unw_table));
>
>
>
> ------------------------------
>
> Message: 7
> Date: Fri, 23 Jan 2009 10:35:06 -0500 (EST)
> From: Dave Anderson <anderson(a)redhat.com>
> Subject: [Crash-utility] Fwd: [PATCH] crash: unwind with
> LKCD_KERNTYPES
> To: "Discussion list for crash utility usage, maintenance and
> development" <crash-utility(a)redhat.com>
> Message-ID:
> <
> 947707277.1449411232724906430.JavaMail.root(a)zmail02.collab.prod.int.phx2.redhat.com
> >
>
> Content-Type: text/plain; charset=utf-8
>
>
> ----- Forwarded Message -----
> From: "Cliff Wickman" <cpw(a)sgi.com>
> To: "Dave Anderson" <anderson(a)redhat.com>
> Sent: Friday, January 23, 2009 10:30:49 AM GMT -05:00 US/Canada Eastern
> Subject: Re: [PATCH] crash: unwind with LKCD_KERNTYPES
>
> Hi Dave,
>
> On Fri, Jan 23, 2009 at 10:09:30AM -0500, Dave Anderson wrote:
> >
> > ----- "Cliff Wickman" <cpw(a)sgi.com> wrote:
> >
> > > This patch enables stack unwind (on ia64) when using a kerntypes
> > > file for a namelist.
> > >
> > > When using a kerntypes file, we have just the address of variable unw
> > > and the definition of an unw structure.
> > >
> > > As you can see, I didn't change the indentation of the normal code.
> >
> > Nicely segregated. But instead of leaving the indentation screwed up,
> > I just inserted a "goto verify" at the bottom of your if statement and
> > put the label at the proper location.
> >
> > > Simple to do, but I didn't want to clutter this patch for a first
> > > pass.
> >
> > With that in place, should I just take the patch for the next release,
> > or did you have something else you want to add?
>
> Sounds good. I have nothing more to add. Thanks.
>
> -Cliff
> >
> > Dave
> >
> >
> > >
> > > ---
> > > unwind.c | 34 ++++++++++++++++++++++++++++++++++
> > > 1 file changed, 34 insertions(+)
> > >
> > > Index: crash-4.0-7.6.ia64/unwind.c
> > > ===================================================================
> > > --- crash-4.0-7.6.ia64.orig/unwind.c
> > > +++ crash-4.0-7.6.ia64/unwind.c
> > > @@ -1395,10 +1395,43 @@ unwind_init_v2(void)
> > > unwind_init_v3(void)
> > > #endif
> > > {
> > > + int len;
> > > struct gnu_request request, *req;
> > >
> > > req = &request;
> > >
> > > + if (LKCD_KERNTYPES()) {
> > > + if ((len = STRUCT_SIZE("unw")) == 0) {
> > > + error(WARNING,
> > > + "cannot determine unw.tables offset; no struct
> unw\n");
> > > + machdep->flags |= UNW_OUT_OF_SYNC;
> > > + return;
> > > + }
> > > + machdep->machspec->unw_tables_offset =
> > > + MEMBER_OFFSET("unw", "tables");
> > > + if (MEMBER_EXISTS("unw", "r0"))
> > > + machdep->flags |= UNW_R0;
> > > + /*
> > > + * no verification of save_order, sw_off, preg_index as
> > > + * we're purely depending on the structure definition.
> > > + */
> > > + if (MEMBER_EXISTS("unw", "pt_regs_offsets")) {
> > > + machdep->machspec->unw_pt_regs_offsets =
> > > + MEMBER_OFFSET("unw", "pt_regs_offsets") -
> > > + machdep->machspec->unw_tables_offset;
> > > + machdep->machspec->unw_kernel_table_offset =
> > > + MEMBER_OFFSET("unw", "kernel_table") -
> > > + machdep->machspec->unw_tables_offset;
> > > + machdep->flags |= UNW_PTREGS;
> > > + }
> > > + if (!load_unw_table(CLEAR_SCRIPT_CACHE)) {
> > > + error(WARNING,
> > > + "unwind_init: cannot read kernel unw
> table\n");
> > > + machdep->flags |= UNW_OUT_OF_SYNC;
> > > + }
> > > + machdep->machspec->unw = (void *)&unw;
> > > + /* fall to common structure size verifications */
> > > + } else {
> > > if (get_symbol_type("unw", "tables", req) == TYPE_CODE_UNDEF)
> > > {
> > > /*
> > > * KLUDGE ALERT:
> > > @@ -1449,6 +1482,7 @@ unwind_init_v3(void)
> > >
> > > machdep->machspec->unw = (void *)&unw;
> > > }
> > > + }
> > >
> > > verify_common_struct("unw_frame_info", sizeof(struct
> > > unw_frame_info));
> > > verify_common_struct("unw_table", sizeof(struct unw_table));
>
> --
> Cliff Wickman
> Silicon Graphics, Inc.
> cpw(a)sgi.com
> (651) 683-3824
>
>
>
> ------------------------------
>
> --
> Crash-utility mailing list
> Crash-utility(a)redhat.com
> https://www.redhat.com/mailman/listinfo/crash-utility
>
>
> End of Crash-utility Digest, Vol 40, Issue 11
> *********************************************
>
--
Anirudh Srinivasan
17 years
Fwd: [PATCH] crash: unwind with LKCD_KERNTYPES
by Dave Anderson
----- Forwarded Message -----
From: "Cliff Wickman" <cpw(a)sgi.com>
To: "Dave Anderson" <anderson(a)redhat.com>
Sent: Friday, January 23, 2009 10:30:49 AM GMT -05:00 US/Canada Eastern
Subject: Re: [PATCH] crash: unwind with LKCD_KERNTYPES
Hi Dave,
On Fri, Jan 23, 2009 at 10:09:30AM -0500, Dave Anderson wrote:
>
> ----- "Cliff Wickman" <cpw(a)sgi.com> wrote:
>
> > This patch enables stack unwind (on ia64) when using a kerntypes
> > file for a namelist.
> >
> > When using a kerntypes file, we have just the address of variable unw
> > and the definition of an unw structure.
> >
> > As you can see, I didn't change the indentation of the normal code.
>
> Nicely segregated. But instead of leaving the indentation screwed up,
> I just inserted a "goto verify" at the bottom of your if statement and
> put the label at the proper location.
>
> > Simple to do, but I didn't want to clutter this patch for a first
> > pass.
>
> With that in place, should I just take the patch for the next release,
> or did you have something else you want to add?
Sounds good. I have nothing more to add. Thanks.
-Cliff
>
> Dave
>
>
> >
> > ---
> > unwind.c | 34 ++++++++++++++++++++++++++++++++++
> > 1 file changed, 34 insertions(+)
> >
> > Index: crash-4.0-7.6.ia64/unwind.c
> > ===================================================================
> > --- crash-4.0-7.6.ia64.orig/unwind.c
> > +++ crash-4.0-7.6.ia64/unwind.c
> > @@ -1395,10 +1395,43 @@ unwind_init_v2(void)
> > unwind_init_v3(void)
> > #endif
> > {
> > + int len;
> > struct gnu_request request, *req;
> >
> > req = &request;
> >
> > + if (LKCD_KERNTYPES()) {
> > + if ((len = STRUCT_SIZE("unw")) == 0) {
> > + error(WARNING,
> > + "cannot determine unw.tables offset; no struct unw\n");
> > + machdep->flags |= UNW_OUT_OF_SYNC;
> > + return;
> > + }
> > + machdep->machspec->unw_tables_offset =
> > + MEMBER_OFFSET("unw", "tables");
> > + if (MEMBER_EXISTS("unw", "r0"))
> > + machdep->flags |= UNW_R0;
> > + /*
> > + * no verification of save_order, sw_off, preg_index as
> > + * we're purely depending on the structure definition.
> > + */
> > + if (MEMBER_EXISTS("unw", "pt_regs_offsets")) {
> > + machdep->machspec->unw_pt_regs_offsets =
> > + MEMBER_OFFSET("unw", "pt_regs_offsets") -
> > + machdep->machspec->unw_tables_offset;
> > + machdep->machspec->unw_kernel_table_offset =
> > + MEMBER_OFFSET("unw", "kernel_table") -
> > + machdep->machspec->unw_tables_offset;
> > + machdep->flags |= UNW_PTREGS;
> > + }
> > + if (!load_unw_table(CLEAR_SCRIPT_CACHE)) {
> > + error(WARNING,
> > + "unwind_init: cannot read kernel unw table\n");
> > + machdep->flags |= UNW_OUT_OF_SYNC;
> > + }
> > + machdep->machspec->unw = (void *)&unw;
> > + /* fall to common structure size verifications */
> > + } else {
> > if (get_symbol_type("unw", "tables", req) == TYPE_CODE_UNDEF)
> > {
> > /*
> > * KLUDGE ALERT:
> > @@ -1449,6 +1482,7 @@ unwind_init_v3(void)
> >
> > machdep->machspec->unw = (void *)&unw;
> > }
> > + }
> >
> > verify_common_struct("unw_frame_info", sizeof(struct
> > unw_frame_info));
> > verify_common_struct("unw_table", sizeof(struct unw_table));
--
Cliff Wickman
Silicon Graphics, Inc.
cpw(a)sgi.com
(651) 683-3824
17 years
[PATCH] crash: unwind with LKCD_KERNTYPES
by Cliff Wickman
This patch enables stack unwind (on ia64) when using a kerntypes
file for a namelist.
When using a kerntypes file, we have just the address of variable unw
and the definition of an unw structure.
As you can see, I didn't change the indentation of the normal code.
Simple to do, but I didn't want to clutter this patch for a first pass.
I tested this against a live 2.6.16 (sles) kernel.
Diffed against crash-4.0-7.6
Signed-off-by: Cliff Wickman <cpw(a)sgi.com>
---
unwind.c | 34 ++++++++++++++++++++++++++++++++++
1 file changed, 34 insertions(+)
Index: crash-4.0-7.6.ia64/unwind.c
===================================================================
--- crash-4.0-7.6.ia64.orig/unwind.c
+++ crash-4.0-7.6.ia64/unwind.c
@@ -1395,10 +1395,43 @@ unwind_init_v2(void)
unwind_init_v3(void)
#endif
{
+ int len;
struct gnu_request request, *req;
req = &request;
+ if (LKCD_KERNTYPES()) {
+ if ((len = STRUCT_SIZE("unw")) == 0) {
+ error(WARNING,
+ "cannot determine unw.tables offset; no struct unw\n");
+ machdep->flags |= UNW_OUT_OF_SYNC;
+ return;
+ }
+ machdep->machspec->unw_tables_offset =
+ MEMBER_OFFSET("unw", "tables");
+ if (MEMBER_EXISTS("unw", "r0"))
+ machdep->flags |= UNW_R0;
+ /*
+ * no verification of save_order, sw_off, preg_index as
+ * we're purely depending on the structure definition.
+ */
+ if (MEMBER_EXISTS("unw", "pt_regs_offsets")) {
+ machdep->machspec->unw_pt_regs_offsets =
+ MEMBER_OFFSET("unw", "pt_regs_offsets") -
+ machdep->machspec->unw_tables_offset;
+ machdep->machspec->unw_kernel_table_offset =
+ MEMBER_OFFSET("unw", "kernel_table") -
+ machdep->machspec->unw_tables_offset;
+ machdep->flags |= UNW_PTREGS;
+ }
+ if (!load_unw_table(CLEAR_SCRIPT_CACHE)) {
+ error(WARNING,
+ "unwind_init: cannot read kernel unw table\n");
+ machdep->flags |= UNW_OUT_OF_SYNC;
+ }
+ machdep->machspec->unw = (void *)&unw;
+ /* fall to common structure size verifications */
+ } else {
if (get_symbol_type("unw", "tables", req) == TYPE_CODE_UNDEF) {
/*
* KLUDGE ALERT:
@@ -1449,6 +1482,7 @@ unwind_init_v3(void)
machdep->machspec->unw = (void *)&unw;
}
+ }
verify_common_struct("unw_frame_info", sizeof(struct unw_frame_info));
verify_common_struct("unw_table", sizeof(struct unw_table));
17 years
netdump issue
by Anirudh Srinivasan
I am implementing a netdump . I crashed one sever and got the vmcore file in
/var/crash/vmcore , then i checked the kernel version through
strings vmcore | fgrep -m1 'Linux'
Linux version 2.4.21-40.ELsmp (bhcompile(a)hs20-bc1-7.build.redhat.com) (gcc
version 3.2.3 20030502 (Red Hat Linux 3.2.3-54)) #1 SMP Thu Feb 2 22:22:39
EST 2006
So now while installing the kernel-debuginfo , it should match the version
above i.e something like "kernel-debuginfo.2.4.21.40.ELsmp.i368.rpm"
But i installed the closest one and that was
kernel-debuginfo.2.4.21.40.EL.i386.rpm but after installing them i should
have /usr/lib/debug/module/vmlinux , which i could'nt see them .
Can anyone give me the link to the rpm i am looking for , or suggest some
idea. ( the server that i am dumping vmcore is version 5 )
I have bunch of server with version 2 and version 3 and version 4 in my
production environment for which i have to configure netdump to collect the
vmcore in version 5 server .
--
Regards
Anirudh Srinivasan
17 years