Bug 827369 - v7/kdump still report PASS if reboot took more than limited time
Summary: v7/kdump still report PASS if reboot took more than limited time
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Hardware Certification Program
Classification: Retired
Component: Test Suite (tests)
Version: 1.5
Hardware: All
OS: All
high
high
Target Milestone: ---
: ---
Assignee: Caspar Zhang
QA Contact: Guangze Bai
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-06-01 09:05 UTC by Caspar Zhang
Modified: 2015-02-08 21:38 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-02-01 18:20:25 UTC
Embargoed:


Attachments (Terms of Use)
kdump patch fixing pass/fail handling (668 bytes, patch)
2012-10-12 16:23 UTC, Greg Nichols
czhang: review+
Details | Diff


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2013:0222 0 normal SHIPPED_LIVE v7 bug fix and enhancement update 2013-02-01 23:18:53 UTC

Description Caspar Zhang 2012-06-01 09:05:51 UTC
Description of problem:

If a reboot takes more than 10 minutes, kdump test will display this error, but the whole test still PASS:

<output name="verify">
reboot took 00:16:00
method: panic
kernel: 2.6.32-276.el6.x86_64
Error: reboot took longer that 10 minutes
Attempting to mount net setting gnichols.usersys.redhat.com:/var/www/v7/export as nfs.
Looking for vmcore image directories under v7-net/var/crash
...
Found kdump image: v7-net/var/crash/10.66.86.24-2012-06-01-04:15:15/vmcore
      KERNEL: /usr/lib/debug/lib/modules/2.6.32-276.el6.x86_64/vmlinux
    DUMPFILE: v7-net/var/crash/10.66.86.24-2012-06-01-04:15:15/vmcore  [PARTIAL DUMP]
        CPUS: 8
        DATE: Fri Jun  1 04:13:36 2012
      UPTIME: 00:06:34
LOAD AVERAGE: 0.83, 0.50, 0.22
       TASKS: 252
    NODENAME: ibm-ls22-01.rhts.eng.nay.redhat.com
     RELEASE: 2.6.32-276.el6.x86_64
     VERSION: #1 SMP Tue May 29 17:38:19 EDT 2012
     MACHINE: x86_64  (1899 Mhz)
      MEMORY: 16 GB
       PANIC: "Oops: 0002 [#1] SMP " (check log for details)
kdump image v7-net/var/crash/10.66.86.24-2012-06-01-04:15:15/vmcore verified
</output>

....

v7 print --last

....
Test Run 1
----------------------------------------------------------------
....                                                 - 
kdump   nfs                                          - PASS
kdump   local                                        - PASS
....

Version-Release number of selected component (if applicable):
V7-1.5 R25

How reproducible:
always

Steps to Reproduce:
1. make your kdump test reboot longer than 10 minutes
2.
3.
  
Actual results:


Expected results:


Additional info:

Related code:

379     def run(self):
380         PASSED = 0
381         FAILED = 1
382                  
383         if self.incomplete and self.continuation.isInitialized():
384             self.markOutput("verify")
385             result = self.continuation.verify(marker=self.Name()) <--
386             self.continuation.removeInitConfig()
387             if self.continuation.getMethod() == Constants.panic:
388                 result = self.verifyKDumpImage()                  <--
389             self.closeOutput()
390         else:    
391             result = self.panic()
392                  
393         if result: return PASSED


I don't think it will blocker v7-1.5, the log still puts out "FAIL", it just cause some confusion those who needs to check return values... (return value not work in V7-1.4, but no customer complained...)

Comment 1 Greg Nichols 2012-10-12 16:23:26 UTC
Created attachment 626110 [details]
kdump patch fixing pass/fail handling

Comment 7 errata-xmlrpc 2013-02-01 18:20:25 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2013-0222.html


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