From owner-freebsd-usb@FreeBSD.ORG Mon Jan 30 21:57:43 2006 Return-Path: X-Original-To: freebsd-usb@freebsd.org Delivered-To: freebsd-usb@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E15D216A420 for ; Mon, 30 Jan 2006 21:57:43 +0000 (GMT) (envelope-from iedowse@iedowse.com) Received: from nowhere.iedowse.com (nowhere.iedowse.com [82.195.144.75]) by mx1.FreeBSD.org (Postfix) with SMTP id 0FE6043D48 for ; Mon, 30 Jan 2006 21:57:40 +0000 (GMT) (envelope-from iedowse@iedowse.com) Received: from localhost ([127.0.0.1] helo=iedowse.com) by nowhere.iedowse.com via local-iedowse id ; 30 Jan 2006 21:57:36 +0000 (GMT) To: Juergen Lock In-Reply-To: Your message of "Mon, 30 Jan 2006 20:52:58 +0100." <20060130195258.GA7172@saturn.kn-bremen.de> Date: Mon, 30 Jan 2006 21:57:36 +0000 From: Ian Dowse Message-ID: <200601302157.aa30543@nowhere.iedowse.com> Cc: freebsd-usb@freebsd.org Subject: Re: cvs commit: src/sys/dev/usb ehci.c ehci_pci.c ehcivar.h X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2006 21:57:44 -0000 In message <20060130195258.GA7172@saturn.kn-bremen.de>, Juergen Lock writes: > Well ehci_intrlist_timeout belongs to the ehci patch in the Subject >so its pretty new... (I don't know the code enough to know if it >matters, but shouldnt the timer only be scheduled if the interrupt >did appear too early, i.e. the transfer indeed wasnt complete yet? >Not all transfers hung before i applied the patch, so it only >happens `sometimes'...) Calling the driver's interrupt service routine should be safe at any time (assuming sufficient locking, which should be OK), since this can happen with shared interrupts, so if anything it's more likely to be an existing problem that just gets triggered more often by having the ISR called via the new timer. Try applying the patch I posted yesterday and see if that helps. It includes a change to usb_transfer_complete() that might be relevant - the EHCI driver touches the transfer structure in its done() method, and the usb_transfer_complete() change makes it safe to do this when a callback function reuses the transfer structure. The umass driver shouldn't normally reuse its transfer structures during callbacks, but maybe it can during some error recovery condition. Could you also do the following from gdb on the crash dump you have? It might possibly provide further hints as to what went wrong. p *(struct ehci_xfer *)0xc1aaf300 p *(struct ehci_softc *)0xc1a3f800 Ian