Date: Sat, 28 May 2005 16:27:13 +0100 From: Ian Dowse <iedowse@iedowse.com> To: Jan-Espen Pettersen <sigsegv@radiotube.org> Cc: freebsd-usb@freebsd.org, iedowse@freebsd.org Subject: Re: ulpt_tick after close Message-ID: <200505281627.aa05625@nowhere.iedowse.com> In-Reply-To: Your message of "Fri, 27 May 2005 11:44:26 %2B0200." <4296EBFA.1070902@radiotube.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200505281627.aa05625>