ulpt_tick after close

[Jan-Espen Pettersen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ian Dowse wrote:

|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?
|
No, there are no 'detached' messages.

|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.
|
This is an Abit NF7-M board with Nforce-2 chipset. I am running without 
SMP and APIC, and with ACPI (partially working). By the way, everything 
else seem to be running quite fine:
11:23AM  up 32 days,  4:14, 36 users, load averages: 0.10, 0.09, 0.06

ohci0: <OHCI (generic) USB controller> mem 0xef003000-0xef003fff irq 12 
at device 2.0 on pci0
usb0: <OHCI (generic) USB controller> on ohci0
ohci1: <OHCI (generic) USB controller> mem 0xef004000-0xef004fff irq 5 
at device 2.1 on pci0
usb1: <OHCI (generic) USB controller> on ohci1
ulpt0: Samsung Electronics Co., Ltd. Samsung ML-1710, rev 1.10/1.00, 
addr 4, iclass 7/1
ulpt0: using bi-directional mode

http://www.linuxprinting.org/show_printer.cgi?recnum=Samsung-ML-1710

This happened immediately after sending a normal print job to the 
printer and before the printer was finished printing.

FreeBSD endeavour.localnet.radiotube.org 5.4-STABLE FreeBSD 5.4-STABLE 
#0: Mon Apr 25 07:52:47 CEST 2005     
sigsegv at endeavour.localnet.radiotube.org:/usr/obj/usr/src/FreeBSD-5/sys/ENDEAVOUR  
i386
I have:
rev 1.65.2.1 of ulpt.c
rev 1.86.2.4 of usbdi.c
rev 1.144.2.4 of ohci.c

I think I'll replace that printf with a panic in ulpt_read_cb to get a 
backtrace next time. (And at the same time update my sources) As it 
would reveal what is actually calling ulpt_read_cb after the callout has 
been stopped. The problem is that this is very unlikely to happen during 
a single print job, but it does over time, so it might take me some time 
to get that backtrace.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (FreeBSD)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCmYsYH90qNYni6VoRAjZKAKCI4VTbf2imK2pLNRiCVXRcgbZrqQCguNc0
O+Y+Bv9EHbK9u5RSw20fvmA=
=8Xmy
-----END PGP SIGNATURE-----