From owner-freebsd-hackers@FreeBSD.ORG Sat Feb 11 06:00:19 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 C181E16A420 for ; Sat, 11 Feb 2006 06:00:19 +0000 (GMT) (envelope-from nielsen-list@memberwebs.com) Received: from mail.npubs.com (mail.zoneseven.net [209.66.100.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id 956AD43D48 for ; Sat, 11 Feb 2006 06:00:19 +0000 (GMT) (envelope-from nielsen-list@memberwebs.com) From: Nate Nielsen User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <20060211060841.898EEDCA994@mail.npubs.com> X-Virus-Scanned: ClamAV using ClamSMTP Date: Sat, 11 Feb 2006 06:08:42 +0000 (GMT) Subject: Panic Kernel Dump to umass device? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: nielsen@memberwebs.com 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 06:00:19 -0000 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