Diskdump - yet another crash dump function

obj-$(CONFIG_BLK_DEV_SR) += sr_mod.o
obj-$(CONFIG_CHR_DEV_SG) += sg.o

+obj-$(CONFIG_SCSI_DUMP) += scsi_dump.o

+#include "hosts.h"

+static int quiesce_ok = 0;

+static void init_scsi_command(Scsi_Device *sdev, Scsi_Cmnd *scmd, void *buf, int len, unsigned char direction, int set_lun)

drivers/scsi/sd.c +4 -0

@@ -192,6 +192,21 @@
 	up(&sd_ref_sem);
 }
 
+#if defined(CONFIG_DISKDUMP) || defined(CONFIG_DISKDUMP_MODULE)
+Scsi_Device *sd_find_scsi_device(dev_t dev)
+{
+	struct gendisk *disk;

Quoted 4 lines

obj-$(CONFIG_BLK_DEV_SR) += sr_mod.o
obj-$(CONFIG_CHR_DEV_SG) += sg.o

+obj-$(CONFIG_SCSI_DUMP) += scsi_dump.o

please use tabs instead of space here.

drivers/scsi/scsi.c line 697

Quoted 8 lines

drivers/scsi/scsi.c +4 -0

@@ -691,6 +691,10 @@
 {
 	unsigned long flags;
 
+#if defined(CONFIG_SCSI_DUMP) || defined(CONFIG_SCSI_DUMP_MODULE)
+	if (crashdump_mode())
+		return;
+#endif

Please make sure crashdump_mode() is always defined so you don't need the ifdef mess.

drivers/scsi/scsi_dump.c line 26

Quoted 1 line

drivers/scsi/scsi_dump.c +1 -0

+#include <linux/config.h>

not needed.

drivers/scsi/scsi_dump.c line 35

Quoted 1 line

drivers/scsi/scsi_dump.c +1 -0

+#include "scsi.h"

please don't use this in new code, use the include/scsi/*.h includes instead.

Review line 700

Quoted 1 line

(quoted diff) +1 -0

+#include "scsi_priv.h"

this is a private header for scsi_mod.ko as the name might suggest ;) But given the rather strange exports I'd suggest to always build scsi_dump.c into scsi_mod.ko anyway.

Quoted 1 line

+#include "hosts.h"

Please use <scsi/scsi_host.h>

drivers/scsi/scsi_dump.c line 46

Quoted 9 lines

drivers/scsi/scsi_dump.c +9 -0

+#include "scsi_dump.h"
+#include <scsi/scsi_ioctl.h>
+
+#include <linux/genhd.h>
+#include <linux/utsname.h>
+#include <linux/crc32.h>
+#include <linux/diskdump.h>
+#include <linux/diskdumplib.h>
+#include <linux/delay.h>

please rework the include order, <linux/*.h> first, then <asm/*.h>, then <scsi/*.h>, then private headers.

Quoted 11 lines

drivers/scsi/scsi_dump.c +9 -0

+#define DEBUG 0
+#if DEBUG
+# define Dbg(x, ...) printk(KERN_INFO "scsi_dump:" x "\n", ## __VA_ARGS__)
+#else
+# define Dbg(x...)
+#endif
+
+#define Err(x, ...)	printk(KERN_ERR "scsi_dump: " x "\n", ## __VA_ARGS__);
+#define Warn(x, ...)	printk(KERN_WARNING "scsi_dump: " x "\n", ## 

__VA_ARGS__)
+#define Info(x, ...) printk(x "\n", ## __VA_ARGS__)

please use the pr_* macros from kernel.h

Quoted 1 line

+static int quiesce_ok = 0;

on need to initialize to 0

drivers/scsi/scsi_dump.c line 70

Quoted 5 lines

drivers/scsi/scsi_dump.c +5 -0

+static Scsi_Cmnd scsi_dump_cmnd;
+static struct request scsi_dump_req;
+static uint32_t module_crc;
+
+static void rw_intr(Scsi_Cmnd * scmd)

Please never use the Scsi_Foo types but the struct scsi_foo versions (goes hand in hand with using <scsi/*.h>

Quoted 2 lines

+static void init_scsi_command(Scsi_Device *sdev, Scsi_Cmnd *scmd, void * buf, int len, unsigned char direction, int set_lun)

plese make sure lines aren't longer than 80 characters.

drivers/scsi/scsi_dump.c

Quoted 5 lines

drivers/scsi/scsi_dump.c +5 -0

+	if (!spin_is_locked(host->host_lock)) {
+		sanity = 0;
+	} else {
+		Warn("host_lock is held: host %d channel %d id %d lun %d",
+				host->host_no, sdev->channel, sdev->id, sdev->

drivers/scsi/scsi_dump.c line 385

Quoted 5 lines

drivers/scsi/scsi_dump.c +5 -0

+		if (host->host_lock == &host->default_lock)
+			sanity = 1;
+		else
+			return -EIO;
+	}

This look bogus to me. Why handle the case of the default and per-driver lock differently?

drivers/scsi/scsi_dump.c line 522

Quoted 9 lines

drivers/scsi/scsi_dump.c +9 -0

+static int scsi_dump_add_device(struct disk_dump_device *dump_device)
+{
+	Scsi_Device *sdev;
+
+	sdev = dump_device->device;
+	if (!sdev->host->hostt->dump_ops)
+		return -ENOTSUPP;
+
+	scsi_device_get(sdev);  /* retval ignored ? */

Please fix this ;-)

drivers/scsi/scsi_dump.h line 2

Quoted 10 lines

diff -Nur linux-2.6.6.org/drivers/scsi/scsi_dump.h linux-2.6.6/drivers/ scsi/scsi_dump.h
--- linux-2.6.6.org/drivers/scsi/scsi_dump.h 1970-01-01 09:00:00.
000000000 +0900
+++ linux-2.6.6/drivers/scsi/scsi_dump.h 2004-05-27 09:31:07.000000000 +

0900

drivers/scsi/scsi_dump.h +2 -0

@@ -0,0 +1,38 @@
+#ifndef _SCSI_DUMP_H
+#define _SCSI_DUMP_H

This file should go into include/scsi/.

drivers/scsi/scsi_dump.h line 33

Quoted 6 lines

drivers/scsi/scsi_dump.h +6 -0

+struct scsi_dump_ops {
+	int (*sanity_check)(Scsi_Device *);
+	int (*quiesce)(Scsi_Device *);
+	int (*shutdown)(Scsi_Device *);
+	void (*poll)(Scsi_Device *);
+};

But I'm not sure we need it at all. These should just go into the scsi_host_template, imho.

drivers/scsi/scsi_error.c line 408

Quoted 6 lines

drivers/scsi/scsi_error.c +4 -0

 static void scsi_eh_done(struct scsi_cmnd *scmd)
 {
+#if defined(CONFIG_SCSI_DUMP) || defined(CONFIG_SCSI_DUMP_MODULE)
+	if (crashdump_mode())
+		return;
+#endif

Same comments as above, please avoid ifdefs.

Quoted 3 lines

+#include "scsi_priv.h"

drivers/scsi/scsi_syms.c line 112

Quoted 7 lines

/*

drivers/scsi/scsi_syms.c +2 -0

@@ -107,3 +108,5 @@
  */
 EXPORT_SYMBOL(scsi_add_timer);
 EXPORT_SYMBOL(scsi_delete_timer);
+
+EXPORT_SYMBOL(scsi_decide_disposition);

prototype in scsi_priv.h == not exported

Quoted 1 line

--- linux-2.6.6.org/drivers/scsi/sd.c 2004-05-20 08:58:48.000000000 +

Quoted 9 lines

+++ linux-2.6.6/drivers/scsi/sd.c 2004-05-27 09:24:46.000000000 +0900

drivers/scsi/sd.c +4 -0

@@ -192,6 +192,21 @@
 	up(&sd_ref_sem);
 }
 
+#if defined(CONFIG_DISKDUMP) || defined(CONFIG_DISKDUMP_MODULE)
+Scsi_Device *sd_find_scsi_device(dev_t dev)
+{
+	struct gendisk *disk;

drivers/scsi/sd.c line 208

Quoted 10 lines

drivers/scsi/sd.c +10 -0

+	int part;
+	disk = get_gendisk(dev, &part);
+	if(disk && disk->private_data)
+		return scsi_disk(disk)->device;
+	else
+		return NULL;
+}
+
+EXPORT_SYMBOL(sd_find_scsi_device);
+#endif

Not the kind of interface we want exported. IMHO you shouldn't find device by dev_t but add a dumpdevice sysfs attribute to the scsi_device where you can echo 1 to to make it a possible dump device.

Quoted 8 lines

drivers/scsi/aic7xxx/aic7xxx_osm.h +8 -0

+/******************************** Disk dump ***********************************/
+#if defined(CONFIG_DISKDUMP) || defined(CONFIG_DISKDUMP_MODULE)
+#undef  add_timer
+#define add_timer       diskdump_add_timer
+#undef  del_timer_sync
+#define del_timer_sync  diskdump_del_timer
+#undef  del_timer
+#define del_timer       diskdump_del_timer

drivers/scsi/aic7xxx/aic7xxx_osm.h line 272

Quoted 5 lines

drivers/scsi/aic7xxx/aic7xxx_osm.h +5 -0

+#undef  mod_timer
+#define mod_timer       diskdump_mod_timer
+
+#define tasklet_schedule        diskdump_tasklet_schedule
+#endif

Yikes. No way in hell we'll place code like this in drivers. This needs to be handled in common code.

Quoted 9 lines · Christoph Hellwig

Quoted 9 lines

+/******************************** Disk dump ************************** *********/

(quoted diff) +7 -0

+#if defined(CONFIG_DISKDUMP) || defined(CONFIG_DISKDUMP_MODULE)
+#undef  add_timer
+#define add_timer       diskdump_add_timer
+#undef  del_timer_sync
+#define del_timer_sync  diskdump_del_timer
+#undef  del_timer
+#define del_timer       diskdump_del_timer

Quoted 8 lines

Review

Quoted 5 lines

(quoted diff) +5 -0

+#undef  mod_timer
+#define mod_timer       diskdump_mod_timer
+
+#define tasklet_schedule        diskdump_tasklet_schedule
+#endif

Yikes. No way in hell we'll place code like this in drivers. This needs to be handled in common code.

yeah, this is arguably the biggest (and i think only) conceptual item that needs to be solved before this can be integrated.

The goal of these defines is to provide a separate (and polling based) timer mechanism that is completely separate from the normal kernel's state.

it would also be easier to enable diskdump in a driver if this was handled in add_timer()/del_timer()/mod_timer()/tasklet_schedule().

Instead of redefinition, I add hooks into the timer/tasklet routines.

ex.

