Hide Forgot
Description of problem: When run kdump test analyse-crash-live, got these output: ============================================================== - only check the return code of this session. - # crash -i /mnt/testarea/crash-simple.cmd - also check command output of this session. - # crash -i /mnt/testarea/crash.cmd - skip the following patterns when searching for potential errors. - 'error_' - 'ERROR_' - '-error' - '_error' - 'Data Access error' - 'invalid float value' - '_fail' - 'failsafe' - 'invalid_' - 'invalidate' - 'PCIBR error' - 'TIOCE error' - 'task_beah_unexpected' - search for the following patterns for potential errors. - 'fail' - 'error' - 'invalid' - 'absurdly large unwind_info' - 'unexpected' c000000068d79730: 00003eb27200000d __kstrtab_drm_mode_prune_invalid c000000068d798e0: 000040c564000017 __ksymtab_drm_mode_prune_invalid c000000068d79a90: 000042d864000019 __kcrctab_drm_mode_prune_invalid - fail: crash commands have some failures. Version-Release number of selected component (if applicable): kernel-2.6.32-119.el6 crash-5.1.1-1.el6.ppc64 How reproducible: ibm-js22-07.rhts.eng.bos.redhat.com Steps to Reproduce: 1.Install RHEL6.1-20110224.2 on ibm-js22-07.rhts.eng.bos.redhat.com 2.Run analyse-crash-live 3. Actual results: Expected results: Additional info: https://beaker.engineering.redhat.com/recipes/119029
> https://beaker.engineering.redhat.com/recipes/119029 That link shows this: Invalid R:119029, has been deleted Anyway, my best guess is the the /mnt/testarea/crash.cmd command list may be doing a "rd -s <address> <length>" command? "__kstrtab_drm_mode_prune_invalid" is just a symbol from the "drm" module: crash> sym __kstrtab_drm_mode_prune_invalid ffffffffa0066a4f (r) __kstrtab_drm_mode_prune_invalid [drm] crash> And so if I search kernel virtual memory for all instances of that value: crash> search -k ffffffffa0066a4f ffff88001f0b0b60: ffffffffa0066a4f ffff88001feadba8: ffffffffa0066a4f ffff8800206d0ba8: ffffffffa0066a4f ffff880035075040: ffffffffa0066a4f ffff880037d39898: ffffffffa0066a4f ffff880037d44708: ffffffffa0066a4f ffffffffa0065898: ffffffffa0066a4f ffffffffa0070708: ffffffffa0066a4f crash> If I take any of memory addresses above, subtract 8, I can mimic your output: > c000000068d79730: 00003eb27200000d __kstrtab_drm_mode_prune_invalid > c000000068d798e0: 000040c564000017 __ksymtab_drm_mode_prune_invalid > c000000068d79a90: 000042d864000019 __kcrctab_drm_mode_prune_invalid by doing this with "rd -s": crash> rd -s ffff880037d44700 2 ffff880037d44700: 0019007200003d1c __kstrtab_drm_mode_prune_invalid crash> Aside from the fact that your output is from a ppc64 machine and mine is x86_64, I'm presuming that your test is doing a "rd -s" on a large chunk of memory, and bumping into instances of that symbol value. (and seeing "invalid" in the output) In any case, that's certainly not a bug.
Tested on ibm-js22-07.rhts.eng.bos.redhat.com with kernel-2.6.32-119.el6/crash-5.1.1-1.el6.ppc64 again, no such issue was found. https://beaker.engineering.redhat.com/jobs/58856
> Tested on ibm-js22-07.rhts.eng.bos.redhat.com with > kernel-2.6.32-119.el6/crash-5.1.1-1.el6.ppc64 again, no such issue was found. Do you not understand my comment #2? There is no *issue* to begin with. When you ran the test a second time, by luck it did not "rd -s" any memory that contained the __kcrctab_drm_mode_prune_invalid symbol. It is NOT a bug -- you have to fix your test program. You cannot simply "grep invalid" the output of all crash commands, because it will pick up legitimate output like this.