From owner-freebsd-usb@FreeBSD.ORG Sun Aug 9 18:16: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 3B546106564A for ; Sun, 9 Aug 2009 18:16:30 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-fx0-f224.google.com (mail-fx0-f224.google.com [209.85.220.224]) by mx1.freebsd.org (Postfix) with ESMTP id BAC108FC15 for ; Sun, 9 Aug 2009 18:16:29 +0000 (UTC) Received: by fxm24 with SMTP id 24so2793191fxm.36 for ; Sun, 09 Aug 2009 11:16:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=rX85xNVsv070ILqb6qoxX2XrItkmRrMmgXMvkTZOUDY=; b=UGIXHaYWTceJiY/Ba0DICYUdY0Uw8Ylku9+zXJ55BqupIb8A9r8Iuz9oGTyvpqMxDE 7+ZFTmVzlkzqbBEh2WEDWw4dk9U8RMiO5Zo1rdC8UkYaRUPPx+K4+XaWf9bNHQyjXf/V 6Qkgx1tXUkI03ftgrR/OqKetFiw+Qd6hilJTg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=E2v1Ca879AbDmaN7nI9ZcOCsFxspguSO2Hh3AdCfHuAouOpmwALpBlU9np2feiMPCA FOvIsd7lOqBEdWdh2GxgvdEL2PV2wYxTykKBoD5HMURa483vkZl0Kcxl0x7409wf5m6d ToOYK5B3+rjhYYY+LzUHC7Jzdsazi4ujpEbIk= MIME-Version: 1.0 Sender: asmrookie@gmail.com Received: by 10.223.119.207 with SMTP id a15mr703632far.11.1249841788736; Sun, 09 Aug 2009 11:16:28 -0700 (PDT) In-Reply-To: <20090809.115606.1943337744.imp@bsdimp.com> References: <20090809.105507.-646227496.imp@bsdimp.com> <3bbf2fe10908091025t7f8d00dbw5b0589728cf400ad@mail.gmail.com> <3bbf2fe10908091038m3efb3612l2923d8b3238e111f@mail.gmail.com> <20090809.115606.1943337744.imp@bsdimp.com> Date: Sun, 9 Aug 2009 20:16:28 +0200 X-Google-Sender-Auth: 09a54e7556d0ca23 Message-ID: <3bbf2fe10908091116x3ac66e63t4b34174f492a4bce@mail.gmail.com> From: Attilio Rao To: "M. Warner Losh" Content-Type: text/plain; charset=UTF-8 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 18:16:30 -0000 2009/8/9 M. Warner Losh : > 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? Ok, so it should not. Can you compile a KTR kernel with KTR_BUF and monitor the buffer cache activity? Please just stop it collecting points early otherwise we could loose many interesting informations due to KTR buffer entries replacements politique. Attilio -- Peace can only be achieved by understanding - A. Einstein