From owner-freebsd-bugs@FreeBSD.ORG Mon Apr 4 20:10:09 2005 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 284D716A4CE for ; Mon, 4 Apr 2005 20:10:09 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id D98E143D53 for ; Mon, 4 Apr 2005 20:10:08 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j34KA8ba022821 for ; Mon, 4 Apr 2005 20:10:08 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j34KA8cn022820; Mon, 4 Apr 2005 20:10:08 GMT (envelope-from gnats) Date: Mon, 4 Apr 2005 20:10:08 GMT Message-Id: <200504042010.j34KA8cn022820@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org From: Ian Dowse Subject: Re: kern/79420: panic using uplcom or uftdi serial adaptor and modem (USB) X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Ian Dowse List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2005 20:10:09 -0000 The following reply was made to PR kern/79420; it has been noted by GNATS. From: Ian Dowse To: Bruce Evans Cc: Mike Tancsa , freebsd-gnats-submit@FreeBSD.ORG Subject: Re: kern/79420: panic using uplcom or uftdi serial adaptor and modem (USB) Date: Mon, 04 Apr 2005 21:08:14 +0100 In message <20050404211652.F34170@delplex.bde.org>, Bruce Evans writes: >The (flag & FREAD) case is supposed to flush input as much as possible >(from any driver buffers and from hardware buffers if possible). Starting >and stopping the transfer is an attempt to do this. I don't know if it >works. Hi Bruce, Thanks for pointing out more about the bug history. In theory, I think stopping and immediately restarting a USB read transfer is a no-op due to USB's polled architecture (USB transfers are repeatedly re-attempted until they succeed or time out, and the USB device only sees this polling, not the transfer state). However in practice the abort-start operation will cancel any already-completed transfer that may be waiting on Giant for processing. It will not flush any input that the device happens to have waiting to be collected. In this case, removing the stop-start pair is just a temporary but effective workaround, as it avoids the panics at the cost of an increased risk of failing to flush all input. It seems possible to implement an asynchronous abort mechanism for USB pipes, so that may be a better way to handle transfers that need to be aborted from odd contexts. Interestingly, this panic does not seem to occur in -CURRENT, but I haven't investigated what is different there. Ian