Re: [Crash-utility] [RFI] Support Fujitsu's sadump dump format

Re: [Crash-utility] [RFI] Support Fujitsu's sadump dump format

[tachibana]

Hi Hatayama-san,

On 2011/06/29 12:12:18 +0900, HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com> wrote:
> From: Dave Anderson <anderson@redhat.com>
> Subject: Re: [Crash-utility] [RFI] Support Fujitsu's sadump dump format
> Date: Tue, 28 Jun 2011 08:57:42 -0400 (EDT)
> 
> > 
> > 
> > ----- Original Message -----
> >> Fujitsu has stand-alone dump mechanism based on firmware level
> >> functionality, which we call SADUMP, in short.
> >> 
> >> We've maintained utility tools internally but now we're thinking that
> >> the best is crash utility and makedumpfile supports the sadump format
> >> for the viewpoint of both portability and maintainability.
> >> 
> >> We'll be of course responsible for its maintainance in a continuous
> >> manner. The sadump dump format is very similar to diskdump format and
> >> so kdump (compressed) format, so we estimate patch set would be a
> >> relatively small size.
> >> 
> >> Could you tell me whether crash utility and makedumpfile can support
> >> the sadump format? If OK, we'll start to make patchset.

I think it's not bad to support sadump by makedumpfile. However I have 
several questions.
- Do you want to use makedumpfile to make an existing file that sadump has 
  dumped small?
- It isn't possible to support the same form as kdump-compressed format 
  now, is it?
- When the information that makedumpfile reads from a note of /proc/vmcore 
  (or a header of kdump-compressed format) is added by an extension of 
  makedumpfile, do you need to modify sadump?

Thanks
tachibana


> > 
> > Sure, yes, the crash utility can always support another dumpfile format.
> > 
> 
> Thanks. It helps a lot.
> 
> > It's unclear to me how similar SADUMP is to diskdump/compressed-kdump.
> > Does your internal version patch diskdump.c, or do you maintain your
> > own "sadump.c"?  I ask because if your patchset is at all intrusive,
> > I'd prefer it be kept in its own file, primarily for maintainability,
> > but also because SADUMP is essentially a black-box to anybody outside
> > Fujitsu.
> 
> What I meant when I used ``similar'' is both literally and
> logically. The format consists of diskdump header-like header, two
> kinds of bitmaps used for the same purpose as those in diskump format,
> and memory data. They can be handled in common with the existing data
> structure, diskdump_data, non-intrusively, so I hope they are placed
> in diskdump.c.
> 
> On the other hand, there's a code to be placed at such specific
> area. sadump is triggered depending on kdump's progress and so
> register values to be contained in vmcore varies according to the
> progress: If crash_notes has been initialized when sadump is
> triggered, sadump packs the register values in crash_notes; if not
> yet, packs registers gathered by firmware. This is sadump specific
> processing, so I think putting it in specific sadump.c file is a
> natural and reasonable choise.
> 
> Anyway, I have not made any patch set for this. I'll post a patch set
> when I complete.
> 
> Again, thanks a lot for the positive answer.
> 
> Thanks.
> HATAYAMA, Daisuke
> 
> 
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [Crash-utility] [RFI] Support Fujitsu's sadump dump format

[HATAYAMA Daisuke]

Hello Tachibana-san,

Thanks for your replying.

From: tachibana@mxm.nes.nec.co.jp
Subject: Re: [Crash-utility] [RFI] Support Fujitsu's sadump dump format
Date: Thu, 30 Jun 2011 14:58:46 +0900

