From owner-freebsd-usb@FreeBSD.ORG Sat May 28 15:27:17 2005 Return-Path: X-Original-To: freebsd-usb@freebsd.org Delivered-To: freebsd-usb@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6588416A41C; Sat, 28 May 2005 15:27:17 +0000 (GMT) (envelope-from iedowse@iedowse.com) Received: from nowhere.iedowse.com (nowhere.iedowse.com [82.195.144.75]) by mx1.FreeBSD.org (Postfix) with SMTP id 844CF43D1D; Sat, 28 May 2005 15:27:16 +0000 (GMT) (envelope-from iedowse@iedowse.com) Received: from localhost ([127.0.0.1] helo=iedowse.com) by nowhere.iedowse.com with SMTP id ; 28 May 2005 16:27:15 +0100 (IST) To: Jan-Espen Pettersen In-Reply-To: Your message of "Fri, 27 May 2005 11:44:26 +0200." <4296EBFA.1070902@radiotube.org> Date: Sat, 28 May 2005 16:27:13 +0100 From: Ian Dowse Message-ID: <200505281627.aa05625@nowhere.iedowse.com> Cc: freebsd-usb@freebsd.org, iedowse@freebsd.org Subject: Re: ulpt_tick after close X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 May 2005 15:27:17 -0000 In message <4296EBFA.1070902@radiotube.org>, Jan-Espen Pettersen writes: >I've for a few weeks suspected that there was more problems with the USB >printer implementation than those that have been resolved through >usb/78208 (http://www.freebsd.org/cgi/query-pr.cgi?pr=78208). I found >that ulpt_read_cb reschedules the ulpt_tick callout, but fails to check >if sc->sc_has_callout is set. ulpt_close destroys the read xfer and >unsets sc->sc_has_callout. Running ulpt_tick with the read xfer >destroyed causes a page fault. Therefore I suggest checking >sc->sc_has_callout in ulpt_read_cb before rescheduling the ulpt_tick >callout. Hi, It appears that ulptclose() should already be doing enough to guarantee that neither ulpt_read_cb() nor ulpt_tick() get called after it completes, so if the case you describe is happening then it may suggest a deeper problem. What version of FreeBSD are you using (branch + date)? Were there any "ulpt0: detached" or similar messages just before or after your printf triggered? The ulptclose() function first calls usb_uncallout(), which in -CURRENT and RELENG_5 should guarantee that the ulpt_tick() will not be called after ulptclose() completes. Next the sc_in_pipe is aborted and closed. If there was an outstanding asynchronous request in progress, then its callback (ulpt_read_cb) should be called immediately with a status of USBD_CANCELLED, which will cause it to skip rescheduling the callout. So once sc_in_pipe has been aborted, neither the timeout nor the transfer should be active. What kind of USB printer do you have, and was there any special kind of access that triggered the message? Once I know what version of FreeBSD you're using I'll try to suggest some further things you can do to narrow down the cause of the problem. Ian