FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Crash Utility

 
 
LinkBack Thread Tools
 
Old 04-24-2012, 05:58 AM
"Seymour, Shane M"
 
Default After feedback on crash patch

Hi,

I'd like to get crash changed to add a new option to the mod command in crash. If you've got a dump server and you've got debuginfo RPMs extracted for pretty much every RHEL/SLES release you can create a symlink in the same directory as the vmcore pointing to the correct namelist, for example:

vmlinux -> /debuginfo/x86_64/rhel5/2.6.18-164/usr/lib/debug/lib/modules/2.6.18-164.el5/vmlinux

I'd like to see the mod command automatically work out where the debug modules will be based upon the result of realpath(3) on the namelist then removing everything after /usr/lib/debug. I know that there's the "--mod directory" option but you've got to remember to run it all the time and if you've extracted the kernel debuginfo crash can easily work out where they are if you use either a full or relative path or symlink to the namelist. I don't know if anyone would prefer to see it implemented in a different way but rather than risk breaking something I didn't understand I added a new -t option instead (-t because it's similar to -S and t is the next available option after the letter s).

I've run it on a few dumps and it seems to be working correctly. All of the code changes are in kernel.c, help.c needed some changes just to add the help text. Any feedback would be appreciated.

Thanks
Shane
--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 
Old 04-24-2012, 02:54 PM
Dave Anderson
 
Default After feedback on crash patch

----- Original Message -----
> Hi,
>
> I'd like to get crash changed to add a new option to the mod command
> in crash. If you've got a dump server and you've got debuginfo RPMs
> extracted for pretty much every RHEL/SLES release you can create a
> symlink in the same directory as the vmcore pointing to the correct
> namelist, for example:
>
> vmlinux -> /debuginfo/x86_64/rhel5/2.6.18-164/usr/lib/debug/lib/modules/2.6.18-164.el5/vmlinux
>
> I'd like to see the mod command automatically work out where the
> debug modules will be based upon the result of realpath(3) on the
> namelist then removing everything after /usr/lib/debug. I know that
> there's the "--mod directory" option but you've got to remember to
> run it all the time and if you've extracted the kernel debuginfo
> crash can easily work out where they are if you use either a full or
> relative path or symlink to the namelist. I don't know if anyone
> would prefer to see it implemented in a different way but rather
> than risk breaking something I didn't understand I added a new -t
> option instead (-t because it's similar to -S and t is the next
> available option after the letter s).
>
> I've run it on a few dumps and it seems to be working correctly. All
> of the code changes are in kernel.c, help.c needed some changes just
> to add the help text. Any feedback would be appreciated.
>
> Thanks
> Shane

It's a reasonable idea, but it seems that the eventual "tree" that is
selected should be more restrictive. Here's what I mean...

It works nicely using the setup that you describe:

vmlinux -> /debuginfo/x86_64/rhel5/2.6.18-164/usr/lib/debug/lib/modules/2.6.18-164.el5/vmlinux

So on my workstation, I set up a sample tree like so, where "mod -t"
with CRASHDEBUG(3) shows this:

REL namelist: vmlinux
REL realpath: /tmp/mydebuginfos/usr/lib/debug/lib/modules/2.6.18-128.el5/vmlinux
REL short path: /tmp/mydebuginfos/usr/lib/debug/

and it found the <module>.ko.debug files OK.

But on an internal server, we have a directory structure like this:

/cores/debuginfo/x86_64/usr/lib/debug/lib/modules

And in that "modules" directory, there are dozens of "2.6.x" kernel version
debuginfo trees. So taking one example using a symbolically linked vmlinux
file, "mod -t" shows this:

REL namelist: vmlinux
REL realpath: /cores/debuginfo/x86_64/usr/lib/debug/lib/modules/2.6.32-220.2.1.el6.x86_64/vmlinux
REL short path: /cores/debuginfo/x86_64/usr/lib/debug/

But unfortunately it just grabs whichever "<module>.ko.debug" it finds
first -- which invariably comes from the wrong kernel version tree, because
there are dozens of each <module>.ko.debug file to select from.

If it used "/cores/debuginfo/x86_64/usr/lib/debug/lib/modules/2.6.32-220.2.1.el6.x86_64",
as the "short path", then it would find the correct (only) <module>.ko.debug files.

So would there be a problem in having the "short path" include the parent
directory that contains the vmlinux file?

We also compress the vmlinux files for space-saving. You might
also test what happens when the local symbolic link is to a
vmlinux.gz file, because pc->namelist will point to the
uncompressed tmpname-generated file instead of back into the
original tree.

Thanks,
Dave

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 
Old 04-25-2012, 09:00 PM
Dave Anderson
 
Default After feedback on crash patch

----- Original Message -----
>
>
> ----- Original Message -----
> > Hi,
> >
> > I'd like to get crash changed to add a new option to the mod command
> > in crash. If you've got a dump server and you've got debuginfo RPMs
> > extracted for pretty much every RHEL/SLES release you can create a
> > symlink in the same directory as the vmcore pointing to the correct
> > namelist, for example:
> >
> > vmlinux -> /debuginfo/x86_64/rhel5/2.6.18-164/usr/lib/debug/lib/modules/2.6.18-164.el5/vmlinux
> >
> > I'd like to see the mod command automatically work out where the
> > debug modules will be based upon the result of realpath(3) on the
> > namelist then removing everything after /usr/lib/debug. I know that
> > there's the "--mod directory" option but you've got to remember to
> > run it all the time and if you've extracted the kernel debuginfo
> > crash can easily work out where they are if you use either a full or
> > relative path or symlink to the namelist. I don't know if anyone
> > would prefer to see it implemented in a different way but rather
> > than risk breaking something I didn't understand I added a new -t
> > option instead (-t because it's similar to -S and t is the next
> > available option after the letter s).
> >
> > I've run it on a few dumps and it seems to be working correctly. All
> > of the code changes are in kernel.c, help.c needed some changes just
> > to add the help text. Any feedback would be appreciated.
> >
> > Thanks
> > Shane
>
> It's a reasonable idea, but it seems that the eventual "tree" that is
> selected should be more restrictive. Here's what I mean...
>
> It works nicely using the setup that you describe:
>
> vmlinux ->
> /debuginfo/x86_64/rhel5/2.6.18-164/usr/lib/debug/lib/modules/2.6.18-164.el5/vmlinux
>
> So on my workstation, I set up a sample tree like so, where "mod -t"
> with CRASHDEBUG(3) shows this:
>
> REL namelist: vmlinux
> REL realpath:
> /tmp/mydebuginfos/usr/lib/debug/lib/modules/2.6.18-128.el5/vmlinux
> REL short path: /tmp/mydebuginfos/usr/lib/debug/
>
> and it found the <module>.ko.debug files OK.
>
> But on an internal server, we have a directory structure like this:
>
> /cores/debuginfo/x86_64/usr/lib/debug/lib/modules
>
> And in that "modules" directory, there are dozens of "2.6.x" kernel version
> debuginfo trees. So taking one example using a symbolically linked vmlinux
> file, "mod -t" shows this:
>
> REL namelist: vmlinux
> REL realpath:
> /cores/debuginfo/x86_64/usr/lib/debug/lib/modules/2.6.32-220.2.1.el6.x86_64/vmlinux
> REL short path: /cores/debuginfo/x86_64/usr/lib/debug/
>
> But unfortunately it just grabs whichever "<module>.ko.debug" it finds
> first -- which invariably comes from the wrong kernel version tree, because
> there are dozens of each <module>.ko.debug file to select from.
>
> If it used "/cores/debuginfo/x86_64/usr/lib/debug/lib/modules/2.6.32-220.2.1.el6.x86_64",
> as the "short path", then it would find the correct (only) <module>.ko.debug files.
>
> So would there be a problem in having the "short path" include the parent
> directory that contains the vmlinux file?
>
> We also compress the vmlinux files for space-saving. You might
> also test what happens when the local symbolic link is to a
> vmlinux.gz file, because pc->namelist will point to the
> uncompressed tmpname-generated file instead of back into the
> original tree.
>
> Thanks,
> Dave

Shane,

How does the attached patch work for you? It should just work automatically
without any additional arguments, because when all else fails, it will search
for modules starting from the directory containing the vmlinux or vmlinux.gz file.

Dave
--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 
Old 04-25-2012, 11:27 PM
"Seymour, Shane M"
 
Default After feedback on crash patch

Hi Dave,

I'll give that a whirl today and let you know.

Thanks
Shane

-----Original Message-----
From: Dave Anderson [mailto:anderson@redhat.com]
Sent: Thursday, April 26, 2012 7:01 AM
To: Discussion list for crash utility usage, maintenance and development
Cc: Seymour, Shane M
Subject: Re: [Crash-utility] After feedback on crash patch



----- Original Message -----
>
>
> ----- Original Message -----
> > Hi,
> >
> > I'd like to get crash changed to add a new option to the mod command
> > in crash. If you've got a dump server and you've got debuginfo RPMs
> > extracted for pretty much every RHEL/SLES release you can create a
> > symlink in the same directory as the vmcore pointing to the correct
> > namelist, for example:
> >
> > vmlinux ->
> > /debuginfo/x86_64/rhel5/2.6.18-164/usr/lib/debug/lib/modules/2.6.18-
> > 164.el5/vmlinux
> >
> > I'd like to see the mod command automatically work out where the
> > debug modules will be based upon the result of realpath(3) on the
> > namelist then removing everything after /usr/lib/debug. I know that
> > there's the "--mod directory" option but you've got to remember to
> > run it all the time and if you've extracted the kernel debuginfo
> > crash can easily work out where they are if you use either a full or
> > relative path or symlink to the namelist. I don't know if anyone
> > would prefer to see it implemented in a different way but rather
> > than risk breaking something I didn't understand I added a new -t
> > option instead (-t because it's similar to -S and t is the next
> > available option after the letter s).
> >
> > I've run it on a few dumps and it seems to be working correctly.
> > All of the code changes are in kernel.c, help.c needed some changes
> > just to add the help text. Any feedback would be appreciated.
> >
> > Thanks
> > Shane
>
> It's a reasonable idea, but it seems that the eventual "tree" that is
> selected should be more restrictive. Here's what I mean...
>
> It works nicely using the setup that you describe:
>
> vmlinux ->
>
> /debuginfo/x86_64/rhel5/2.6.18-164/usr/lib/debug/lib/modules/2.6.18-16
> 4.el5/vmlinux
>
> So on my workstation, I set up a sample tree like so, where "mod -t"
> with CRASHDEBUG(3) shows this:
>
> REL namelist: vmlinux
> REL realpath:
> /tmp/mydebuginfos/usr/lib/debug/lib/modules/2.6.18-128.el5/vmlinux
> REL short path: /tmp/mydebuginfos/usr/lib/debug/
>
> and it found the <module>.ko.debug files OK.
>
> But on an internal server, we have a directory structure like this:
>
> /cores/debuginfo/x86_64/usr/lib/debug/lib/modules
>
> And in that "modules" directory, there are dozens of "2.6.x" kernel
> version debuginfo trees. So taking one example using a symbolically
> linked vmlinux file, "mod -t" shows this:
>
> REL namelist: vmlinux
> REL realpath:
>
> /cores/debuginfo/x86_64/usr/lib/debug/lib/modules/2.6.32-220.2.1.el6.x
> 86_64/vmlinux REL short path: /cores/debuginfo/x86_64/usr/lib/debug/
>
> But unfortunately it just grabs whichever "<module>.ko.debug" it finds
> first -- which invariably comes from the wrong kernel version tree,
> because there are dozens of each <module>.ko.debug file to select from.
>
> If it used
> "/cores/debuginfo/x86_64/usr/lib/debug/lib/modules/2.6.32-220.2.1.el6.
> x86_64", as the "short path", then it would find the correct (only)
> <module>.ko.debug files.
>
> So would there be a problem in having the "short path" include the
> parent directory that contains the vmlinux file?
>
> We also compress the vmlinux files for space-saving. You might also
> test what happens when the local symbolic link is to a vmlinux.gz
> file, because pc->namelist will point to the uncompressed
> tmpname-generated file instead of back into the original tree.
>
> Thanks,
> Dave

Shane,

How does the attached patch work for you? It should just work automatically without any additional arguments, because when all else fails, it will search
for modules starting from the directory containing the vmlinux or vmlinux.gz file.

Dave

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 
Old 04-26-2012, 02:11 AM
"Seymour, Shane M"
 
Default After feedback on crash patch

Hi Dave,

> How does the attached patch work for you?

Absolutely perfectly. Thank you very much.

Shane

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 
Old 04-26-2012, 01:05 PM
Dave Anderson
 
Default After feedback on crash patch

----- Original Message -----
> Hi Dave,
>
> > How does the attached patch work for you?
>
> Absolutely perfectly. Thank you very much.
>
> Shane
>

OK great -- and thanks for the excellent idea.

Queued for crash-6.0.6.

Dave

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 

Thread Tools




All times are GMT. The time now is 07:05 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org