Date: Sat, 11 Feb 2006 00:13:05 -0700 From: Scott Long <scottl@samsco.org> To: nielsen@memberwebs.com Cc: freebsd-hackers@freebsd.org Subject: Re: Panic Kernel Dump to umass device? Message-ID: <43ED8E81.2060907@samsco.org> In-Reply-To: <20060211060841.898EEDCA994@mail.npubs.com> References: <20060211060841.898EEDCA994@mail.npubs.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?43ED8E81.2060907>