Date: Mon, 4 Apr 2005 12:20:07 GMT From: Bruce Evans <bde@zeta.org.au> To: freebsd-bugs@FreeBSD.org Subject: Re: kern/79420: panic using uplcom or uftdi serial adaptor and modem (USB) Message-ID: <200504041220.j34CK7E8027089@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: Bruce Evans <bde@zeta.org.au>
To: Mike Tancsa <mike@sentex.net>
Cc: freebsd-gnats-submit@FreeBSD.ORG, iedowse@FreeBSD.ORG
Subject: Re: kern/79420: panic using uplcom or uftdi serial adaptor and modem
(USB)
Date: Mon, 4 Apr 2005 22:19:47 +1000 (EST)
On Sun, 3 Apr 2005, Mike Tancsa wrote:
> Ian Dowse provided the patch below which seems to stop the panics. At
> least 24hrs of testing has not resulted in a panic yet.
>
> --------------------------------------------
>
> In this case I wonder if the transfer needs to be aborted at all,
> since it is just restarted immediately afterwards. Mike, maybe you
> could try the following patch? Sorry, I haven't tested this, so I
> may be missing something obvious.
> Index: dev/usb/ucom.c
> ===================================================================
> RCS file: /dump/FreeBSD-CVS/src/sys/dev/usb/ucom.c,v
> retrieving revision 1.51.2.2
> diff -u -r1.51.2.2 ucom.c
> --- dev/usb/ucom.c 30 Jan 2005 01:00:10 -0000 1.51.2.2
> +++ dev/usb/ucom.c 2 Apr 2005 13:10:27 -0000
> @@ -929,11 +929,13 @@
>
> DPRINTF(("ucomstop: %d\n", flag));
>
> +#if 0
> if (flag & FREAD) {
> DPRINTF(("ucomstop: read\n"));
> ucomstopread(sc);
> ucomstartread(sc);
> }
> +#endif
>
> if (flag & FWRITE) {
> DPRINTF(("ucomstop: write\n"));
>
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.
PR 65769 is about a nearby bug in ucomstop(). The ucomstartread() in
the above was missing, so flushing input often caused input to hang.
This seems to have been fixed by adding the ucomstartcall() in rev.1.56,
but the PR has not been closed. I wrote a detailed analysis which
pointed out the bogusness of just removing the FREAD support as above
and wondered about other calls to ucomstopread(): there is a call in
ucomparam(); it may be necessary to stop input while changing the
parameters, but if stopping input has the side effect of flushing
input as it should do for the above to work, then it is bad to stop
input in ucomparam(), since TIOCSETA is supposed to _not_ flush input
(only TIOCSETAF should flush input).
The bug here seems to be that ucomstopread(sc) doesn't work when it is
called in usb interrupt context while handling usb input, but it ucomstop()
needs to work in this context since such calls are normal -- e.g., they
occur whenever you type the interrupt character (if there is an interrupt
character, and noflsh is not set). The sio driver avoids potential
problems in this area almost accidentally by doing the character handling
in a software interrupt handler. ucom also uses a software interrupt
handler; however, it is soft only by name, since USB_USE_SOFTINTR is
not configured in FreeBSD despite FreeBSD probably needing it more than
NetBSD which has it configured.
Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200504041220.j34CK7E8027089>