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

Bruce Evans bde at zeta.org.au
Mon Apr 4 05:20:08 PDT 2005


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

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


More information about the freebsd-bugs mailing list