From owner-freebsd-bugs@FreeBSD.ORG Mon Apr 4 12:20:08 2005 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 92A6616A4CE for ; Mon, 4 Apr 2005 12:20:08 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4942043D45 for ; Mon, 4 Apr 2005 12:20:08 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j34CK7m1027090 for ; Mon, 4 Apr 2005 12:20:07 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j34CK7E8027089; Mon, 4 Apr 2005 12:20:07 GMT (envelope-from gnats) Date: Mon, 4 Apr 2005 12:20:07 GMT Message-Id: <200504041220.j34CK7E8027089@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org From: Bruce Evans Subject: Re: kern/79420: panic using uplcom or uftdi serial adaptor and modem (USB) X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Bruce Evans List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2005 12:20:08 -0000 The following reply was made to PR kern/79420; it has been noted by GNATS. From: Bruce Evans To: Mike Tancsa 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