[PATCH] insert wdt kernel modules when watchdog is active
by Baoquan He
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
9 years, 9 months
[PATCH 0/6] kdump: Modify kdump init script to support firmware-assisted dump
by Hari Bathini
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
9 years, 10 months
[PATCH] Add acpi_no_memhotplug to kdump kernel
by Baoquan He
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
9 years, 10 months
[PATCH v3 0/6] Add fence kdump support
by WANG Chao
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
9 years, 10 months
[PATCH v2 0/6] Add fence kdump support
by WANG Chao
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
9 years, 10 months
[PATCH rawhide] makedumpfile: memset() in cyclic bitmap initialization introduce segment fault.
by WANG Chao
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
9 years, 10 months
[PATCH] ssh dump: create random-seed manually
by WANG Chao
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
9 years, 10 months
[PATCH] ssh dump: install random-seed from a new location
by WANG Chao
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=ef5bfcf668e6029faa...
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
9 years, 10 months
[PATCH] makedumpfile: Improve progress information for huge memory system.
by Baoquan He
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
9 years, 10 months
[PATCH] ssh: use ssh -n to redirect stdin from /dev/null
by WANG Chao
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
9 years, 10 months