From owner-freebsd-usb@FreeBSD.ORG Sun Aug 9 17:56:30 2009 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EEFBF1065670; Sun, 9 Aug 2009 17:56:30 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 934328FC1E; Sun, 9 Aug 2009 17:56:30 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id n79HtD24043635; Sun, 9 Aug 2009 11:55:14 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sun, 09 Aug 2009 11:56:06 -0600 (MDT) Message-Id: <20090809.115606.1943337744.imp@bsdimp.com> To: attilio@freebsd.org From: "M. Warner Losh" In-Reply-To: <3bbf2fe10908091038m3efb3612l2923d8b3238e111f@mail.gmail.com> References: <20090809.105507.-646227496.imp@bsdimp.com> <3bbf2fe10908091025t7f8d00dbw5b0589728cf400ad@mail.gmail.com> <3bbf2fe10908091038m3efb3612l2923d8b3238e111f@mail.gmail.com> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-usb@freebsd.org Subject: Re: Performance issues X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Aug 2009 17:56:31 -0000 In message: <3bbf2fe10908091038m3efb3612l2923d8b3238e111f@mail.gmail.com> Attilio Rao writes: : 2009/8/9 Attilio Rao : : > 2009/8/9 M. Warner Losh : : >> In message: <200908091840.55000.hselasky@c2i.net> : >> Hans Petter Selasky writes: : >> : On Sunday 09 August 2009 18:23:41 M. Warner Losh wrote: : >> : > Any ideas how to track this down? : >> : : >> : Hi, : >> : : >> : USB is only draining from "usbd_transfer_drain()" in : >> : /sys/dev/usb/usb_transfer.c . You could add a print including the backtrace : >> : and see if that function gets called when it freezes. : >> : >> Ummm. No. Adding a traceback print to a function that's called 60 : >> times a second in steady state doesn't seem like a viable option. : >> : >> : Else I would try to compile a fresh kernel from USB P4. There are : >> : some patches there in relation to the recent newbus lock change, : >> : that might help. : >> : >> This kernel predates the newbus lock change. : >> : >> : USB uses uppercase "WDRAIN". Is your printout lowercase "wdrain" ? : >> : >> Yes. : > : > That's used by the buffer cache in order to reduce pressure of : > asynchronous writes. It waits for other writes to complete before to : > go on. Probabilly, I/O requests get stuck for another reasong starving : > the asynchronous requests queue flushing. : : It would be also interesting to understand if the allowed requests are : just lost or still pending and can be effectively flushed out. Can you : please show the content of vm.runningbufspace ? The writes eventually happen, it is just stalled. I'll run the experiment again and see if I can give you that info... : However, keep in mind that as long as the buffer cache is global, if : the bluethoot dongle breaks I/O requests, it can be the offending : part, so USB may not be involved. I'm not sure I understand this statement. I think what is happening is a race between multiple devices. I also see problems when I have both a usb disk and a usb dvd burner attached. I didn't used to see that problem (I made hundreds of DVDs of my son's hockey games). Now, I can't even burn one disc to save my life... Besides, the bluetooth dongle isn't going to be doing any disk block requests, so how can that interfere with the buffer cache? Warner