From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 22 04:12:27 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 7509B16A496 for ; Wed, 22 Feb 2006 04:12:27 +0000 (GMT) (envelope-from nielsen-list@memberwebs.com) Received: from mail.npubs.com (npubs.com [209.66.100.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3696E43D45 for ; Wed, 22 Feb 2006 04:12:26 +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: Ian Dowse References: <200602111542.aa07502@nowhere.iedowse.com> Content-Type: multipart/mixed; boundary="------------060408040104060004020008" Message-Id: <20060222042200.BC7B3DCAA07@mail.npubs.com> X-Virus-Scanned: ClamAV using ClamSMTP Date: Wed, 22 Feb 2006 04:22:01 +0000 (GMT) Cc: freebsd-hackers@freebsd.org, Scott Long Subject: Re: 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: Wed, 22 Feb 2006 04:12:27 -0000 This is a multi-part message in MIME format. --------------060408040104060004020008 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Ian Dowse wrote: > In message <43ED8E81.2060907@samsco.org>, Scott Long writes: > >>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. > > > The USB stack supports polled operations, so it's actually not to > hard to make this work. Below is a patch I had in one of my local > trees that adds a CAM poll handler to the umass driver. I've just > tested this and it does seem to make kernel dumping work, but I > guess it might not be as reliable as dumping to other devices. As noted earlier the umass polling patch you posted works for dumping to a umass device via a uhci controller. After a little more fiddling I've managed to get it working on an ohci controller. Attached is a patch. This patch includes your patch above. Cheers, Nate --------------060408040104060004020008 Content-Type: text/x-patch; name="umass-ohci-dump.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="umass-ohci-dump.patch" Index: sys/dev/usb/umass.c =================================================================== RCS file: /home/ncvs/src/sys/dev/usb/umass.c,v retrieving revision 1.122.2.6 diff -U3 -r1.122.2.6 umass.c --- sys/dev/usb/umass.c 29 Jan 2006 00:45:11 -0000 1.122.2.6 +++ sys/dev/usb/umass.c 22 Feb 2006 03:04:02 -0000 @@ -2643,21 +2643,17 @@ } } -/* umass_cam_poll - * all requests are handled through umass_cam_action, requests - * are never pending. So, nothing to do here. - */ Static void umass_cam_poll(struct cam_sim *sim) { -#ifdef USB_DEBUG struct umass_softc *sc = (struct umass_softc *) sim->softc; DPRINTF(UDMASS_SCSI, ("%s: CAM poll\n", USBDEVNAME(sc->sc_dev))); -#endif - /* nop */ + usbd_set_polling(sc->sc_udev, 1); + usbd_dopoll(sc->iface); + usbd_set_polling(sc->sc_udev, 0); } Index: sys/dev/usb/ohci.c =================================================================== RCS file: /home/ncvs/src/sys/dev/usb/ohci.c,v retrieving revision 1.154.2.2 diff -U3 -r1.154.2.2 ohci.c --- sys/dev/usb/ohci.c 29 Jan 2006 01:26:46 -0000 1.154.2.2 +++ sys/dev/usb/ohci.c 22 Feb 2006 03:04:05 -0000 @@ -3049,6 +3049,9 @@ splx(s); + if (sc->sc_bus.use_polling) + ohci_waitintr(sc, xfer); + return (USBD_IN_PROGRESS); } --------------060408040104060004020008--