Date: Sun, 29 May 2005 11:27:52 +0200 From: Jan-Espen Pettersen <sigsegv@radiotube.org> To: Ian Dowse <iedowse@iedowse.com> Cc: freebsd-usb@freebsd.org Subject: Re: ulpt_tick after close Message-ID: <42998B18.8020806@radiotube.org> In-Reply-To: <200505281627.aa05625@nowhere.iedowse.com> References: <200505281627.aa05625@nowhere.iedowse.com>
next in thread | previous in thread | raw e-mail | index | archive | help
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ian Dowse wrote: |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? | 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@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-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?42998B18.8020806>