Nate Nielsen wrote:
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


You're correct that dumping is meant to be done with interrupts and task
switching disabled.  The first thing that the umass driver is missing is
a working CAM poll handler.  Without this, there is no way for command
completions to be seen when interrupts are disabled.  Beyond that, I
somewhat suspect that the USB stack expects to be able to push command
completion work off to worker threads, at least for some situations, and
that also will not work in the kernel dump environment.  So, there is a
lot of work needed to make this happen.

Scott
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to