ulpt_tick after close

[Ian Dowse]

In message <4296EBFA.1070902 at 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