Date: Tue, 16 Jul 2002 19:14:05 -0400 (EDT) From: John Baldwin <jhb@FreeBSD.org> To: Josef Karthauser <joe@tao.org.uk> Cc: dnelson@allantgroup.com, current@freebsd.org, zipzippy@sonic.net, Don Lewis <dl-freebsd@catspoiler.org> Subject: Re: What to do with witness verbiage (is this new?)? Message-ID: <XFMail.20020716191405.jhb@FreeBSD.org> In-Reply-To: <20020716225346.GA552@genius.tao.org.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
On 16-Jul-2002 Josef Karthauser wrote: > On Thu, Jul 11, 2002 at 12:33:27PM +0100, Josef Karthauser wrote: >> On Thu, Jul 11, 2002 at 04:01:08AM -0700, Don Lewis wrote: > > [stuff about > could sleep with "inp" locked from /usr/src/sys/netinet/tcp_usrreq.c:647 > could sleep with "tcp" locked from /usr/src/sys/netinet/tcp_usrreq.c:630 > cut] > > I saw the recent changes to -current to try and fix this, but I'm still > seeing it. > > Here's a typical stack trace: > > Debugger(c0374e00,c0389851,534,c0374e47,c037d8c8) at Debugger+0x54 > witness_sleep(1,0,c0389851,534,c021bf24) at witness_sleep+0x135 > uma_zalloc_arg(c1564000,0,4,c021bf24,c1564000) at uma_zalloc_arg+0x39 > malloc(50,c03c1060,4,c40e5000,c40e5000) at malloc+0x55 > uhci_allocm(c40e5000,c40edc40,a4,c024a000,c160e72e) at uhci_allocm+0x3d > usbd_transfer(c40edc00,c434b600,c4126174,c42b1000,a4) at > usbd_transfer+0xba > aue_encap(c4126000,c160e700,0,49c,c41260dc) at aue_encap+0xa2 > aue_start(c4126000,0,c0379f81,134,0) at aue_start+0xcc > if_handoff(c41260c8,c160e700,c4126000,0,de0259e4) at if_handoff+0x107 > ether_output_frame(c4126000,c160e700,6,c4336ba8,de0259e4) at > ether_output_frame+0x241 > ether_output(c4126000,c160e700,c4336ba8,c4ace200,0) at > ether_output+0x4a2 > ip_output(c160e700,0,c4336ba4,0,0) at ip_output+0xa75 > tcp_output(c4336c68,c160ed00,c037de40,287,0) at tcp_output+0xc60 > tcp_usr_send(c4ce1320,0,c160ed00,0,0) at tcp_usr_send+0x1be > sosend(c4ce1320,0,de025c7c,c160ed00,0) at sosend+0x4c3 > soo_write(c4d62078,de025c7c,c4d5cc80,0 > > Is anyone anywhere near this code at the moment? This is because USB network drivers are possibly doing bad things. Either that or the network locking is making bogus assumptions about what device driver routines will and will not do. Probably the network stack should not hold locks across a driver's start method. -- John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.20020716191405.jhb>