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>
Among the 1 debian patch available in version 1:1.7.5-1 of the package, we noticed the following issues: