Panic Kernel Dump to umass device?

[Nate Nielsen]

I'm developing for small embedded systems, and I'm looking into the
possibility of dumping a kernel core dump to a USB memory stick (umass
driver). It currently doesn't work (see below), but I'm interested in
fixing it.

Yes, I know it'll be slow. It's probably also a non-tested (and
non-reliable) code path for a kernel dump. But leaving those issues aside...

First I wanted to ask if anyone else has tried this. Is it an insane
idea, impossible? I'm not very familiar with the CAM/SCSI/USB
sub-systems so perhaps someone more knowledgeable than I can set me
straight.

Currently when doing a dump to a USB device, I get the following. This
with 6.0-RELEASE. Dump device is /dev/da0s1.


> Fatal trap 12: page fault while in kernel mode
> fault virtual address   = 0x0
> fault code              = supervisor write, page not present
> instruction pointer     = 0x20:0xc0cea412
> stack pointer           = 0x28:0xc6cf5c1c
> frame pointer           = 0x28:0xc6cf5c24
> code segment            = base 0x0, limit 0xfffff, type 0x1b
>                         = DPL 0, pres 1, def32 1, gran 1
> processor eflags        = interrupt enabled, resume, IOPL = 0
> current process         = 473 (kldload)
> trap number             = 12
> panic: page fault
> Uptime: 3m48s
> Dumping 95 MB (2 chunks)
> Aborting dump due to I/O error.
> status == 0xb, scsi status == 0x0
> 
> ** DUMP FAILED (ERROR 5) **
> Automatic reboot in 5 seconds - press a key on the console to abort


It waits for about a minute after 'Dumping 95 MB (2 chunks)'. The light
on the USB stick goes and remains stuck in the on state. The status: 0xb
seems to be CAM_CMD_TIMEOUT. ERROR 5 is EIO.

As far as I know, kernel dumps are always dune without interrupts and
the driver runs with polling. It's likely that the umass driver and/or
USB subsystem doesn't like this.


Cheers,
Nate