Bug 171137 - FEAT RHEL4-U3: crash - reads the new format of dumpfile created by compressible dump feature of diskdump.
FEAT RHEL4-U3: crash - reads the new format of dumpfile created by compressib...
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: crash (Show other bugs)
4.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Dave Anderson
BZ_168641 IT_81617
None
: FutureFeature
Depends On:
Blocks: 168429 168641 171141
  Show dependency treegraph
 
Reported: 2005-10-18 11:50 EDT by Akira Imamura
Modified: 2007-11-30 17:07 EST (History)
8 users (show)

See Also:
Fixed In Version: RHEA-2006-0075
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-03-07 13:26:46 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
crash.patch (14.98 KB, patch)
2005-10-24 18:49 EDT, Nobuhiro Tachino
no flags Details | Diff
crash-compress-3.patch (14.97 KB, patch)
2005-11-01 14:10 EST, Nobuhiro Tachino
no flags Details | Diff

  None (edit)
Description Akira Imamura 2005-10-18 11:50:35 EDT
Today, the memory size of hardware that customers have
is getting larger than before. So, they hope they can use
diskdump features with the size of the dump device which
is much less than the size of the mounted memory.
diskdump will be able to compress dump data while memory
dumping. It will also be able to create a vmcore file
as the new format with its dump data. The current crash
is not able to read the vmcore of the new format. crash
needs to be modified so that it can read it correctly.
Comment 2 Dave Anderson 2005-10-24 17:31:56 EDT
I am awaiting a set of proposed changes to the crash utility from NEC
to properly support their new dumpfile format.  

The initial changes proposed by NEC were unnacceptable because it depended
upon untested, constantly-changing, and unmaintained (by me) LKCD code in
the crash utility.  A meeting was held with the in-house Fujitsu team to
discuss a better, safer, and acceptable manner of creating and accessing the
dumpfile, and my proposal was passed back to the NEC developers.

I am putting this bugzilla into NEEDINFO_REPORTER until a reply from NEC
is received.
Comment 3 Nobuhiro Tachino 2005-10-24 18:46:48 EDT
NEC and Fujitsu are now trying very hard to improve the previous patch. The
current patchset is almost free for LKCD origin code and clean. I'm now
reviewing the experimental patch for crash and found it is relatively
small(600step) and clean as experimental. I'll upload the crash patch. Please
see and evaluate it.
Comment 4 Nobuhiro Tachino 2005-10-24 18:49:54 EDT
Created attachment 120330 [details]
crash.patch

This is the patch for crash to support compressible dump. This is the first and
experimental patch and will be changed later.
Comment 5 Dave Anderson 2005-10-25 09:15:31 EDT
> This is the patch for crash to support compressible dump. This is the first and
> experimental patch and will be changed later.

Outstanding!  This is exactly what I wanted to see -- nice work!


Comment 6 Larry Troan 2005-10-30 17:50:35 EST
Looks like the NEEDINFO_REPORTER has been satisfied. Setting to ASSIGNED.
Comment 9 Dave Anderson 2005-10-31 08:52:56 EST
> Looks like the NEEDINFO_REPORTER has been satisfied. Setting to ASSIGNED.

Not really.  Comment #4 indicates:

> This is the first and experimental patch and will be changed later.

Just to be clear, I, the "assignee", am still waiting for the "reporter"
to provide their final, non-experimental, patch.
Comment 11 Dave Anderson 2005-11-01 08:47:31 EST
How can this be NAK'd if the related diskdump bugzillas are still 
in play?  Diskdump bugzillas 168641 and 171141 are both RHEL4U3CanFix:

Bugzilla Bug 168641 – FEAT RHEL4 U3 [diskdump]: Support compressing dump data
Bugzilla Bug 171141 – FEAT RHEL4 U3 [diskdump]: kernel - support compressing dump

It makes no sense to put this diskdump feature in place if crash can't
read the dumpfile!  It's a three-part feature:

 168641 - diskdumputils user package changes for creating new dumpfile format
 171141 - diskdump kernel module changes for creating new dumpfile format
 171137 - crash utility changes to read new dumpfile format

If you NAK one, you've got to NAK them all.

Peter and/or Linda -- please raise this issue at the next RHEL meeting.

 
Comment 13 Nobuhiro Tachino 2005-11-01 14:10:18 EST
Created attachment 120618 [details]
crash-compress-3.patch

This is the updated patch for compressed dump support for crash. It includes
performance improvement by caching index values of page_desc_t and clean up.
The size of patch became a bit smaller than the previous one. If no problem is
found, this will be the final proposed patch. Please review this.
Comment 14 Larry Troan 2005-11-01 15:47:38 EST
Flipping to ASSIGNED as Tachino-san has provided what they believe is their
final pass (what Engineering was waiting for). 