int mod_timer(struct timer_list *timer, unsigned long expires) {

kernel/timer.c +3 -0

 	BUG_ON(!timer->function);
 
+	if (crashdump_mode()) {
+		return diskdump_mod_timer(timer, expires);
+	}
 
 	 check_timer(timer);

Please see the following patches for details.
How do you think?

diff -Nur linux-2.6.6.org/include/linux/interrupt.h linux-2.6.6/include/linux/interrupt.h

include/linux/interrupt.h +1 -0

@@ -7,6 +7,7 @@
 #include <linux/linkage.h>
 #include <linux/bitops.h>
 #include <linux/preempt.h>
+#include <linux/diskdumplib.h>
 #include <asm/atomic.h>
 #include <asm/hardirq.h>
 #include <asm/ptrace.h>

@@ -172,6 +173,11 @@
 

Quoted 6 lines

diff -Nur linux-2.6.6.org/include/linux/diskdumplib.h linux-2.6.6/include /linux/diskdumplib.h
--- linux-2.6.6.org/include/linux/diskdumplib.h 1970-01-01 09:00:00.
000000000 +0900
+++ linux-2.6.6/include/linux/diskdumplib.h 2004-06-17 18:28:01.000000000
+0900

Should probably just go to linux/dump.h or dump_priv.h

Quoted 17 lines

diff -Nur linux-2.6.6.org/include/linux/interrupt.h linux-2.6.6/include/ linux/interrupt.h
--- linux-2.6.6.org/include/linux/interrupt.h 2004-06-04 21:22:09.
000000000 +0900
+++ linux-2.6.6/include/linux/interrupt.h 2004-06-17 18:28:01.000000000 +

0900

include/linux/interrupt.h +1 -0

@@ -7,6 +7,7 @@
 #include <linux/linkage.h>
 #include <linux/bitops.h>
 #include <linux/preempt.h>
+#include <linux/diskdumplib.h>
 #include <asm/atomic.h>
 #include <asm/hardirq.h>
 #include <asm/ptrace.h>

@@ -172,6 +173,11 @@
 

include/linux/interrupt.h line 183

Quoted 10 lines

include/linux/interrupt.h +5 -0

 static inline void tasklet_schedule(struct tasklet_struct *t)
 {
+	if (crashdump_mode()) {
+		diskdump_tasklet_schedule(t);
+		return;
+	}
+
 	if (!test_and_set_bit(TASKLET_STATE_SCHED, &t->state))
 		__tasklet_schedule(t);
 }

Please sprinclde unlikely's all over here. Also the above could be shortened to

static inline void tasklet_schedule(struct tasklet_struct *t)

{
	if (unlikely(crashdump_mode()))
		diskdump_tasklet_schedule(t);
	else if (!test_and_set_bit(TASKLET_STATE_SCHED, &t->state))
		__tasklet_schedule(t);
}

kernel/diskdumplib.c line 95

Quoted 5 lines

kernel/diskdumplib.c +5 -0

+int diskdump_schedule_work(struct work_struct *work)
+{
+	list_add_tail(&work->entry, &diskdump_workq);
+	return 1;
+}

Should probably just inlined, I guess the function call is bigger than all of list_add_tail.

kernel/diskdumplib.c line 108

Quoted 5 lines

kernel/diskdumplib.c +5 -0

+void diskdump_add_timer(struct timer_list *timer)
+{
+	timer->base = (void *)1;
+	list_add(&timer->entry, &diskdump_timers);
+}

dito.

kernel/diskdumplib.c line 156

Quoted 3 lines

kernel/diskdumplib.c +3 -0

+	/* run timers */
+	list_for_each_safe(t, n, &diskdump_timers) {
+		timer = list_entry(t, struct timer_list, entry);

list_for_each_entry_safe here please.

kernel/timer.c line 260

Quoted 7 lines

kernel/timer.c +3 -0

@@ -255,6 +255,10 @@
 {
 	BUG_ON(!timer->function);
 
+	if (crashdump_mode()) {
+		return diskdump_mod_timer(timer, expires);
+	}

please remove the superflous braces here.

Btw, now that we got you in the loop, any chance to see a forward-port of netdump to 2.6? I think diskdump and netdump could share a lot of infrastructure, and given we already have the net polling hooks adding netdump shouldn't be that much work anymore.

Quoted 4 lines

Btw, now that we got you in the loop, any chance to see a forward-port of netdump to 2.6? I think diskdump and netdump could share a lot of infrastructure, and given we already have the net polling hooks adding netdump shouldn't be that much work anymore.

==> Regarding Re: [3/4] [PATCH]Diskdump - yet another crash dump function; Ingo Molnar <[email protected]> adds:

Quoted 4 lines · mingo> * Christoph Hellwig <[email protected]> wrote:

Quoted 4 lines

Btw, now that we got you in the loop, any chance to see a forward-port of netdump to 2.6? I think diskdump and netdump could share a lot of infrastructure, and given we already have the net polling hooks adding netdump shouldn't be that much work anymore.

mingo> i think a forward port of netdump might already exist - Jeff, Dave?

Yes, I ported the code forward to 2.6. The netpoll infrastructure needed a little tweaking to accommodate netdump, but nothing major. Namely, we need to reset some locks, and I added an element to the netpoll data structure for the dump function. I also updated the zap_completion_queue function to touch the nmi watchdog.

mingo> i agree that netdump and diskdump should be merged. (Red Hat is mingo> involved in the diskdump project too so this is an ultimate goal mingo> even though the patches are divergent.) Basically diskdumping is mingo> another IO transport - the format, userspace tools and much of the mingo> non-IO kernel mechanism is shared. Diskdumping is more complex on mingo> the driver level and it also needs to be more careful because it mingo> writes to media so it verifies various assumptions by reading mingo> on-disk sectors before writing to the area.

I'm not quite sure what infrastructure would be shared between the two. Page selection, perhaps? Anything else?

but there's another possible method (suggested by Alan Cox) that requires no changes to the timer API hotpaths: 'clear' all timer lists upon a crash [once all CPUs have stopped and irqs are disabled] and just let the drivers use the normal timer APIs. Drive timer execution via a polling method.

this basically approximates your polling based implementation but uses the existing kernel timer data structures and timer mechanism so should be robust and compatible. It doesnt rely on any previous state (because all currently pending timers are discarded) so it's as crash-safe as possible.

what do you think?

It sounds good because change of timer/tasklet code is not needed. But, I wonder whether this method is safe. For example, if kernel crashes because of problem of timer, clearing lists may be dangerous before dumping. Is it possible to clear all timer lists safely?

Quoted 4 lines · Takao Indoh

It sounds good because change of timer/tasklet code is not needed. But, I wonder whether this method is safe. For example, if kernel crashes because of problem of timer, clearing lists may be dangerous before dumping. Is it possible to clear all timer lists safely?

yes it can be done safely - just INIT_LIST_HEAD() all the timer list heads - like init_timers_cpu() does.

Quoted 2 lines

yes it can be done safely - just INIT_LIST_HEAD() all the timer list heads - like init_timers_cpu() does.

obviously this only involves the dumping CPU - no other CPU will run any kernel code. On SMP you should also clear the timer spinlock of the dumping CPU's timer base, if the crash happened within the timer code.

Quoted 7 lines · Ingo Molnar

Quoted 4 lines · Takao Indoh

It sounds good because change of timer/tasklet code is not needed. But, I wonder whether this method is safe. For example, if kernel crashes because of problem of timer, clearing lists may be dangerous before dumping. Is it possible to clear all timer lists safely?

Quoted 2 lines

yes it can be done safely - just INIT_LIST_HEAD() all the timer list heads - like init_timers_cpu() does.

obviously this only involves the dumping CPU - no other CPU will run any kernel code. On SMP you should also clear the timer spinlock of the dumping CPU's timer base, if the crash happened within the timer code.

Ingo

Quoted 11 lines · Ingo Molnar

Quoted 8 lines · Ingo Molnar

Quoted 4 lines · Takao Indoh

It sounds good because change of timer/tasklet code is not needed. But, I wonder whether this method is safe. For example, if kernel crashes because of problem of timer, clearing lists may be dangerous before dumping. Is it possible to clear all timer lists safely?

Quoted 8 lines

Quoted 2 lines

yes it can be done safely - just INIT_LIST_HEAD() all the timer list heads - like init_timers_cpu() does.

obviously this only involves the dumping CPU - no other CPU will run any kernel code. On SMP you should also clear the timer spinlock of the dumping CPU's timer base, if the crash happened within the timer code.

Ingo

How about this?

void clear_timers(void)

{
	int j;
	tvec_base_t *base;
       
	base = &per_cpu(tvec_bases, smp_processor_id());
	spin_lock_init(&base->lock);
	for (j = 0; j < TVN_SIZE; j++) {
		INIT_LIST_HEAD(base->tv5.vec + j);
		INIT_LIST_HEAD(base->tv4.vec + j);

		INIT_LIST_HEAD(base->tv3.vec + j);
		INIT_LIST_HEAD(base->tv2.vec + j);
	}
	for (j = 0; j < TVR_SIZE; j++)
		INIT_LIST_HEAD(base->tv1.vec + j);

	base->timer_jiffies = jiffies;
}

I think you should save original values to somewhere else, so you can refer these values from vmcore if you want.

but there's another possible method (suggested by Alan Cox) that requires no changes to the timer API hotpaths: 'clear' all timer lists upon a crash [once all CPUs have stopped and irqs are disabled] and just let the drivers use the normal timer APIs. Drive timer execution via a polling method.

this basically approximates your polling based implementation but uses the existing kernel timer data structures and timer mechanism so should be robust and compatible. It doesnt rely on any previous state (because all currently pending timers are discarded) so it's as crash-safe as possible.

Quoted 11 lines · Ingo Molnar

but there's another possible method (suggested by Alan Cox) that requires no changes to the timer API hotpaths: 'clear' all timer lists upon a crash [once all CPUs have stopped and irqs are disabled] and just let the drivers use the normal timer APIs. Drive timer execution via a polling method.

this basically approximates your polling based implementation but uses the existing kernel timer data structures and timer mechanism so should be robust and compatible. It doesnt rely on any previous state (because all currently pending timers are discarded) so it's as crash-safe as possible.

This is a test patch for clearing timer/tasklet and executing it during dumping.
This patch does not work yet. I tried dumping using this patch, but aic7xxx is unstable...

Your new dump_run_timers() calls __run_timers() directly. I think that's the reason of unstability. __run_timers() calls spin_unlock_irq() and enables IRQ, but diskdump expects everything runs with IRQ disabled.

indeed!

luckily we can solve this in the upstream kernel without too much fuss, see the patch below. All callers of __run_timers() run with irqs enabled.

(NOTE: we unconditionally disable interrupts after having run the timer fn - this solves the problem of a timer fn keeping irqs disabled.)

does this patch stabilize diskdump?

Quoted 1 line

does this patch stabilize diskdump?

No. There is one thing I need correct. I need replace proc interface with sysfs, as Christoph and Arjan commented.
After fix this, I'll release stable version 1.0.

but there's another possible method (suggested by Alan Cox) that requires no changes to the timer API hotpaths: 'clear' all timer lists upon a crash [once all CPUs have stopped and irqs are disabled] and just let the drivers use the normal timer APIs. Drive timer execution via a polling method.

this basically approximates your polling based implementation but uses the existing kernel timer data structures and timer mechanism so should be robust and compatible. It doesnt rely on any previous state (because all currently pending timers are discarded) so it's as crash-safe as possible.

Quoted 11 lines · Ingo Molnar

but there's another possible method (suggested by Alan Cox) that requires no changes to the timer API hotpaths: 'clear' all timer lists upon a crash [once all CPUs have stopped and irqs are disabled] and just let the drivers use the normal timer APIs. Drive timer execution via a polling method.

this basically approximates your polling based implementation but uses the existing kernel timer data structures and timer mechanism so should be robust and compatible. It doesnt rely on any previous state (because all currently pending timers are discarded) so it's as crash-safe as possible.

Don't forget live crash dumping. The system is running and is behaving strangely so you want to take a dump for investigation, but you do not want to kill the system afterwards. Live crash dumping is very useful for problem diagnosis.
It is a little more complex than dumping after an oops because you must not destroy any kernel data, including timer lists.

Quoted 5 lines

this basically approximates your polling based implementation but uses the existing kernel timer data structures and timer mechanism so should be robust and compatible. It doesnt rely on any previous state (because all currently pending timers are discarded) so it's as crash-safe as possible.

Don't forget live crash dumping. The system is running and is behaving strangely so you want to take a dump for investigation, but you do not want to kill the system afterwards. Live crash dumping is very useful for problem diagnosis.

It is a little more complex than dumping after an oops because you must not destroy any kernel data, including timer lists.

Don't forget live crash dumping. [...]

Quoted 9 lines

+/******************************** Disk dump **************************** *******/

drivers/scsi/aic7xxx/aic7xxx_osm.h +7 -0

+#if defined(CONFIG_DISKDUMP) || defined(CONFIG_DISKDUMP_MODULE)
+#undef  add_timer
+#define add_timer       diskdump_add_timer
+#undef  del_timer_sync
+#define del_timer_sync  diskdump_del_timer
+#undef  del_timer
+#define del_timer       diskdump_del_timer

drivers/scsi/aic7xxx/aic7xxx_osm.h line 272

Quoted 5 lines

drivers/scsi/aic7xxx/aic7xxx_osm.h +5 -0

+#undef  mod_timer
+#define mod_timer       diskdump_mod_timer
+
+#define tasklet_schedule        diskdump_tasklet_schedule
+#endif

Yikes. No way in hell we'll place code like this in drivers. This needs to be handled in common code.

Although I know about LKCD and netdump, I'm developing yet another crash dump, which is a polling-based disk dump as netdump do. Because it disables any interrupts during doing dump, it can avoid lots of problems LKCD has.

Main Feature
- Reliability
Diskdump disables interrupts, stops other cpus and writes to the disk with polling mode. Therefore, unnecessary functions(like interrupt handler) don't disturb dumping.

Quoted 5 lines

Although I know about LKCD and netdump, I'm developing yet another crash dump, which is a polling-based disk dump as netdump do. Because it disables any interrupts during doing dump, it can avoid lots of problems LKCD has.

Quoted 5 lines

Main Feature
- Reliability
Diskdump disables interrupts, stops other cpus and writes to the disk with polling mode. Therefore, unnecessary functions(like interrupt handler) don't disturb dumping.

Hmm... with this, better design of swsusp mifht be feasible.

Quoted 11 lines

Quoted 10 lines

Although I know about LKCD and netdump, I'm developing yet another crash dump, which is a polling-based disk dump as netdump do. Because it disables any interrupts during doing dump, it can avoid lots of problems LKCD has.

Main Feature
- Reliability
Diskdump disables interrupts, stops other cpus and writes to the disk with polling mode. Therefore, unnecessary functions(like interrupt handler) don't disturb dumping.

Quoted 1 line

Hmm... with this, better design of swsusp mifht be feasible.

I don't know mechanism of swsusp well.
Do you mean diskdump is useful when saving system memory to the disk?