> Hi Hatayama-san,
> 
> On 2011/06/29 12:12:18 +0900, HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com> wrote:
>> From: Dave Anderson <anderson@redhat.com>
>> Subject: Re: [Crash-utility] [RFI] Support Fujitsu's sadump dump format
>> Date: Tue, 28 Jun 2011 08:57:42 -0400 (EDT)
>> 
>> > 
>> > 
>> > ----- Original Message -----
>> >> Fujitsu has stand-alone dump mechanism based on firmware level
>> >> functionality, which we call SADUMP, in short.
>> >> 
>> >> We've maintained utility tools internally but now we're thinking that
>> >> the best is crash utility and makedumpfile supports the sadump format
>> >> for the viewpoint of both portability and maintainability.
>> >> 
>> >> We'll be of course responsible for its maintainance in a continuous
>> >> manner. The sadump dump format is very similar to diskdump format and
>> >> so kdump (compressed) format, so we estimate patch set would be a
>> >> relatively small size.
>> >> 
>> >> Could you tell me whether crash utility and makedumpfile can support
>> >> the sadump format? If OK, we'll start to make patchset.
> 
> I think it's not bad to support sadump by makedumpfile. However I have 
> several questions.
> - Do you want to use makedumpfile to make an existing file that sadump has 
>   dumped small?

Of couse, it's one of the purposes. It's useful feature.

The first is to translate sadump format into the one crash utility can
recognize. makedumpfile is the standard tool to do it, and if
makdumpfile can support sadump format, I think it is the best.

> - It isn't possible to support the same form as kdump-compressed format 
>   now, is it?

I think it's technically possible but practically impossible. sadump is
a firmware and it is maintained by firmware team.

> - When the information that makedumpfile reads from a note of /proc/vmcore 
>   (or a header of kdump-compressed format) is added by an extension of 
>   makedumpfile, do you need to modify sadump?

Sorry, I've not investigated makedumpfile implementation enough yet.

But if I understand correctly, the current note information contained
in kdump-compressed format is NT_PRSTATUS and VMCOREINFO only, and for
them, sadump doesn't need to be modified. But it might need to be
modified if another kind of note is newly added.

Thanks.
HATAYAMA, Daisuke


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [Crash-utility] [RFI] Support Fujitsu's sadump dump format

[tachibana]

Hi Hatayama-san,

On 2011/06/30 16:25:07 +0900, HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com> wrote:
> Hello Tachibana-san,
> 
> Thanks for your replying.
> 
> From: tachibana@mxm.nes.nec.co.jp
> Subject: Re: [Crash-utility] [RFI] Support Fujitsu's sadump dump format
> Date: Thu, 30 Jun 2011 14:58:46 +0900
> 
> > Hi Hatayama-san,
> > 
> > On 2011/06/29 12:12:18 +0900, HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com> wrote:
> >> From: Dave Anderson <anderson@redhat.com>
> >> Subject: Re: [Crash-utility] [RFI] Support Fujitsu's sadump dump format
> >> Date: Tue, 28 Jun 2011 08:57:42 -0400 (EDT)
> >> 
> >> > 
> >> > 
> >> > ----- Original Message -----
> >> >> Fujitsu has stand-alone dump mechanism based on firmware level
> >> >> functionality, which we call SADUMP, in short.
> >> >> 
> >> >> We've maintained utility tools internally but now we're thinking that
> >> >> the best is crash utility and makedumpfile supports the sadump format
> >> >> for the viewpoint of both portability and maintainability.
> >> >> 
> >> >> We'll be of course responsible for its maintainance in a continuous
> >> >> manner. The sadump dump format is very similar to diskdump format and
> >> >> so kdump (compressed) format, so we estimate patch set would be a
> >> >> relatively small size.
> >> >> 
> >> >> Could you tell me whether crash utility and makedumpfile can support
> >> >> the sadump format? If OK, we'll start to make patchset.
> > 
> > I think it's not bad to support sadump by makedumpfile. However I have 
> > several questions.
> > - Do you want to use makedumpfile to make an existing file that sadump has 
> >   dumped small?
> 
> Of couse, it's one of the purposes. It's useful feature.
> 
> The first is to translate sadump format into the one crash utility can
> recognize. makedumpfile is the standard tool to do it, and if
> makdumpfile can support sadump format, I think it is the best.
> 
> > - It isn't possible to support the same form as kdump-compressed format 
> >   now, is it?
> 
> I think it's technically possible but practically impossible. sadump is
> a firmware and it is maintained by firmware team.
> 
> > - When the information that makedumpfile reads from a note of /proc/vmcore 
> >   (or a header of kdump-compressed format) is added by an extension of 
> >   makedumpfile, do you need to modify sadump?
> 
> Sorry, I've not investigated makedumpfile implementation enough yet.
> 
> But if I understand correctly, the current note information contained
> in kdump-compressed format is NT_PRSTATUS and VMCOREINFO only, and for
> them, sadump doesn't need to be modified. But it might need to be
> modified if another kind of note is newly added.