Has this patch been submitted upstream? Accepted? 
Comment 16 Nobuhiro Tachino 2005-11-01 16:03:27 EST
(In reply to comment #14)
> Has this patch been submitted upstream? Accepted? 

Hi,

Dave is the upstream maintainer of crash and he decides the patch is acceptable
or not.
Comment 17 Dave Anderson 2005-11-01 16:48:06 EST
Thanks, Nobuhiro.  I'll review the patch, and if acceptable, I'll fold
it into a new upstream version for Fujitsu and NEC to sanity-check and
verify.  Then that version will subsequently be used as a base to create
a beehive-built version for the RHEL4-U3 errata procedure.



Comment 18 Dave Anderson 2005-11-02 10:14:34 EST
The patch looks good.  Thanks to both NEC and Fujitsu for their time and effort.
I will update the upstream package shortly.

Whenever work of this magnitude is added to the crash utility, I have
always wanted to give credit where credit is due.  During crash initialization,
a list of the companies who have made major contributions have their copyrights
shown:

# crash

crash 4.0-2.7
Copyright (C) 2002, 2003, 2004, 2005  Red Hat, Inc.
Copyright (C) 2004, 2005  IBM Corporation
Copyright (C) 1999-2005  Hewlett-Packard Co
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.
...

I would like to add Fujitsu and NEC to the list.  In the past, each company
has preferred that their company "name string" be presented in a specific
manner, i.e., IBM wanted it to be "IBM Corporation", and HP wanted theirs
to be "Hewlett-Packard Co".

If Fujitsu and NEC does not want to be listed, that's fine too.
  
But if they do, how should each company name string be listed?

  
Comment 19 Akira Imamura 2005-11-02 11:20:27 EST
> I would like to add Fujitsu and NEC to the list.  In the past, each company
> has preferred that their company "name string" be presented in a specific
> manner, i.e., IBM wanted it to be "IBM Corporation", and HP wanted theirs
> to be "Hewlett-Packard Co".
That sounds great to us! Thanks!

> If Fujitsu and NEC does not want to be listed, that's fine too.
We want to, but we don't know what NEC guys think. So we need to ask them
about that.

> But if they do, how should each company name string be listed?
I'll ask Fujitsu Japan about that. Then, I'll let you know how. As for
NEC guys, if they do, I'll also ask them.

Does that make sense?
Comment 20 Dave Anderson 2005-11-02 11:34:21 EST
> I'll ask Fujitsu Japan about that. Then, I'll let you know how. As for
> NEC guys, if they do, I'll also ask them.
>
> Does that make sense?

Sure, that's fine -- I'll wait until you indicate final approval from
both NEC and Fujitsu.

Other than that, I've made only minor modifications to your last patch,
mainly changes to error messages.  For example, we don't want to
print error messages in read_netump_header() until *after* the
header's signature has been read and confirmed -- at least unless
CRASHDEBUG(1) is set.  Since is_diskdump() is called in main()
*before* is_lkcd_compressed_dump(), is_system_map() and is_s390_dump(),
you would see unnecessary "dump does not have panic dump header"
messages for those types of files.

Comment 21 Dave Anderson 2005-11-02 11:36:39 EST
s/read_netump_header/read_dump_header/
Comment 22 Dave Anderson 2005-11-03 15:45:36 EST
I've update the upstream version of crash to 4.0-2.9:

  http://people.redhat.com/anderson

As I mentioned above, I made a few minor changes that deal with
error messages, as well as a few unused variable removals that
allow crash to be built via "make Warn".

Can you please sanity check this version?  If it's OK, I will take
a snapshot of this release for use in the RHEL4-U3 crash-utility errata.

Note that I did not add NEC and Fujitus to the "credits", but will
do so if you tell me it's OK, and what name string to use.

Thanks,
  Dave

Comment 23 Nobuhiro Tachino 2005-11-03 17:04:16 EST
The patch looks fine. I tested 4.0-2.9 on ia64 machine in the lab and it worked
with no problem. Thanks!
Comment 24 Dave Anderson 2005-11-03 17:09:33 EST
OK, great, thanks!
Comment 25 Nobuhiro Tachino 2005-11-04 10:26:16 EST
I received the reply from NEC and Fujitsu Japan regarding to their opyrights.

Fujitsu:
Copyright (C) 2005  FUJITSU LIMITED

NEC:
Copyright (C) 2005  NEC Corporation

Thank you.
Comment 26 Dave Anderson 2005-11-04 14:59:20 EST
I don't mean to be a bother here, but, is there any legal reason that
the Fujitsu name cannot be expressed in lower-case?  In other words,
can I make it:

  Copyright (C) 2005  Fujitsu Limited

instead of: 

  Copyright (C) 2005  FUJITSU LIMITED

I ask because it looks a little strange compared to the others:

  $ crash -v

  crash 4.0-2.9a
  Copyright (C) 2002, 2003, 2004, 2005  Red Hat, Inc.
  Copyright (C) 2004, 2005  IBM Corporation
  Copyright (C) 1999-2005  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.

  $
Comment 27 Nobuhiro Tachino 2005-11-04 15:18:51 EST
It shows up more than others, but that's not our intention ;-) The uppercase
copyright is just our standard format. But I believe "Fujitsu Limited" is fine too.
Please change it.
Comment 29 Dave Anderson 2005-11-21 15:02:46 EST
Please QA ack this bugzilla. It has PM and DEVEL acks, and I need
to start the errata process ASAP.
Comment 30 Dave Anderson 2005-11-21 16:17:16 EST
> Please QA ack this bugzilla. It has PM and DEVEL acks, and I need
> to start the errata process ASAP.

Note also that the blocked diskdumputils bugzilla:

  Bugzilla Bug 168641 – FEAT RHEL4 U3 [diskdump]: Support compressing dump data

does have all 3 ACKS, but you can't have one without the other.

Please give this BZ a QA_ACK!
Comment 31 Akira Imamura 2005-11-21 17:20:32 EST
We, Fujitsu, are to do testing against crash package because this feature
was submitted by us. We should be responsible for this BZ. So please give
this BZ a QA_ACK.

Best regards,
Akira
Comment 34 Dave Anderson 2005-11-30 16:19:52 EST
Fujitsu testing of the compressed diskdump format uncovered a
bug with the "bt" command for ppc64 dumpfile only, which will
require a package update from 4.0-2.14 to 4.0-2.15.
Comment 35 Keiichiro Tokunaga 2005-12-01 15:15:17 EST
The testing of 4.0-2.15 has been completed and no problems were found.
Comment 40 Red Hat Bugzilla 2006-03-07 13:26:46 EST
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHEA-2006-0075.html

Note You need to log in before you can comment on or make changes to this bug.