attilio at freebsd.org
Sun Aug 9 17:38:52 UTC 2009
2009/8/9 Attilio Rao <attilio at freebsd.org>:
> 2009/8/9 M. Warner Losh <imp at bsdimp.com>:
>> In message: <200908091840.55000.hselasky at c2i.net>
>> Hans Petter Selasky <hselasky at 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" ?
> 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.
Peace can only be achieved by understanding - A. Einstein
More information about the freebsd-usb