Thank you for your explanation. I understood.
I will merge patches for sadump if you will post them.


Thanks.
tachibana

> 
> Thanks.
> HATAYAMA, Daisuke
> 

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [Crash-utility] [RFI] Support Fujitsu's sadump dump format

[HATAYAMA Daisuke]

From: tachibana@mxm.nes.nec.co.jp
Subject: Re: [Crash-utility] [RFI] Support Fujitsu's sadump dump format
Date: Thu, 30 Jun 2011 17:24:48 +0900

> Hi Hatayama-san,
> 
> On 2011/06/30 16:25:07 +0900, HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com> wrote:
>> Hello Tachibana-san,
>> 
>> Thanks for your replying.
>> 
>> From: tachibana@mxm.nes.nec.co.jp
>> Subject: Re: [Crash-utility] [RFI] Support Fujitsu's sadump dump format
>> Date: Thu, 30 Jun 2011 14:58:46 +0900
>> 
>> > Hi Hatayama-san,
>> > 
>> > On 2011/06/29 12:12:18 +0900, HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com> wrote:
>> >> From: Dave Anderson <anderson@redhat.com>
>> >> Subject: Re: [Crash-utility] [RFI] Support Fujitsu's sadump dump format
>> >> Date: Tue, 28 Jun 2011 08:57:42 -0400 (EDT)
>> >> 
>> >> > 
>> >> > 
>> >> > ----- Original Message -----
>> >> >> Fujitsu has stand-alone dump mechanism based on firmware level
>> >> >> functionality, which we call SADUMP, in short.
>> >> >> 
>> >> >> We've maintained utility tools internally but now we're thinking that
>> >> >> the best is crash utility and makedumpfile supports the sadump format
>> >> >> for the viewpoint of both portability and maintainability.
>> >> >> 
>> >> >> We'll be of course responsible for its maintainance in a continuous
>> >> >> manner. The sadump dump format is very similar to diskdump format and
>> >> >> so kdump (compressed) format, so we estimate patch set would be a
>> >> >> relatively small size.
>> >> >> 
>> >> >> Could you tell me whether crash utility and makedumpfile can support
>> >> >> the sadump format? If OK, we'll start to make patchset.
>> > 
>> > I think it's not bad to support sadump by makedumpfile. However I have 
>> > several questions.
>> > - Do you want to use makedumpfile to make an existing file that sadump has 
>> >   dumped small?
>> 
>> Of couse, it's one of the purposes. It's useful feature.
>> 
>> The first is to translate sadump format into the one crash utility can
>> recognize. makedumpfile is the standard tool to do it, and if
>> makdumpfile can support sadump format, I think it is the best.
>> 
>> > - It isn't possible to support the same form as kdump-compressed format 
>> >   now, is it?
>> 
>> I think it's technically possible but practically impossible. sadump is
>> a firmware and it is maintained by firmware team.
>> 
>> > - When the information that makedumpfile reads from a note of /proc/vmcore 
>> >   (or a header of kdump-compressed format) is added by an extension of 
>> >   makedumpfile, do you need to modify sadump?
>> 
>> Sorry, I've not investigated makedumpfile implementation enough yet.
>> 
>> But if I understand correctly, the current note information contained
>> in kdump-compressed format is NT_PRSTATUS and VMCOREINFO only, and for
>> them, sadump doesn't need to be modified. But it might need to be
>> modified if another kind of note is newly added.
> 
> Thank you for your explanation. I understood.
> I will merge patches for sadump if you will post them.
> 

It helps us a lot. Thanks.

I'll post a patch set after making it.
Wait for a while, please.

