kexec January 2014

kexec@lists.fedoraproject.org

7 participants
16 discussions

[PATCH] insert wdt kernel modules when watchdog is active
by Baoquan He 13 Feb '14

13 Feb '14

When watchdog is enabled in 1st kernel, then crash dump in kdump kernel will be interrupted if watchdog is timeout. Since some wdt drivers can stop the watchdog when its driver is loaded, e.g iTCO_wdt, this can benefit crash dump. Add watchdog driver which is active in system to initramfs, its loading can stop watchdog. For now, put this adding in 99kdumpbase. Signed-off-by: Baoquan He <bhe(a)redhat.com> --- dracut-module-setup.sh | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/dracut-module-setup.sh b/dracut-module-setup.sh index c013430..d1ba83e 100755 --- a/dracut-module-setup.sh +++ b/dracut-module-setup.sh @@ -418,3 +418,11 @@ install() { # at some point of time. kdump_check_iscsi_targets } + +installkernel() { + wdt=$(lsmod|cut -f1 -d' '|grep "wdt$") + if [ -n "$wdt" ]; then + instmods $wdt + [ "$wdt" = "iTCO_wdt" ] && instmods lpc_ich + fi +} -- 1.8.3.1

3 8

[PATCH 0/6] kdump: Modify kdump init script to support firmware-assisted dump
by Hari Bathini 05 Feb '14

05 Feb '14

This patch set implements firmware-assisted dump support for kdump service. Firmware-assisted dump support depends on existing kdump infrastructure (kdump scripts) present in userland to save dump to the disk. Though existing kdump script will work seemlessly, it still needs to modified to make it aware of presense of firmware- assisted dump feature during service start and stop. These changes are tested successfully on a power box with fedora19. --- Hari Bathini (6): kdump: Modify status() routine to check for firmware-assisted dump kdump: Modify kdump script to start the firmware assisted dump. kdump: Modify kdump script to stop firmware assisted dump kdump: Take a backup of original default initrd before rebuilding. kdump: Rebuild default initrd for firmware assisted dump kdump: Check for /proc/vmcore existence before capturing the vmcore. dracut-kdump.sh | 3 + kdumpctl | 181 ++++++++++++++++++++++++++++++++++++++++++++++++++----- 2 files changed, 169 insertions(+), 15 deletions(-) -- - Hari

2 11

[PATCH] Add acpi_no_memhotplug to kdump kernel
by Baoquan He 29 Jan '14

29 Jan '14

In kdump kernel boot, kdump kernel is booted with memmap= and add them into e820 map. Then ACPI is initialized and the kernel traverses the ACPI namespace to find entries for memory device to be hot added. This adds page table information and the kexec/kdump kernel runs out of memory. So in kdump kernel, hot plug memory need be disabled always, only exact map is trusted. Now add the kernel parameter acpi_no_memhotplug to kdump kernel cmdline. Signed-off-by: Baoquan He <bhe(a)redhat.com> --- kdump.sysconfig.x86_64 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kdump.sysconfig.x86_64 b/kdump.sysconfig.x86_64 index 7e4d611..989c3c7 100644 --- a/kdump.sysconfig.x86_64 +++ b/kdump.sysconfig.x86_64 @@ -16,7 +16,7 @@ KDUMP_COMMANDLINE="" # This variable lets us append arguments to the current kdump commandline # As taken from either KDUMP_COMMANDLINE above, or from /proc/cmdline -KDUMP_COMMANDLINE_APPEND="irqpoll nr_cpus=1 reset_devices cgroup_disable=memory mce=off numa=off udev.children-max=2 panic=10 rootflags=nofail" +KDUMP_COMMANDLINE_APPEND="irqpoll nr_cpus=1 reset_devices cgroup_disable=memory mce=off numa=off udev.children-max=2 panic=10 rootflags=nofail acpi_no_memhotplug" # Any additional kexec arguments required. In most situations, this should # be left empty -- 1.8.3.1

4 5

[PATCH v3 0/6] Add fence kdump support
by WANG Chao 28 Jan '14

28 Jan '14

This is a patchset to add fence kdump support. In cluster environment, fence kdump is used to notify all the other nodes that current is crashed and stop from being fenced off. The patchset has the following features: 1. rebuild kdump initrd regarding timestamp of fence kdump config or cluster configuration. 2. setup a required working environment for fence kdump in 2nd kernel. 3. fence_kdump_send notify other nodes to stop the crashed one being fenced off before dumping process. 4. add kdump-in-cluster-environment.txt v2->v3: From Vivek: (4/6) kdump.sh: make var nodes local (6/6) module-setup: avoid adding duplicates instead of removing them at last WANG Chao (5): kdump-lib: add common variables and function for fence kdump kdumpctl: rebuild kdump initramfs if cluster or fence_kdump config is changed. kdump.sh: send fence kdump message to other nodes in the cluster module-setup.sh: setup fence kdump environment module-setup: remove duplicated ip= line arthur (1): doc: Add kdump-in-cluster-environment.txt dracut-kdump.sh | 15 +++++++++++ dracut-module-setup.sh | 54 ++++++++++++++++++++++++++++++++++++-- kdump-in-cluster-environment.txt | 56 ++++++++++++++++++++++++++++++++++++++++ kdump-lib.sh | 17 +++++++++++- kdumpctl | 26 +++++++++++++++++++ kexec-tools.spec | 3 +++ 6 files changed, 168 insertions(+), 3 deletions(-) create mode 100644 kdump-in-cluster-environment.txt -- 1.8.4.2

2 7

[PATCH v2 0/6] Add fence kdump support
by WANG Chao 28 Jan '14

28 Jan '14

This is a patchset to add fence kdump support. In cluster environment, fence kdump is used to notify all the other nodes that current is crashed and stop from being fenced off. The patchset has the following features: 1. rebuild kdump initrd regarding timestamp of fence kdump config or cluster configuration. 2. setup a required working environment for fence kdump in 2nd kernel. 3. fence_kdump_send notify other nodes to stop the crashed one being fenced off before dumping process. 4. add kdump-in-cluster-environment.txt WANG Chao (5): kdump-lib: add common variables and function for fence kdump kdumpctl: rebuild kdump initramfs if cluster or fence_kdump config is changed. kdump.sh: send fence kdump message to other nodes in the cluster module-setup.sh: setup fence kdump environment module-setup: remove duplicated ip= line arthur (1): doc: Add kdump-in-cluster-environment.txt dracut-kdump.sh | 15 +++++++++++ dracut-module-setup.sh | 54 ++++++++++++++++++++++++++++++++++++-- kdump-in-cluster-environment.txt | 56 ++++++++++++++++++++++++++++++++++++++++ kdump-lib.sh | 17 +++++++++++- kdumpctl | 26 +++++++++++++++++++ kexec-tools.spec | 3 +++ 6 files changed, 168 insertions(+), 3 deletions(-) create mode 100644 kdump-in-cluster-environment.txt -- 1.8.4.2

5 34

[PATCH rawhide] makedumpfile: memset() in cyclic bitmap initialization introduce segment fault.
by WANG Chao 28 Jan '14

28 Jan '14

This is a backport of the following upstream commit: commit 4404368 Author: WANG Chao <chaowang(a)redhat.com> Date: Wed Dec 18 22:34:43 2013 +0900 [PATCH] memset() in cyclic bitmap initialization introduce segment fault. We are using memset() to improve performance when creating 1st and 2nd bitmap. After doing round up the pfn_start and round down pfn_end, it's possible that pfn_start_roundup is greater than pfn_end_round. A segment fault could happen in that case because memset is taking roughly the value of (pfn_end_round << 3 - pfn_start_roundup << 3 ), which is negative, as its third argument. So we can skip the memset if start is greater than end. It's safe because we will set bit for the round up part and also round down part. Actually this happens on my EFI virtual machine: cat /proc/iomem: 00000000-00000fff : reserved 00001000-0009ffff : System RAM 000a0000-000bffff : PCI Bus 0000:00 000f0000-000fffff : System ROM 00100000-3d162017 : System RAM 01000000-015cab9b : Kernel code 015cab9c-019beb3f : Kernel data 01b4f000-01da9fff : Kernel bss 30000000-37ffffff : Crash kernel 3d162018-3d171e57 : System RAM 3d171e58-3d172017 : System RAM 3d172018-3d17ae57 : System RAM 3d17ae58-3dc10fff : System RAM 3dc11000-3dc18fff : reserved 3dc19000-3dc41fff : System RAM 3dc42000-3ddcefff : reserved 3ddcf000-3f7fefff : System RAM 3f7ff000-3f856fff : reserved [..] gdb ./makedumpfile core (gdb) bt full [..] #1 0x000000000042775d in create_1st_bitmap_cyclic () at makedumpfile.c:4543 i = 0x5 pfn = 0x3d190 phys_start = 0x3d18ee58 phys_end = 0x3d18f018 pfn_start = 0x3d18e pfn_end = 0x3d18f pfn_start_roundup = 0x3d190 pfn_end_round = 0x3d188 pfn_start_byte = 0x7a32 pfn_end_byte = 0x7a31 [..] (gdb) list makedumpfile.c:4543 4538 return FALSE; 4539 4540 pfn_start_byte = (pfn_start_roundup - info->cyclic_start_pfn) >> 3; 4541 pfn_end_byte = (pfn_end_round - info->cyclic_start_pfn) >> 3; 4542 4543 memset(info->partial_bitmap2 + pfn_start_byte, 4544 0xff, 4545 pfn_end_byte - pfn_start_byte); 4546 4547 for (pfn = pfn_end_round; pfn < pfn_end; ++pfn) Signed-off-by: WANG Chao <chaowang(a)redhat.com> This patch fixes segment fault issues on the systems with very small memory map range (less than 8 pages). Signed-off-by: WANG Chao <chaowang(a)redhat.com> --- The regression is introduced in makedumpfile-1.5.5. So this patch is for rawhide/f21 only. ...t-in-cyclic-bitmap-initialization-introdu.patch | 112 +++++++++++++++++++++ 1 file changed, 112 insertions(+) create mode 100644 kexec-tools-2.0.4-makedumpfile-memset-in-cyclic-bitmap-initialization-introdu.patch diff --git a/kexec-tools-2.0.4-makedumpfile-memset-in-cyclic-bitmap-initialization-introdu.patch b/kexec-tools-2.0.4-makedumpfile-memset-in-cyclic-bitmap-initialization-introdu.patch new file mode 100644 index 0000000..60939b8 --- /dev/null +++ b/kexec-tools-2.0.4-makedumpfile-memset-in-cyclic-bitmap-initialization-introdu.patch @@ -0,0 +1,112 @@ +From 4404368a0860e3b6c845eb41782e97a9bf7593b8 Mon Sep 17 00:00:00 2001 +From: WANG Chao <chaowang(a)redhat.com> +Date: Wed, 18 Dec 2013 22:34:43 +0900 +Subject: [PATCH] [PATCH] memset() in cyclic bitmap initialization introduce + segment fault. + +We are using memset() to improve performance when creating 1st and 2nd +bitmap. After doing round up the pfn_start and round down pfn_end, it's +possible that pfn_start_roundup is greater than pfn_end_round. A segment +fault could happen in that case because memset is taking roughly the +value of (pfn_end_round << 3 - pfn_start_roundup << 3 ), which is +negative, as its third argument. + +So we can skip the memset if start is greater than end. It's safe +because we will set bit for the round up part and also round down part. + +Actually this happens on my EFI virtual machine: + +cat /proc/iomem: +00000000-00000fff : reserved +00001000-0009ffff : System RAM +000a0000-000bffff : PCI Bus 0000:00 +000f0000-000fffff : System ROM +00100000-3d162017 : System RAM + 01000000-015cab9b : Kernel code + 015cab9c-019beb3f : Kernel data + 01b4f000-01da9fff : Kernel bss + 30000000-37ffffff : Crash kernel +3d162018-3d171e57 : System RAM +3d171e58-3d172017 : System RAM +3d172018-3d17ae57 : System RAM +3d17ae58-3dc10fff : System RAM +3dc11000-3dc18fff : reserved +3dc19000-3dc41fff : System RAM +3dc42000-3ddcefff : reserved +3ddcf000-3f7fefff : System RAM +3f7ff000-3f856fff : reserved +[..] + +gdb ./makedumpfile core +(gdb) bt full +[..] + #1 0x000000000042775d in create_1st_bitmap_cyclic () at makedumpfile.c:4543 + i = 0x5 + pfn = 0x3d190 + phys_start = 0x3d18ee58 + phys_end = 0x3d18f018 + pfn_start = 0x3d18e + pfn_end = 0x3d18f + pfn_start_roundup = 0x3d190 + pfn_end_round = 0x3d188 + pfn_start_byte = 0x7a32 + pfn_end_byte = 0x7a31 +[..] +(gdb) list makedumpfile.c:4543 +4538 return FALSE; +4539 +4540 pfn_start_byte = (pfn_start_roundup - info->cyclic_start_pfn) >> +3; +4541 pfn_end_byte = (pfn_end_round - info->cyclic_start_pfn) >> 3; +4542 +4543 memset(info->partial_bitmap2 + pfn_start_byte, +4544 0xff, +4545 pfn_end_byte - pfn_start_byte); +4546 +4547 for (pfn = pfn_end_round; pfn < pfn_end; ++pfn) + +Signed-off-by: WANG Chao <chaowang(a)redhat.com> +--- + makedumpfile.c | 18 +++++++++++------- + 1 file changed, 11 insertions(+), 7 deletions(-) + +diff --git a/makedumpfile.c b/makedumpfile.c +index 23251a1..ef08d91 100644 +--- a/makedumpfile.c ++++ b/makedumpfile.c +@@ -4435,11 +4435,13 @@ create_1st_bitmap_cyclic() + pfn_start_byte = (pfn_start_roundup - info->cyclic_start_pfn) >> 3; + pfn_end_byte = (pfn_end_round - info->cyclic_start_pfn) >> 3; + +- memset(info->partial_bitmap1 + pfn_start_byte, +- 0xff, +- pfn_end_byte - pfn_start_byte); ++ if (pfn_start_byte < pfn_end_byte) { ++ memset(info->partial_bitmap1 + pfn_start_byte, ++ 0xff, ++ pfn_end_byte - pfn_start_byte); + +- pfn_bitmap1 += (pfn_end_byte - pfn_start_byte) * BITPERBYTE; ++ pfn_bitmap1 += (pfn_end_byte - pfn_start_byte) * BITPERBYTE; ++ } + + for (pfn = pfn_end_round; pfn < pfn_end; pfn++) { + if (set_bit_on_1st_bitmap(pfn)) +@@ -4540,9 +4542,11 @@ initialize_2nd_bitmap_cyclic(void) + pfn_start_byte = (pfn_start_roundup - info->cyclic_start_pfn) >> 3; + pfn_end_byte = (pfn_end_round - info->cyclic_start_pfn) >> 3; + +- memset(info->partial_bitmap2 + pfn_start_byte, +- 0xff, +- pfn_end_byte - pfn_start_byte); ++ if (pfn_start_byte < pfn_end_byte) { ++ memset(info->partial_bitmap2 + pfn_start_byte, ++ 0xff, ++ pfn_end_byte - pfn_start_byte); ++ } + + for (pfn = pfn_end_round; pfn < pfn_end; ++pfn) + if (!set_bit_on_2nd_bitmap_for_kernel(pfn)) +-- +1.8.5.3 + -- 1.8.5.3

2 1

[PATCH] ssh dump: create random-seed manually
by WANG Chao 28 Jan '14

28 Jan '14

In ssh dump, we use random-seed to feed /dev/urandom. Since the systemd random-seed file could change location, it's better we create our own random-seed. The discussion is listed below for future reference: https://lists.fedoraproject.org/pipermail/kexec/2014-January/000340.html Signed-off-by: WANG Chao <chaowang(a)redhat.com> --- dracut-module-setup.sh | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-) diff --git a/dracut-module-setup.sh b/dracut-module-setup.sh index c013430..a4351b9 100755 --- a/dracut-module-setup.sh +++ b/dracut-module-setup.sh @@ -392,13 +392,26 @@ kdump_check_iscsi_targets () { } } +# Install a random seed used to feed /dev/urandom +# By the time kdump service starts, /dev/uramdom is already fed by systemd +kdump_install_random_seed() { + local poolsize=`cat /proc/sys/kernel/random/poolsize` + + if [ ! -d ${initdir}/var/lib/ ]; then + mkdir -p ${initdir}/var/lib/ + fi + + dd if=/dev/urandom of=${initdir}/var/lib/random-seed \ + bs=$poolsize count=1 2> /dev/null +} + install() { kdump_install_conf >"$initdir/lib/dracut/no-emergency-shell" if is_ssh_dump_target; then - dracut_install /var/lib/random-seed || exit $? + kdump_install_random_seed fi dracut_install -o /etc/adjtime /etc/localtime inst "$moddir/monitor_dd_progress" "/kdumpscripts/monitor_dd_progress" -- 1.8.4.2

2 1

[PATCH] ssh dump: install random-seed from a new location
by WANG Chao 20 Jan '14

20 Jan '14

In ssh dump, we use random-seed to feed /dev/urandom. In later release of systemd[1], random-seed is moved from /var/lib/random-seed to /var/lib/systemd/random-seed. We need to adapt the change and also keep backward compatibility with older systemd. [1]: http://cgit.freedesktop.org/systemd/systemd/commit/?id=ef5bfcf668e6029faa78… Signed-off-by: WANG Chao <chaowang(a)redhat.com> --- dracut-kdump.sh | 7 ++++++- dracut-module-setup.sh | 3 ++- 2 files changed, 8 insertions(+), 2 deletions(-) diff --git a/dracut-kdump.sh b/dracut-kdump.sh index 4d8616f..a7672e1 100755 --- a/dracut-kdump.sh +++ b/dracut-kdump.sh @@ -146,7 +146,12 @@ dump_ssh() echo "kdump: saving to $_host:$_dir" - cat /var/lib/random-seed > /dev/urandom + if [ -f /var/lib/random-seed ]; then + cat /var/lib/random-seed > /dev/urandom + elif [ -f /var/lib/systemd/random-seed ]; then + cat /var/lib/systemd/random-seed > /dev/urandom + fi + ssh -q $_opt $_host mkdir -p $_dir || return 1 save_vmcore_dmesg_ssh ${DMESG_COLLECTOR} ${_dir} "${_opt}" $_host diff --git a/dracut-module-setup.sh b/dracut-module-setup.sh index c013430..96009f8 100755 --- a/dracut-module-setup.sh +++ b/dracut-module-setup.sh @@ -398,7 +398,8 @@ install() { >"$initdir/lib/dracut/no-emergency-shell" if is_ssh_dump_target; then - dracut_install /var/lib/random-seed || exit $? + dracut_install -o /var/lib/random-seed || exit $? + dracut_install -o /var/lib/systemd/random-seed || exit $? fi dracut_install -o /etc/adjtime /etc/localtime inst "$moddir/monitor_dd_progress" "/kdumpscripts/monitor_dd_progress" -- 1.8.4.2

3 12

[PATCH] makedumpfile: Improve progress information for huge memory system.
by Baoquan He 17 Jan '14

17 Jan '14

Backport from upstream. commit 20ecc0827e7837c52f3903638a59959f8bf17f9e Author: HATAYAMA Daisuke <d.hatayama(a)jp.fujitsu.com> Date: Tue Nov 5 00:29:35 2013 +0900 [PATCH v2] Improve progress information for huge memory system. On system with huge memory, percentage in progress information is updated at very slow interval, because 1 percent on 1 TiB memory is about 10 GiB, which looks like as if system has freezed. Then, confused users might get tempted to push a reset button to recover the system. We want to avoid such situation as much as possible. Signed-off-by: HATAYAMA Daisuke <d.hatayama(a)jp.fujitsu.com> Signed-off-by: Baoquan He <bhe(a)redhat.com> --- ...prove-progress-information-for-huge-memor.patch | 200 +++++++++++++++++++++ 1 file changed, 200 insertions(+) create mode 100644 kexec-tools-2.0.4-makedumpfile-Improve-progress-information-for-huge-memor.patch diff --git a/kexec-tools-2.0.4-makedumpfile-Improve-progress-information-for-huge-memor.patch b/kexec-tools-2.0.4-makedumpfile-Improve-progress-information-for-huge-memor.patch new file mode 100644 index 0000000..9b15185 --- /dev/null +++ b/kexec-tools-2.0.4-makedumpfile-Improve-progress-information-for-huge-memor.patch @@ -0,0 +1,200 @@ +From 20ecc0827e7837c52f3903638a59959f8bf17f9e Mon Sep 17 00:00:00 2001 +From: HATAYAMA Daisuke <d.hatayama(a)jp.fujitsu.com> +Date: Tue, 5 Nov 2013 00:29:35 +0900 +Subject: [PATCH] [PATCH v2] Improve progress information for huge memory + system. + +On system with huge memory, percentage in progress information is +updated at very slow interval, because 1 percent on 1 TiB memory is +about 10 GiB, which looks like as if system has freezed. Then, +confused users might get tempted to push a reset button to recover the +system. We want to avoid such situation as much as possible. + +To address the issue, this patch: + +- increases the number of calling print_progress() from once in + (written pages / 100)-pages to once in (written pages / + 10000)-pages, + +- extends precision in progress information by adding 1 digit to its + fractional part, and + +- adds spinner that rotates in the order of /, |, \ and - in next to + the progress indicator in percentage, + +which help users to get aware that system is still active and crash +dump process is still in progress now. + +The spinner code is borrowed from diskdump code. + +The ouput is changed from: + +Copying data : [ 0 %] / +Copying data : [ 8 %] | +Copying data : [ 11 %] \ +Copying data : [ 14 %] - +Copying data : [ 16 %] / +... +Copying data : [ 99 %] / +Copying data : [100 %] | + +to: + +Copying data : [ 0.1 %] / +Copying data : [ 8.9 %] | +Copying data : [ 11.6 %] \ +Copying data : [ 14.3 %] - +Copying data : [ 16.4 %] / +... +Copying data : [ 99.2 %] / +Copying data : [100.0 %] | + +This patch doesn't adopt purely time-based approach that records the +time when print_progress() is called at each invocation and print the +recorded time if it is strictly larger than the previous time value. + +The problem is that calling time() system call amounts to +considertably long time in total on huge memory system. For example, +here is a simple bench that measures total execution time of time() +system call for (1TiB / 4KiB)-times: + +$ ./bench +total: 18.360503 +total: 34.910297 + +the result of which reveals that it amounts to about 20 seconds with +vDSO optimization and about 35 seconds without. + +BTW, on our 12 TiB memory system, we collect about 300 GiB crash dump +in about 40 minutes with dump level 31. On 12TiB, the benchmark result +corresponds to about 4 minutes and 7 minutes respectively, both of which +affects a whole performance. + +==bench.c +static inline double getdtime(void) +{ + struct timeval tv; + gettimeofday(&tv, NULL); + return (double)tv.tv_sec + (double)tv.tv_usec * 1.0e-6; +} + +int main(int argc, char **argv) +{ + unsigned long i; + time_t t; + double t1, t2, total; + const int NR_time = 201; + const unsigned long nr_repeat = (1UL << 40) / 4096; + + total = 0; + for (i = 0; i < nr_repeat; ++i) { + t1 = getdtime(); + time(&t); + t2 = getdtime(); + total += t2 - t1; + } + printf("total: %lf\n", total); + + total = 0; + for (i = 0; i < nr_repeat; ++i) { + t1 = getdtime(); + syscall(NR_time, &t); + t2 = getdtime(); + total += t2 - t1; + } + printf("total: %lf\n", total); + + return 0; +} +== + +Signed-off-by: HATAYAMA Daisuke <d.hatayama(a)jp.fujitsu.com> +--- + makedumpfile.c | 8 ++++---- + print_info.c | 15 +++++++++------ + 2 files changed, 13 insertions(+), 10 deletions(-) + +diff --git a/makedumpfile-1.5.4/makedumpfile.c b/makedumpfile-1.5.4/makedumpfile.c +index dafe83b..3746cf6 100644 +--- a/makedumpfile-1.5.4/makedumpfile.c ++++ b/makedumpfile-1.5.4/makedumpfile.c +@@ -5573,7 +5573,7 @@ write_elf_pages(struct cache_data *cd_header, struct cache_data *cd_page) + initialize_2nd_bitmap(&bitmap2); + + num_dumpable = get_num_dumpable(); +- per = num_dumpable / 100; ++ per = num_dumpable / 10000; + + off_seg_load = info->offset_load_dumpfile; + cd_page->offset = info->offset_load_dumpfile; +@@ -5858,7 +5858,7 @@ write_elf_pages_cyclic(struct cache_data *cd_header, struct cache_data *cd_page) + return FALSE; + + num_dumpable = info->num_dumpable; +- per = num_dumpable / 100; ++ per = num_dumpable / 10000; + + off_seg_load = info->offset_load_dumpfile; + cd_page->offset = info->offset_load_dumpfile; +@@ -6116,7 +6116,7 @@ write_kdump_pages(struct cache_data *cd_header, struct cache_data *cd_page) + } + + num_dumpable = get_num_dumpable(); +- per = num_dumpable / 100; ++ per = num_dumpable / 10000; + + /* + * Calculate the offset of the page data. +@@ -6317,7 +6317,7 @@ write_kdump_pages_cyclic(struct cache_data *cd_header, struct cache_data *cd_pag + goto out; + } + +- per = info->num_dumpable / 100; ++ per = info->num_dumpable / 10000; + + /* + * Set a fileoffset of Physical Address 0x0. +diff --git a/makedumpfile-1.5.4/print_info.c b/makedumpfile-1.5.4/print_info.c +index 3527970..d7a8600 100644 +--- a/makedumpfile-1.5.4/print_info.c ++++ b/makedumpfile-1.5.4/print_info.c +@@ -283,27 +283,30 @@ print_usage(void) + void + print_progress(const char *msg, unsigned long current, unsigned long end) + { +- int progress; ++ float progress; + time_t tm; + static time_t last_time = 0; ++ static unsigned int lapse = 0; ++ static const char *spinner = "/|\\-"; + + if (current < end) { + tm = time(NULL); + if (tm - last_time < 1) + return; + last_time = tm; +- progress = current * 100 / end; ++ progress = (float)current * 100 / end; + } else + progress = 100; + + if (flag_ignore_r_char) { +- PROGRESS_MSG("%-" PROGRESS_MAXLEN "s: [%3d %%]\n", +- msg, progress); ++ PROGRESS_MSG("%-" PROGRESS_MAXLEN "s: [%5.1f %%] %c\n", ++ msg, progress, spinner[lapse % 4]); + } else { + PROGRESS_MSG("\r"); +- PROGRESS_MSG("%-" PROGRESS_MAXLEN "s: [%3d %%] ", +- msg, progress); ++ PROGRESS_MSG("%-" PROGRESS_MAXLEN "s: [%5.1f %%] %c", ++ msg, progress, spinner[lapse % 4]); + } ++ lapse++; + } + + void +-- +1.8.3.1 + -- 1.8.3.1

2 2

[PATCH] ssh: use ssh -n to redirect stdin from /dev/null
by WANG Chao 15 Jan '14

15 Jan '14

When we're parsing kdump.conf, we read it from stdin in a while loop statement. If we don't use ssh -n within the loop, all rest of the kdump.conf options, which are in stdin, will be eaten by ssh. Signed-off-by: WANG Chao <chaowang(a)redhat.com> --- mkdumprd | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/mkdumprd b/mkdumprd index 6de1755..43a41cb 100644 --- a/mkdumprd +++ b/mkdumprd @@ -153,7 +153,7 @@ mkdir_save_path_ssh() { local _opt _dir _opt="-i $SSH_KEY_LOCATION -o BatchMode=yes -o StrictHostKeyChecking=yes" - ssh -q $_opt $1 mkdir -p $SAVE_PATH 2>&1 > /dev/null + ssh -qn $_opt $1 mkdir -p $SAVE_PATH 2>&1 > /dev/null _ret=$? if [ $_ret -ne 0 ]; then perror_exit "mkdir failed on $DUMP_TARGET:$SAVE_PATH" @@ -165,7 +165,7 @@ mkdir_save_path_ssh() if [ $_ret -ne 0 ]; then perror_exit "Could not create temporary directory on $DUMP_TARGET:$SAVE_PATH. Make sure user has write permission on destination" fi - ssh -q $_opt $1 rmdir $_dir + ssh -qn $_opt $1 rmdir $_dir return 0 } -- 1.8.4.2

3 5

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

kexec January 2014