kern/79420: panic using uplcom or uftdi serial adaptor and
modem (USB)
Ian Dowse
iedowse at maths.tcd.ie
Mon Apr 4 13:10:09 PDT 2005
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
More information about the freebsd-bugs
mailing list