Thanks.
HATAYAMA, Daisuke


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [Crash-utility] [RFI] Support Fujitsu's sadump dump format

[Dave Anderson]

----- Original Message -----

Now I am confused...

You stated this earlier:

> What I meant when I used ``similar'' is both literally and
> logically. The format consists of diskdump header-like header, two
> kinds of bitmaps used for the same purpose as those in diskump format,
> and memory data. They can be handled in common with the existing data
> structure, diskdump_data, non-intrusively, so I hope they are placed
> in diskdump.c.

which made it sound like the sadump dumpfile format is already similar
to the compressed kdump format.

But this makes it sound like the sadump native-format is unique:

> >> The first is to translate sadump format into the one crash utility can
> >> recognize. makedumpfile is the standard tool to do it, and if
> >> makdumpfile can support sadump format, I think it is the best.
> >>
> >> > - It isn't possible to support the same form as kdump-compressed format
> >> >   now, is it?
> >>
> >> I think it's technically possible but practically impossible.  sadump is
> >> a firmware and it is maintained by firmware team.

Is this how it would work?:

 (1) kernel crashes
 (2) sadump creates a native-format dumpfile 
 (3) (patched) makedumpfile takes the native-format sadump dumpfile and
     translates into a format that is similar to a compressed kdump
 (4) (patched) crash utility reads the translated sadump dumpfile

Or will the (patched) crash utility be able to read the sadump dumpfile
in its native form if it is not pre-processed by makedumpfile?

Dave
     

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [Crash-utility] [RFI] Support Fujitsu's sadump dump format

[HATAYAMA Daisuke]

From: Dave Anderson <anderson@redhat.com>
Subject: Re: [Crash-utility] [RFI] Support Fujitsu's sadump dump format
Date: Thu, 30 Jun 2011 09:40:49 -0400 (EDT)

> 
> 
> ----- Original Message -----
> 
> Now I am confused...
> 
> You stated this earlier:
> 
>> What I meant when I used ``similar'' is both literally and
>> logically. The format consists of diskdump header-like header, two
>> kinds of bitmaps used for the same purpose as those in diskump format,
>> and memory data. They can be handled in common with the existing data
>> structure, diskdump_data, non-intrusively, so I hope they are placed
>> in diskdump.c.
> 
> which made it sound like the sadump dumpfile format is already similar
> to the compressed kdump format.
> 
> But this makes it sound like the sadump native-format is unique:
> 
>> >> The first is to translate sadump format into the one crash utility can
>> >> recognize. makedumpfile is the standard tool to do it, and if
>> >> makdumpfile can support sadump format, I think it is the best.
>> >>
>> >> > - It isn't possible to support the same form as kdump-compressed format
>> >> >   now, is it?
>> >>
>> >> I think it's technically possible but practically impossible.  sadump is
>> >> a firmware and it is maintained by firmware team.
> 
> Is this how it would work?:
> 
>  (1) kernel crashes
>  (2) sadump creates a native-format dumpfile 
>  (3) (patched) makedumpfile takes the native-format sadump dumpfile and
>      translates into a format that is similar to a compressed kdump
>  (4) (patched) crash utility reads the translated sadump dumpfile
> 
> Or will the (patched) crash utility be able to read the sadump dumpfile
> in its native form if it is not pre-processed by makedumpfile?
> 
> Dave

Yes, the procedure (1)-(4) you wrote is exactly correct. But in addition,

 (1) kernel crashes
 (2) sadump creates a native-format dumpfile 
+(2.5) (patched) crash utility reads the native-format dumpfile and creates a dump summary.
 (3) (patched) makedumpfile takes the native-format sadump dumpfile and
     translates into a format that is similar to a compressed kdump
 (4) (patched) crash utility reads the translated sadump dumpfile

requires crash utility to be able to recognize sadump dump format
directly.

The dump sammary information is an output of crash utility including
startup information, bt -a, log, mod etc. For this, crash utility can
recognize the dump data.

But if we translates the dump data into vmcore, such as using
makedumpfile, to have crash utility read it, not a little disk space
and time must be consumed since dump size tends to be huge.

