Date: Sun, 9 Aug 2009 19:38:50 +0200 From: Attilio Rao <attilio@freebsd.org> To: "M. Warner Losh" <imp@bsdimp.com> Cc: freebsd-usb@freebsd.org Subject: Re: Performance issues Message-ID: <3bbf2fe10908091038m3efb3612l2923d8b3238e111f@mail.gmail.com> In-Reply-To: <3bbf2fe10908091025t7f8d00dbw5b0589728cf400ad@mail.gmail.com> References: <20090809.102341.2106235641.imp@bsdimp.com> <200908091840.55000.hselasky@c2i.net> <20090809.105507.-646227496.imp@bsdimp.com> <3bbf2fe10908091025t7f8d00dbw5b0589728cf400ad@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
2009/8/9 Attilio Rao <attilio@freebsd.org>: > 2009/8/9 M. Warner Losh <imp@bsdimp.com>: >> In message: <200908091840.55000.hselasky@c2i.net> >> Hans Petter Selasky <hselasky@c2i.net> 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 ? 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. Attilio -- Peace can only be achieved by understanding - A. Einstein
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3bbf2fe10908091038m3efb3612l2923d8b3238e111f>