kern/79420: panic using uplcom or uftdi serial adaptor and modem (USB)

[Ian Dowse]

The following reply was made to PR kern/79420; it has been noted by GNATS.

From: Ian Dowse <iedowse at maths.tcd.ie>
To: Bruce Evans <bde at zeta.org.au>
Cc: Mike Tancsa <mike at sentex.net>, freebsd-gnats-submit at 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 at 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