Date: Mon, 4 Apr 2005 20:10:08 GMT From: Ian Dowse <iedowse@maths.tcd.ie> To: freebsd-bugs@FreeBSD.org Subject: Re: kern/79420: panic using uplcom or uftdi serial adaptor and modem (USB) Message-ID: <200504042010.j34KA8cn022820@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/79420; it has been noted by GNATS. From: Ian Dowse <iedowse@maths.tcd.ie> To: Bruce Evans <bde@zeta.org.au> Cc: Mike Tancsa <mike@sentex.net>, 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200504042010.j34KA8cn022820>