Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
> 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.
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.