makedumpfile (1:1.7.5-1)
[PTS] [DDPO]
COMMITS: VCS has seen 26 commits since the debian/1%1.7.4-1 tag
- Git: https://salsa.debian.org/debian/makedumpfile.git
-
- Branch: master
- Path: debian/changelog
- Repo size: 868352
- Browser: https://salsa.debian.org/debian/makedumpfile
- Last scan: 2024-04-19 14:33:12+00
- Next scan: 2024-04-25 23:05:00+00
- Debian changelog in Git:
makedumpfile (1:1.7.5-1) unstable; urgency=medium
* Update to new upstream version 1.7.5.
-- dann frazier <dannf@debian.org> Fri, 12 Apr 2024 07:57:10 -0600
- This branch is 26 commits ahead of tag debian/1%1.7.4-1
- Git log:
commit e66a1a5ce0111495aebbfa8ae44d43a44eaf2d52
Merge: 2425f43 7e3e55b
Author: dann frazier <dannf@debian.org>
Date: Fri Apr 12 07:58:17 2024 -0600
Declare fast forward / record previous work
[git-debrebase pseudomerge: quick]
commit 2425f43f67ecb5d6b886d9f418c4f6b6f2385fa7
Author: Louis Bouchard <louis.bouchard@ubuntu.com>
Date: Mon Dec 17 15:21:09 2018 -0200
adapt-makefile-to-debian
===================================================================
Gbp-Pq: Name 0002-adapt-makefile-to-debian.patch
commit 99713582ecab15908d52ae52acca5d9fca333c32
Author: dann frazier <dannf@debian.org>
Date: Fri Apr 12 07:57:39 2024 -0600
releasing package makedumpfile version 1:1.7.5-1
commit 2d21066f986201dacbb922c2c68f18d356a70fb5
Author: dann frazier <dannf@debian.org>
Date: Fri Apr 12 07:55:37 2024 -0600
Update changelog for new upstream 1:1.7.5
[git-debrebase changelog: new upstream 1:1.7.5]
commit b4caa5761139f516f7c7fb5337b1359ab68d2e5e
Merge: 9b79809 c266469
Author: dann frazier <dannf@debian.org>
Date: Fri Apr 12 07:55:37 2024 -0600
Update to upstream 1:1.7.5
[git-debrebase anchor: new upstream 1:1.7.5, merge]
commit 9b798095f2f44b3e48046b5df9b91b157d0edf29
Author: dann frazier <dannf@debian.org>
Date: Fri Nov 10 00:03:28 2023 +0200
releasing package makedumpfile version 1:1.7.4-1
commit c266469347d49287be38059d45e7aaa454db9cb2
Author: Kazuhito Hagio <k-hagio-ab@nec.com>
Date: Fri Apr 12 14:09:09 2024 +0900
[v1.7.5] Update version
Update makedumpfile to version 1.7.5.
This version supports the following new kernels:
- 6.7, 6.8 (x86_64)
Signed-off-by: Kazuhito Hagio <k-hagio-ab@nec.com>
commit 94241fd2feed059227a243618f2acc6aabf366e8
Author: Aditya Gupta <adityag@linux.ibm.com>
Date: Sat Feb 24 00:33:42 2024 +0530
[PATCH] ppc64: get vmalloc start address from vmcoreinfo
Below error was noticed when running makedumpfile on linux-next kernel
crash (linux-next tag next-20240121):
Checking for memory holes : [100.0 %] | readpage_elf: Attempt to read non-existent page at 0xc000000000000.
[ 17.551718] kdump.sh[404]: readmem: type_addr: 0, addr:c00c000000000000, size:16384
[ 17.551793] kdump.sh[404]: __exclude_unnecessary_pages: Can't read the buffer of struct page.
[ 17.551864] kdump.sh[404]: create_2nd_bitmap: Can't exclude unnecessary pages.
[ 17.562632] kdump.sh[404]: The kernel version is not supported.
[ 17.562708] kdump.sh[404]: The makedumpfile operation may be incomplete.
[ 17.562773] kdump.sh[404]: makedumpfile Failed.
[ 17.564335] kdump[406]: saving vmcore failed, _exitcode:1
Above error was due to 'vmap_area_list' and 'vmlist' symbols missing
from the vmcore. 'vmap_area_list' was removed in the linux kernel
6.9-rc1 by the commit below:
commit 55c49fee57af99f3c663e69dedc5b85e691bbe50
mm/vmalloc: remove vmap_area_list
Subsequently the commit also introduced 'VMALLOC_START' in vmcoreinfo to
get base address of vmalloc area, instead of depending on 'vmap_area_list'
Hence if 'VMALLOC_START' symbol is there in vmcoreinfo:
1. Set vmalloc_start based on 'VMALLOC_START'
2. Don't error if vmap_area_list/vmlist are not defined
Reported-by: Sachin Sant <sachinp@linux.ibm.com>
Signed-off-by: Aditya Gupta <adityag@linux.ibm.com>
commit 71ac00c8a3464608ac19f7c89d7220073d7374a9
Author: Aditya Gupta <adityag@linux.ibm.com>
Date: Fri Feb 23 14:09:13 2024 +0530
[PATCH] ppc64: read cur_mmu_type from vmcoreinfo
Currently makedumpfile depends on reading the 'cur_cpu_spec' kernel
symbol to get the current MMU type on PowerPC64.
The disadvantage with this approach was that it depends on bit '0x40'
('MMU_FTR_TYPE_RADIX') being set in 'cur_cpu_spec->mmu_features',
which implies kernel developers have to be careful of modifying
MMU_FTR_* defines.
Instead a more stable approach was suggested by contributors in [1], to
pass information about the MMU type in vmcoreinfo itself, instead of
depending on the MMU_FTR_* defines.
This was implemented in linux kernel in:
commit 36e826b568e4 ("powerpc/vmcore: Add MMU information to vmcoreinfo")
With this commit, if RADIX_MMU is there in the vmcoreinfo, we prefer it
to get current mmu type, instead of 'cur_cpu_spec'.
On older kernels, where RADIX_MMU number is not there, makedumpfile will
simply fall back to using 'cur_cpu_spec'.
The earlier defines for 'RADIX_MMU' have been renamed to 'MMU_TYPE_RADIX'
which avoids conflict with the vmcoreinfo string 'RADIX_MMU', as well as
being more clear about the value 0x40 with a comment about MMU_FTR_TYPE_RADIX.
[1] https://lore.kernel.org/linuxppc-dev/87v8c3m70t.fsf@mail.lhotse/
Signed-off-by: Aditya Gupta <adityag@linux.ibm.com>
commit 48bb1e089056d7d14aadeefd141f66a487faabac
Author: Edward Chron <echron@arista.com>
Date: Thu Dec 28 12:33:26 2023 -0800
[PATCH] add PRINTK_CALLER id support to --dump-dmesg option
Add support so that dmesg entries include the optional Linux Kernel
debug CONFIG option PRINTK_CALLER which adds an optional dmesg field
that contains the Thread Id or CPU Id that is issuing the printk to
add the message to the kernel ring buffer. If enabled, this CONFIG
option makes debugging simpler as dmesg entries for a specific
thread or CPU can be recognized.
The dmesg command supports printing the PRINTK_CALLER field. The
old syslog format (dmesg -S) and recently support was added for dmesg
using /dev/kmsg interface.
The additional field provided by PRINTK_CALLER is only present
if it was configured for the Linux kernel on the running system. The
PRINTK_CALLER is a debug option and not configured by default so the
dmesg output will only change for those kernels where the option was
configured when the kernel was built. For users who went to the
trouble to configure PRINTK_CALLER and have the extra field available
for debugging, having dmesg print the field is very helpful and so
it would be very useful to add makedumpfile support for it.
The PRINTK_CALLER field is printed as T<id> for a Task Id or C<id>
for a CPU Id for a printk in CPU context. The values are left space
padded and enclosed in parentheses such as:
[ T123] or [ C16]
For dmesg command the PRINTK_CALLER field when present is the last
field before the dmesg text so it makes sense to use the same format.
Resolves: https://github.com/makedumpfile/makedumpfile/issues/13
Signed-off-by: Ivan Delalande <colona@arista.com>
Signed-off-by: Edward Chron <echron@arista.com>
Signed-off-by: Kazuhito Hagio <k-hagio-ab@nec.com>
commit 6f8325d72b0767dd964485086f77318fc2edc418
Author: Alexander Gordeev <agordeev@linux.ibm.com>
Date: Tue Dec 5 16:01:51 2023 +0100
[PATCH v2 2/2] s390x: uncouple virtual and physical address spaces
Rework vaddr_to_paddr() and paddr_to_vaddr() macros to reflect
the future uncoupling of physical and virtual address spaces in
kernel. Existing versions are not affected.
Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
commit 7bb90b7caaa449af6aef708f2620e803a0c0aa25
Author: Alexander Gordeev <agordeev@linux.ibm.com>
Date: Wed Nov 29 13:50:11 2023 +0100
[PATCH 1/2] s390x: fix virtual vs physical address confusion
Physical and virtual addresses are the same on S390X.
That led to misuse of readmem() address type.
Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
commit 4030b6ad456c23053456364b4da9f53ffb7d693a
Author: Kazuhito Hagio <k-hagio-ab@nec.com>
Date: Wed Dec 6 13:35:02 2023 +0900
[PATCH] Mark start of 1.7.5 development phase with version 1.7.4++
Signed-off-by: Kazuhito Hagio <k-hagio-ab@nec.com>
