Re: lock contention problem?
It might be a hardware resource starvation problem. It is possible to nice umass by simply adding a line like: .interval = 2,/* 2 milliseconds */ Thanks, but it didn't help. Also tried setting it to 1, 4, and 20. http://svn.freebsd.org/changeset/base/217350 Is this supposed to work for 8.0? Is there more to it than a couple line change in a .h file? /usr/src/sys/dev/usb/controller/usb_controller.c: In function 'usb_attach_sub': /usr/src/sys/dev/usb/controller/usb_controller.c:434: warning: implicit declaration of function 'PI_SWI' /usr/src/sys/dev/usb/controller/usb_controller.c:434: warning: nested extern declaration of 'PI_SWI' I'm feeding fwcontrol -u 1 -S /dev/stdin from a pipe. The write() to the pipe took over a second. Perhaps connected to the lock contention of over a second? The EAGAIN comes from the writev() roughly 20 lines from the end of /usr/src/usr.sbin/fwcontrol/fwdv.c. CPU is 98% idle. Data rate is only 3.4 MiB/second. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
lock contention problem?
I suspect that I have a problem with lock/mutex contention. Reading from a USB disk appears to lock out the firewire driver for too long, causing data transfer (writing to firewire bus) to fail with EAGAIN. Once it fails it does not recover. kernel: fwohci1: IT DMA underrun (0x40308011) (stat OHCI_CNTL_CYCMATCH_S) last message repeated 63 times This is from the end of the fwohci_itxbuf_enable() function in dev/firewire/fwohci.c I added LOCK_PROFILING to the kernel and gathered some data. The data is quite verbose, so I sorted by max and am including the first 40 lines. This is a true real-time task, so I am concerned with the worst case rather than the average. First, data from approx 20 seconds without a problem: debug.lock.prof.enable: 0 debug.lock.prof.reset: 0 debug.lock.prof.stats: max wait_max total wait_total countavg wait_avg cnt_hold cnt_lock name 16990 0 2216486 01837 1206 0 0 0 /usr/src/sys/kern/vfs_vnops.c:533 (lockmgr:ufs) 5852 0 11669 0 18648 0 0 0 /usr/src/sys/kern/vfs_subr.c:1693 (lockmgr:syncer) 1659 05522 0 34162 0 0 0 /usr/src/sys/kern/vfs_mount.c:2231 (sleep mutex:struct mount mtx) 1540 0 30353 0 15283 1 0 0 0 /usr/src/sys/kern/sys_pipe.c:574 (sleep mutex:pipe mutex) 1415 0 1885651 0 53865 35 0 0 0 /usr/src/sys/vm/vm_map.c:3526 (sx:user map) 1385 0 252414 0 53865 4 0 0 0 /usr/src/sys/vm/vm_fault.c:937 (sleep mutex:vm object) 1361 0 84475 0 53865 1 0 0 0 /usr/src/sys/vm/vm_fault.c:938 (sleep mutex:vm page queue mutex) 1044 02079 0 2 1039 0 0 0 /usr/src/sys/kern/vfs_mount.c:2194 (sleep mutex:struct mount mtx) 934 0 65031 0 146445 0 0 0 /usr/src/sys/vm/vm_pager.c:311 (lockmgr:bufwait) 864 0 194008 0 53865 3 0 0 0 /usr/src/sys/amd64/amd64/pmap.c:2958 (sleep mutex:pmap) 864 0 192948 0 53865 3 0 0 0 /usr/src/sys/amd64/amd64/pmap.c:2957 (sleep mutex:vm page queue mutex) 862 0 24690 0 30823 0 0 0 /usr/src/sys/kern/kern_mutex.c:147 (sleep mutex:nfe0) 857 0 84478 0 53863 1 0 0 0 /usr/src/sys/amd64/amd64/trap.c:740 (sleep mutex:process lock) 697 0 154340 03292 46 0 0 0 /usr/src/sys/kern/vfs_bio.c:2559 (lockmgr:bufwait) 557 0 896107 0 13438 66 0 0 0 /usr/src/sys/kern/vfs_bio.c:1835 (lockmgr:bufwait) 519 01615 0 11146 0 0 0 /usr/src/sys/ufs/ffs/ffs_vfsops.c:1321 (sleep mutex:struct mount mtx) 481 0 24417 0 13438 1 0 0 0 /usr/src/sys/kern/vfs_subr.c:1595 (sleep mutex:bufobj interlock) 367 0 65371 09178 7 0 0 0 /usr/src/sys/kern/sys_pipe.c:643 (sleep mutex:pipe mutex) 351 02324 0 52 44 0 0 0 /usr/src/sys/kern/vfs_subr.c:2083 (lockmgr:ufs) 333 0 325772 0 53865 6 0 0 0 /usr/src/sys/vm/vm_fault.c:297 (sleep mutex:vm object) 329 0 171709 0 108608 1 0 0 0 /usr/src/sys/amd64/amd64/pmap.c:3989 (sleep mutex:pmap) 329 02090 0 534 3 0 0 0 /usr/src/sys/kern/vfs_subr.c:337 (sleep mutex:struct mount mtx) 327 0 99170 0 58917 1 0 0 0 /usr/src/sys/vm/vm_page.c:1052 (sleep mutex:vm page queue free mutex) 305 0 514 0 4128 0 0 0 /usr/src/sys/vm/vm_object.c:541 (sleep mutex:vm object) 304 0 304 0 1304 0 0 0 /usr/src/sys/vm/uma_core.c:1565 (sleep mutex:UMA lock) 297 0 359 0 13 27 0 0 0 /usr/src/sys/kern/vfs_bio.c:3611 (sleep mutex:vm object) 296 0 23341 0 983 23 0 0 0 /usr/src/sys/kern/tty_ttydisc.c:467 (sleep mutex:ttymtx) 291 0 448 0 6 74 0 0 0 /usr/src/sys/vm/vm_object.c:1719 (sleep mutex:vm object) 284 0 12090 0 997 12 0 0 0 /usr/src/sys/kern/sys_generic.c:1446 (sleep mutex:select mtxpool) 281 08752 0 955 9 0 0 0
Re: lock contention problem?
On Thursday 13 January 2011 21:28:15 dieter...@engineer.com wrote: I suspect that I have a problem with lock/mutex contention. Reading from a USB disk appears to lock out the firewire driver for too long, causing data transfer (writing to firewire bus) to fail with EAGAIN. Once it fails it does not recover. kernel: fwohci1: IT DMA underrun (0x40308011) (stat OHCI_CNTL_CYCMATCH_S) last message repeated 63 times This is from the end of the fwohci_itxbuf_enable() function in dev/firewire/fwohci.c I added LOCK_PROFILING to the kernel and gathered some data. The data is quite verbose, so I sorted by max and am including the first 40 lines. This is a true real-time task, so I am concerned with the worst case rather than the average. Hi, It might be a hardware resource starvation problem. It is possible to nice umass by simply adding a line like: .interval = 2,/* 2 milliseconds */ Inside the following structure in /sys/dev/usb/storage/umass.c : umass_bbb_config[] In states: UMASS_T_BBB_DATA_WRITE UMASS_T_BBB_DATA_READ Another idea: http://svn.freebsd.org/changeset/base/217350 --HPS ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
