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 05-19-2010, 01:09 PM
Dave Anderson
 
Default Why are there two ways of getting register values for active tasks?

----- "Daisuke HATAYAMA" <d.hatayama@jp.fujitsu.com> wrote:

> Hi, all.
>
> I have a question on the implementation of get_netdump_regs_x86_64().
>
> Currently, in order to get register values for active tasks, only
> panic task makes use of note information. On the other hand, other
> active tasks search stack frame for registers saved at nmi
> switch. However, crash dump contains the note information for every
> CPUs, so I think it uncessary to search stack frame.

Originally it was done that way because the code was written for
netdump-generated dumpfiles, which only generated note information
for the panic task. But if I'm not mistaken, given that recent
kernels do not store debuginfo data for the user_regs_struct, it
almost always falls through into x86_64_get_stack_frame().

Dave

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 
Old 05-19-2010, 01:28 PM
Dave Anderson
 
Default Why are there two ways of getting register values for active tasks?

----- "Dave Anderson" <anderson@redhat.com> wrote:

> ----- "Daisuke HATAYAMA" <d.hatayama@jp.fujitsu.com> wrote:
>
> > Hi, all.
> >
> > I have a question on the implementation of
> get_netdump_regs_x86_64().
> >
> > Currently, in order to get register values for active tasks, only
> > panic task makes use of note information. On the other hand, other
> > active tasks search stack frame for registers saved at nmi
> > switch. However, crash dump contains the note information for every
> > CPUs, so I think it uncessary to search stack frame.
>
> Originally it was done that way because the code was written for
> netdump-generated dumpfiles, which only generated note information
> for the panic task. But if I'm not mistaken, given that recent
> kernels do not store debuginfo data for the user_regs_struct, it
> almost always falls through into x86_64_get_stack_frame().

I take that back -- when it's not in the debuginfo, it hardwires
the user_regs_struct data structure information.

That being the case, I don't remember why it is restricted to the
panic task, but it had to have been put in place based upon actual
dumpfiles where it didn't work correctly for a non-panic task.
If I get the time, I'll remove the restriction and run it on
my set of stashed dumpfile examples to see if I can be more
specific.

Anyway, good question -- sorry for such a weak answer...

Dave

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 
Old 05-21-2010, 02:07 AM
Daisuke HATAYAMA
 
Default Why are there two ways of getting register values for active tasks?

Hi Dave.

Sorry for the late response.

From: Dave Anderson <anderson@redhat.com>
>
> ----- "Dave Anderson" <anderson@redhat.com> wrote:
>
>> ----- "Daisuke HATAYAMA" <d.hatayama@jp.fujitsu.com> wrote:
>>
>> > Hi, all.
>> >
>> > I have a question on the implementation of
>> get_netdump_regs_x86_64().
>> >
>> > Currently, in order to get register values for active tasks, only
>> > panic task makes use of note information. On the other hand, other
>> > active tasks search stack frame for registers saved at nmi
>> > switch. However, crash dump contains the note information for every
>> > CPUs, so I think it uncessary to search stack frame.
>>
>> Originally it was done that way because the code was written for
>> netdump-generated dumpfiles, which only generated note information
>> for the panic task. But if I'm not mistaken, given that recent
>> kernels do not store debuginfo data for the user_regs_struct, it
>> almost always falls through into x86_64_get_stack_frame().
>
> I take that back -- when it's not in the debuginfo, it hardwires
> the user_regs_struct data structure information.
>
> That being the case, I don't remember why it is restricted to the
> panic task, but it had to have been put in place based upon actual
> dumpfiles where it didn't work correctly for a non-panic task.
> If I get the time, I'll remove the restriction and run it on
> my set of stashed dumpfile examples to see if I can be more
> specific.

Well, I have still a question: Does kdump-compressed format contain
register values for CPUs?

I've looked into part of makedumpfile reading ELF but found out that
yet. It appears to me that makedumpfile ignores all note info except
for vmcoreinfo's location.

>
> Anyway, good question -- sorry for such a weak answer...

That's what I needed. Thanks a lot.

Thanks.
HATAYAMA, Daisuke

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 
Old 05-21-2010, 01:38 PM
Dave Anderson
 
Default Why are there two ways of getting register values for active tasks?

----- "Daisuke HATAYAMA" <d.hatayama@jp.fujitsu.com> wrote:

> Hi Dave.
>
> Well, I have still a question: Does kdump-compressed format contain
> register values for CPUs?
>
> I've looked into part of makedumpfile reading ELF but found out that
> yet. It appears to me that makedumpfile ignores all note info except
> for vmcoreinfo's location.

That's correct, there are no per-cpu register values. From the crash
utility's perspective, all it gets from the makedumpfile-generated
compressed dumpfile is the diskdump_header and kdump_sub_header:

struct disk_dump_header {
char signature[SIG_LEN]; /* = "DISKDUMP" */
int header_version; /* Dump header version */
struct new_utsname utsname; /* copy of system_utsname */
struct timeval timestamp; /* Time stamp */
unsigned int status; /* Above flags */
int block_size; /* Size of a block in byte */
int sub_hdr_size; /* Size of arch dependent
header in blocks */
unsigned int bitmap_blocks; /* Size of Memory bitmap in
block */
unsigned int max_mapnr; /* = max_mapnr */
unsigned int total_ram_blocks;/* Number of blocks should be
written */
unsigned int device_blocks; /* Number of total blocks in
* the dump device */
unsigned int written_blocks; /* Number of written blocks */
unsigned int current_cpu; /* CPU# which handles dump */
int nr_cpus; /* Number of CPUs */
struct task_struct *tasks[0];
};


struct kdump_sub_header {
unsigned long phys_base;
int dump_level; /* header_version 1 and later */
int split; /* header_version 2 and later */
unsigned long start_pfn; /* header_version 2 and later */
unsigned long end_pfn; /* header_version 2 and later */
};

Dave

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 
Old 05-24-2010, 01:03 AM
Daisuke HATAYAMA
 
Default Why are there two ways of getting register values for active tasks?

From: Dave Anderson <anderson@redhat.com>
Subject: Re: [Crash-utility] Why are there two ways of getting register values for active tasks?
Date: Fri, 21 May 2010 09:38:12 -0400 (EDT)

>
> ----- "Daisuke HATAYAMA" <d.hatayama@jp.fujitsu.com> wrote:
>
>> Hi Dave.
>>
>> Well, I have still a question: Does kdump-compressed format contain
>> register values for CPUs?
>>
>> I've looked into part of makedumpfile reading ELF but found out that
>> yet. It appears to me that makedumpfile ignores all note info except
>> for vmcoreinfo's location.
>
> That's correct, there are no per-cpu register values. From the crash
> utility's perspective, all it gets from the makedumpfile-generated
> compressed dumpfile is the diskdump_header and kdump_sub_header:
>

Thanks. It's very helpful.

HATAYAMA, Daisuke

--
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 08:45 AM.

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