From owner-freebsd-usb@FreeBSD.ORG Sun May 29 09:28:33 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 BB94616A41C for ; Sun, 29 May 2005 09:28:33 +0000 (GMT) (envelope-from sigsegv@radiotube.org) Received: from enterprise.localnet.radiotube.org (enterprise.radiotube.org [81.0.166.237]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4DE7A43D1D for ; Sun, 29 May 2005 09:28:31 +0000 (GMT) (envelope-from sigsegv@radiotube.org) Received: from [10.53.4.10] ([10.53.4.10]) (authenticated bits=0) by enterprise.localnet.radiotube.org (8.13.1/8.13.1) with ESMTP id j4T9Rvpn049226 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 29 May 2005 11:28:20 +0200 (CEST) (envelope-from sigsegv@radiotube.org) Message-ID: <42998B18.8020806@radiotube.org> Date: Sun, 29 May 2005 11:27:52 +0200 From: Jan-Espen Pettersen User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050329) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ian Dowse References: <200505281627.aa05625@nowhere.iedowse.com> In-Reply-To: <200505281627.aa05625@nowhere.iedowse.com> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-usb@freebsd.org Subject: Re: ulpt_tick after close X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sigsegv@radiotube.org List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 May 2005 09:28:33 -0000 -----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: mem 0xef003000-0xef003fff irq 12 at device 2.0 on pci0 usb0: on ohci0 ohci1: mem 0xef004000-0xef004fff irq 5 at device 2.1 on pci0 usb1: 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-----