From owner-freebsd-usb@FreeBSD.ORG Sun May 29 18:22:20 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 6F33716A41C for ; Sun, 29 May 2005 18:22:20 +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 76F4843D48 for ; Sun, 29 May 2005 18:22:18 +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 j4TILxp4059581 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 29 May 2005 20:22:03 +0200 (CEST) (envelope-from sigsegv@radiotube.org) Message-ID: <429A088B.1090405@radiotube.org> Date: Sun, 29 May 2005 20:23:07 +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: <200505291310.aa19689@nowhere.iedowse.com> In-Reply-To: <200505291310.aa19689@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 18:22:20 -0000 Ian Dowse wrote: >In message <42998B18.8020806@radiotube.org>, Jan-Espen Pettersen writes: > > >>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. >> >> > >Thanks for the details. By the way, is it lpd or something else >that is actually accessing the ulpt device? Below is a patch you >could try that will hopefully find out a bit more about what is >going on. You could also change the new return statement in >ulpt_read_cb() to a panic, as the stack trace might reveal more >information like you say. > > It is cups from ports. Thank you very much. Jan-Espen Pettersen