xportshow -x traceback on kernel 5.14.21-150500.55.52-default
Fixed in [21da81]
Caused by removal of "hash" field from struct unix_address in patch "af_unix: Save hash in sk_hash" (https://lists.openwall.net/netdev/2021/11/24/34). Fixed in [21da81].
xportshow -x traceback on kernel 5.14.21-150500.55.52-default
Remove prio2band from netdevice
Home
crashinfo aborts in crash7, but not crash8
[6af99b]
Fixed in [6af99b].
That's very strange...I can reproduce the error with crash7, but it works fine on crash8. I'll look into this, but in the meantime you could try switching to crash8 (which I would recommend anyway, as it has many improvements and is much faster to start up on large vmcores).
crashinfo aborts in crash7, but not crash8
Can you try with the latest PyKdump version, which is 3.9.1? You can download the .so file from https://sourceforge.net/projects/pykdump/files/mpykdump-x86_64/. There are separate versions for crash7 and crash8: mpykdump-3.9.1-crash7.so mpykdump-3.9.1-crash8.so Use the one that matches your version of crash. There are also many improvements and bug fixes in PyKdump 3.9 compared to 3.5.
Add a documentation page for tslog
Closed with [4a89db].
Add a documentation page for tslog
Add '-c' option to tslog command
Closed with [718c17].
crashinfo --checkstacks aborts
Closed with commit [78b250]
This turned out to be two different aborts: one due to the relocation of restart_block from thread_info to task_struct in kernel v4, and the other due to the removal of thread_struct.sp0 from x86_64 kernels starting with 4.14.9.
crashinfo --checkstacks aborts
Add '-c' option to tslog command
No, you were staring at what should have been the correct code. The problem was the commit with that bit of code (and only that one, as far as I can tell) got left out of the previous build.
I’m pleased to announce the release of PyKdump version 3.9.1. All commits in the dev branch have been merged into the master branch, and new precompiled extension files are available for crash versions 7 and 8. These are available in the Files section of this site: mpykdump-3.9.1-crash7.so mpykdump-3.9.1-crash8.so The new version includes many improvements and bug fixes. Some of the highlights: Six new commands: cifsshow - Print information about cifs mounts detailedsearch - Search for a value and...
Hi Martin, PyKdump 3.9.1 is now released (see announcment in Open Discussion section). You can download new precompiled extensions, and this should resolve your issue. Thanks again for reporting it. Regards, (the other) Martin
I’m pleased to announce the release of PyKdump version 3.9.1. All commits in the dev branch have been merged into the master branch, and new precompiled extension files are available for crash versions 7 and 8. These are available in the Files section of this site: mpykdump-3.9.1-crash7.so mpykdump-3.9.1-crash8.so The new version includes many improvements and bug fixes. Some of the highlights: Six new commands: cifsshow - Print information about cifs mounts detailedsearch - Search for a value and...
I found the problem. Due to a slight build mishap, the commit that added followlinks=True wasn't included in the precompiled builds. With it included, following symlinks to load modules works fine. Your timing with this report was excellent. I'm close to releasing new precompiled versions and will include this fix. Thanks for reporting it; I'm surprised that it didn't surface earlier.
No need for you to try building from source - I've reproduced the behavior.
Can you try building the extension from source (see https://pykdump.readthedocs.io/en/latest/install/build-steps.html for instructions) and see if that works in your environment?
Fix the duplicate lines in stdin when call crash command in child process
Thank you for the detailed problem description and reproducer. However, I can't reproduce the duplicate output lines on my build system, which is running RHEL 7. Is the behavior specific to Debian?
scsishow: enable for zfcp device driver
follow links when searching kernel modules