From owner-freebsd-hackers@FreeBSD.ORG Sat Feb 11 07:13:04 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DBC5016A420 for ; Sat, 11 Feb 2006 07:13:04 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4F03B43D46 for ; Sat, 11 Feb 2006 07:13:04 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id k1B7D23i012847; Sat, 11 Feb 2006 00:13:03 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <43ED8E81.2060907@samsco.org> Date: Sat, 11 Feb 2006 00:13:05 -0700 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20051230 X-Accept-Language: en-us, en MIME-Version: 1.0 To: nielsen@memberwebs.com References: <20060211060841.898EEDCA994@mail.npubs.com> In-Reply-To: <20060211060841.898EEDCA994@mail.npubs.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on pooker.samsco.org Cc: freebsd-hackers@freebsd.org Subject: Re: Panic Kernel Dump to umass device? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Feb 2006 07:13:05 -0000 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