On the other hand, translating the data into kdump-compressed format
is better for carrying the data to another place.

And, sorry. the below I wrote earlier is not precisely correct. I need
to have crash utility can recognize the sadump format too. I'm
intending that crash reads the sadump dump format only for a dump
summary.

>> >> The first is to translate sadump format into the one crash utility can
>> >> recognize. makedumpfile is the standard tool to do it, and if
>> >> makdumpfile can support sadump format, I think it is the best.

Thanks.
HATAYAMA, Daisuke


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [Crash-utility] [RFI] Support Fujitsu's sadump dump format

[HATAYAMA Daisuke]

From: Dave Anderson <anderson@redhat.com>
Subject: Re: [Crash-utility] [RFI] Support Fujitsu's sadump dump format
Date: Tue, 28 Jun 2011 08:57:42 -0400 (EDT)

> 
> 
> ----- Original Message -----
>> Fujitsu has stand-alone dump mechanism based on firmware level
>> functionality, which we call SADUMP, in short.
>> 
>> We've maintained utility tools internally but now we're thinking that
>> the best is crash utility and makedumpfile supports the sadump format
>> for the viewpoint of both portability and maintainability.
>> 
>> We'll be of course responsible for its maintainance in a continuous
>> manner. The sadump dump format is very similar to diskdump format and
>> so kdump (compressed) format, so we estimate patch set would be a
>> relatively small size.
>> 
>> Could you tell me whether crash utility and makedumpfile can support
>> the sadump format? If OK, we'll start to make patchset.
> 
> Sure, yes, the crash utility can always support another dumpfile format.
> 

Thanks. It helps a lot.

> It's unclear to me how similar SADUMP is to diskdump/compressed-kdump.
> Does your internal version patch diskdump.c, or do you maintain your
> own "sadump.c"?  I ask because if your patchset is at all intrusive,
> I'd prefer it be kept in its own file, primarily for maintainability,
> but also because SADUMP is essentially a black-box to anybody outside
> Fujitsu.

What I meant when I used ``similar'' is both literally and
logically. The format consists of diskdump header-like header, two
kinds of bitmaps used for the same purpose as those in diskump format,
and memory data. They can be handled in common with the existing data
structure, diskdump_data, non-intrusively, so I hope they are placed
in diskdump.c.

On the other hand, there's a code to be placed at such specific
area. sadump is triggered depending on kdump's progress and so
register values to be contained in vmcore varies according to the
progress: If crash_notes has been initialized when sadump is
triggered, sadump packs the register values in crash_notes; if not
yet, packs registers gathered by firmware. This is sadump specific
processing, so I think putting it in specific sadump.c file is a
natural and reasonable choise.

Anyway, I have not made any patch set for this. I'll post a patch set
when I complete.

Again, thanks a lot for the positive answer.

Thanks.
HATAYAMA, Daisuke


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [Crash-utility] [RFI] Support Fujitsu's sadump dump format

[Dave Anderson]

----- Original Message -----
> Fujitsu has stand-alone dump mechanism based on firmware level
> functionality, which we call SADUMP, in short.
> 
> We've maintained utility tools internally but now we're thinking that
> the best is crash utility and makedumpfile supports the sadump format
> for the viewpoint of both portability and maintainability.
> 
> We'll be of course responsible for its maintainance in a continuous
> manner. The sadump dump format is very similar to diskdump format and
> so kdump (compressed) format, so we estimate patch set would be a
> relatively small size.
> 
> Could you tell me whether crash utility and makedumpfile can support
> the sadump format? If OK, we'll start to make patchset.

Sure, yes, the crash utility can always support another dumpfile format.

It's unclear to me how similar SADUMP is to diskdump/compressed-kdump.
Does your internal version patch diskdump.c, or do you maintain your
own "sadump.c"?  I ask because if your patchset is at all intrusive,
I'd prefer it be kept in its own file, primarily for maintainability,
but also because SADUMP is essentially a black-box to anybody outside
Fujitsu.

Thanks,
  Dave

 
> Thanks.
> HATAYAMA, Daisuke

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec