From owner-freebsd-net@FreeBSD.ORG Sun Feb 1 00:37:44 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 588DE1065687 for ; Sun, 1 Feb 2009 00:37:44 +0000 (UTC) (envelope-from mmitar@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.185]) by mx1.freebsd.org (Postfix) with ESMTP id E02FB8FC13 for ; Sun, 1 Feb 2009 00:37:43 +0000 (UTC) (envelope-from mmitar@gmail.com) Received: by nf-out-0910.google.com with SMTP id h3so145584nfh.33 for ; Sat, 31 Jan 2009 16:37:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=RB0WS0PKC97yswx9m2pZ5B4PQWwK3nRijhRgUK8+3R0=; b=YMOLS7+cB2MFgpFxjRGsoAmV0FPePIpOaq/5PR4ahZdcD7xouPWpV3wp82iQAJGLnj MjouXdSr3ZUwBitXzQ5fWZcvEun5tSATT7KeHXl/Y9X1JXR1kF0hxOg+WUex4RMapE2Z VtaA7LYX7U0mjcr8pyhVDKJcrdG1C2JNkSRgA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=GqGDWVmzloWITP4EIZ3bkGmi8JFXzYMXp2gBL7AIVxtjC9u/iwXpCGRuB7kNMPZDz2 H1JGrVDjFw7OCm/InRddlII9Q4ei4BDPwbxAIt9jztIRO2sCWD6+qDOjiIiQ5v7j+u/5 aFhXGRLi5Df7yUOSWIAAQmwQ4/TZegSnvpLbo= MIME-Version: 1.0 Received: by 10.210.66.13 with SMTP id o13mr3093506eba.157.1233448247465; Sat, 31 Jan 2009 16:30:47 -0800 (PST) In-Reply-To: References: Date: Sun, 1 Feb 2009 01:30:47 +0100 Message-ID: From: Mitar To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: read() returns ETIMEDOUT X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Feb 2009 00:37:44 -0000 Hi! I have found also: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/108670 http://lists.freebsd.org/mailman/htdig/freebsd-net/2007-February/013095.html I am using FreeBSD 7.0-STABLE. Mitar From owner-freebsd-net@FreeBSD.ORG Sun Feb 1 00:47:01 2009 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 14F621065675; Sun, 1 Feb 2009 00:47:01 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id B4ECA8FC12; Sun, 1 Feb 2009 00:47:00 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id n110kwKT026717; Sat, 31 Jan 2009 19:46:58 -0500 (EST) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.8/8.13.3) with ESMTP id n110kwg5076330 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 31 Jan 2009 19:46:58 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <200902010046.n110kwg5076330@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 31 Jan 2009 19:47:02 -0500 To: Andrew Thompson From: Mike Tancsa In-Reply-To: <20090131213354.GA29777@citylink.fud.org.nz> References: <200901271739.n0RHdGd3047497@lava.sentex.ca> <20090131213354.GA29777@citylink.fud.org.nz> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: freebsd-net@FreeBSD.org Subject: Re: lagg failover mode and vlans X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Feb 2009 00:47:01 -0000 At 04:33 PM 1/31/2009, Andrew Thompson wrote: > > > > and do the same pulling of the cable, it does not work. BUT, if I do an > > arp -nda on a machine that is part of vlan102 which is doing the pinging > > (so an arp-who has gets sent out and a reply answered), it works. The > > other option is if I send a packet out on the vlan's broadcast > address from > > the server > >Can you verify that em2, em3 and all the lagg* interfaces have the same >mac address. > Looks to be from the server side. I dont have them hooked up to the switch right now, but will Monday em2: flags=8843 metric 0 mtu 1500 options=19b ether 00:30:48:90:4c:fe inet 1.1.1.1 netmask 0xffffff00 broadcast 1.1.1.255 media: Ethernet autoselect status: no carrier lagg: laggdev lagg0 em3: flags=8843 metric 0 mtu 1500 options=19b ether 00:30:48:90:4c:fe inet 10.10.1.1 netmask 0xffffff00 broadcast 10.10.1.255 media: Ethernet autoselect status: no carrier lagg: laggdev lagg0 lo0: flags=8049 metric 0 mtu 16384 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff000000 lagg0: flags=8843 metric 0 mtu 1500 options=19b ether 00:30:48:90:4c:fe inet 192.168.44.99 netmask 0xffffff00 broadcast 192.168.44.255 media: Ethernet autoselect status: no carrier laggproto failover laggport: em3 flags=0<> laggport: em2 flags=1 lagg0.100: flags=8843 metric 0 mtu 1500 options=3 ether 00:30:48:90:4c:fe inet 192.168.100.1 netmask 0xffffff00 broadcast 192.168.100.255 media: Ethernet autoselect status: no carrier vlan: 100 parent interface: lagg0 lagg0.102: flags=8843 metric 0 mtu 1500 options=3 ether 00:30:48:90:4c:fe inet 192.168.102.1 netmask 0xffffff00 broadcast 192.168.102.255 media: Ethernet autoselect status: no carrier vlan: 102 parent interface: lagg0 >Andrew From owner-freebsd-net@FreeBSD.ORG Sun Feb 1 00:51:02 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D899510656C8 for ; Sun, 1 Feb 2009 00:51:02 +0000 (UTC) (envelope-from mmitar@gmail.com) Received: from mail-ew0-f21.google.com (mail-ew0-f21.google.com [209.85.219.21]) by mx1.freebsd.org (Postfix) with ESMTP id 6DF208FC1F for ; Sun, 1 Feb 2009 00:51:02 +0000 (UTC) (envelope-from mmitar@gmail.com) Received: by ewy14 with SMTP id 14so1676003ewy.19 for ; Sat, 31 Jan 2009 16:51:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=vLSVRF20PaFjAR+gLWb/LLSl0smCm5sr5LQ6OM85RFU=; b=UaHB6snyDQmDoz1nm/7Nu5Rb+g88TT8d9VOpwH+o1tL2I4G06lYeqCZZvgx8r3cV1J Y/G/8VEKSZVLqHiJzfcljL1uR3Z7YJWjYlD41KqUNd2pFCAlBjYWJmYfzeYQcs2umD5I QQfv9+KKYAa/BtMLONA3zimbet9AJEQzrne0E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=IWgoFBQetkWghk83K5nxxW8+9h/RcLwe6gaWAwOmCl4u7GGoEk14jfYACO5Rt3BKPp /vqz4t0FxDoqPrzuMc5e1VIC5d06jNaETvENAenhV/gbw7H6dSLppipJQ81+jHsCzm3y 4KEMo2UFS8ymLkZV8wn3UDVs+3Z3vMjeqb/JA= MIME-Version: 1.0 Received: by 10.210.44.19 with SMTP id r19mr1110219ebr.188.1233447917509; Sat, 31 Jan 2009 16:25:17 -0800 (PST) Date: Sun, 1 Feb 2009 01:25:17 +0100 Message-ID: From: Mitar To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: read() returns ETIMEDOUT X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Feb 2009 00:51:03 -0000 Hi! Is there any progress on this error reported: http://freebsd.monkey.org/freebsd-net/200805/msg00026.html I have the same or very similar issue. On my server large HTTP uploads are failing because there are only one direction data transmissions (when reading/receiving a request) and kernel drops connections after some time with ETIMEDOUT returning from read() even if transmissions are doing just fine with steady speed, tested at different speeds. Is there any workaround currently known? Mitar From owner-freebsd-net@FreeBSD.ORG Sun Feb 1 01:34:46 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0A71710656F0; Sun, 1 Feb 2009 01:34:46 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id D3A498FC19; Sun, 1 Feb 2009 01:34:45 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n111YjAe018373; Sun, 1 Feb 2009 01:34:45 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n111YjLp018369; Sun, 1 Feb 2009 01:34:45 GMT (envelope-from linimon) Date: Sun, 1 Feb 2009 01:34:45 GMT Message-Id: <200902010134.n111YjLp018369@freefall.freebsd.org> To: dnelson@allantgroup.com, linimon@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/129719: [tcp] [panic] Panic during shutdown, tcp_ctloutput: inp == NULL X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Feb 2009 01:34:46 -0000 Synopsis: [tcp] [panic] Panic during shutdown, tcp_ctloutput: inp == NULL State-Changed-From-To: open->feedback State-Changed-By: linimon State-Changed-When: Sun Feb 1 01:33:56 UTC 2009 State-Changed-Why: Is this easily reproducible? And, if so, do you have a corefile available that can be posted on the web somewhere? http://www.freebsd.org/cgi/query-pr.cgi?pr=129719 From owner-freebsd-net@FreeBSD.ORG Sun Feb 1 02:42:41 2009 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 045C31065735 for ; Sun, 1 Feb 2009 02:42:41 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from email1.allantgroup.com (email1.emsphone.com [199.67.51.115]) by mx1.freebsd.org (Postfix) with ESMTP id B64228FC33 for ; Sun, 1 Feb 2009 02:42:40 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (dan-a.emsphone.com [199.67.51.107]) by email1.allantgroup.com (8.14.0/8.14.0) with ESMTP id n112VLnH067345 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 31 Jan 2009 20:31:21 -0600 (CST) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (smmsp@localhost [127.0.0.1]) by dan.emsphone.com (8.14.3/8.14.3) with ESMTP id n112VLmn054042 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 31 Jan 2009 20:31:21 -0600 (CST) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.14.3/8.14.3/Submit) id n112VJ0r054004; Sat, 31 Jan 2009 20:31:19 -0600 (CST) (envelope-from dan) Date: Sat, 31 Jan 2009 20:31:19 -0600 From: Dan Nelson To: linimon@FreeBSD.org Message-ID: <20090201023118.GG75802@dan.emsphone.com> References: <200902010134.n111YjLp018369@freefall.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200902010134.n111YjLp018369@freefall.freebsd.org> X-OS: FreeBSD 7.1-STABLE User-Agent: Mutt/1.5.18 (2008-05-17) X-Virus-Scanned: ClamAV version 0.94.1, clamav-milter version 0.94.1 on email1.allantgroup.com X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (email1.allantgroup.com [199.67.51.78]); Sat, 31 Jan 2009 20:31:21 -0600 (CST) X-Scanned-By: MIMEDefang 2.45 Cc: freebsd-net@FreeBSD.org Subject: Re: kern/129719: [tcp] [panic] Panic during shutdown, tcp_ctloutput: inp == NULL X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Feb 2009 02:42:41 -0000 In the last episode (Feb 01), linimon@FreeBSD.org said: > Is this easily reproducible? And, if so, do you have a corefile > available that can be posted on the web somewhere? I've only had it happen once, but I still have the corefile if it might help. -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-net@FreeBSD.ORG Sun Feb 1 11:49:57 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AC379106566C for ; Sun, 1 Feb 2009 11:49:57 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 874CD8FC20 for ; Sun, 1 Feb 2009 11:49:57 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 24ED346B37; Sun, 1 Feb 2009 06:49:57 -0500 (EST) Date: Sun, 1 Feb 2009 11:49:57 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: "Per Hurtig (work)" In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: TCP gets special treatment? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Feb 2009 11:49:57 -0000 On Wed, 28 Jan 2009, Per Hurtig (work) wrote: > How differently are TCP packets treated compared to e.g. SCTP packets, while > traversing the FreeBSD network stack (up to and including the IP-layer when > using ipfw)?. I do not assume that the firewall (ipfw) is explicitly > configured to check for established sessions or any TCP specifics. Are there > a lot of TCP-specific optimizations conducted by lower layers anyways > (besides possible checksum offloading)? Hi Per: On the whole, TCP packets are treated like any other packet until they reach the tcp_input() function during the input path, and once they've entered ip_output() in the output path. There are some exceptions that I'm aware of, including: - ipfw(4) has special knowledge of the layout and semantics of TCP packets, including stateful tracking of TCP connections, etc. ipfw(4) is able use (output) or to look up (input) the local socket for the purposes of identifying the credential that was or may be associated with. Many of us consider this highly dubious behavior subject to race conditions and unexpected semantics, but it appears to be popular functionality. Other firewall packets, including pf(4) have this functionality as well. - The IP input protocol dispatch (in_proto.c) doesn't set PR_LASTHDR for TCP (and UDP for that matter) because IPSEC policy is aware of TCP-level properties, meaning that some IPSEC processing (policy checking) isn't performed in the normal IPSEC input path and instead deferred to the TCP input path. See ip_ipsec.c. - Various sorts of checksum offload and segmentation offload require TCP segments to be handled outside of the core TCP routines, including ip_output(), where deferred checksum calculations will be performed if it turns out the output interface doesn't support hardware checksumming, and where TSO segments may be rejected, and in device drivers that perform (for example) TSO and LSO and are therefore aware (in some form) of TCP processing. tcp_lso.c, for example, is entirely called from the device driver in order to perform early reassembly, if the device driver supports it (primarily 10gbps drivers). Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-net@FreeBSD.ORG Sun Feb 1 15:28:44 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1CE41106566B for ; Sun, 1 Feb 2009 15:28:44 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.18.43]) by mx1.freebsd.org (Postfix) with ESMTP id A377F8FC23 for ; Sun, 1 Feb 2009 15:28:43 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from [88.153.0.16] (helo=localhost) by smtprelay05.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1LTe58-0004je-NH; Sun, 01 Feb 2009 16:17:58 +0100 Date: Sun, 1 Feb 2009 16:05:44 +0100 From: Fabian Keil To: Jeff Roberson Message-ID: <20090201160544.4f1961b4@fabiankeil.de> In-Reply-To: <20090131125100.N983@desktop> References: <20090131125100.N983@desktop> X-Mailer: Claws Mail 3.7.0 (GTK+ 2.14.7; i386-portbld-freebsd8.0) X-PGP-KEY-URL: http://www.fabiankeil.de/gpg-keys/freebsd-listen-2008-08-18.asc Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/J88GP4GS78NoV.7Fp.3mKvr"; protocol="application/pgp-signature"; micalg=PGP-SHA1 X-Df-Sender: 775067 Cc: freebsd-net@freebsd.org Subject: Re: mbuf revision, testers/comments wanted. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Feb 2009 15:28:44 -0000 --Sig_/J88GP4GS78NoV.7Fp.3mKvr Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Jeff Roberson wrote: > http://people.freebsd.org/~jeff/mbuf_ref2.diff > I have been experimenting with different revisions to the mbuf api to=20 > improve performance and simplify code. This patch is the first of > several proposed steps towards those goals. The aim of this patch is > two fold; > I would appreciate testing feedback from varied workloads to make sure=20 > there are no bugs before I go forward with this. I have tested only > host oriented networking with a few drivers. It is not anticipated that > there will be any significant incompatibilities introduced with this > round but there is always that possibility. To compile without changing my kernel config I needed: --- .zfs/snapshot/2009-02-01/sys/kern/kern_mbuf.c 2009-02-01 14:13:18= .678107513 +0100 +++ sys/kern/kern_mbuf.c 2009-02-01 14:24:56.006950417 +0100 @@ -222,7 +222,9 @@ /* * Local prototypes. */ +#ifdef INVARIANTS static int mb_ctor_pack(void *mem, int size, void *arg, int how); +#endif static void mb_dtor_pack(void *mem, int size, void *arg); static void mb_reclaim(void *); static int mb_zinit_pack(void *mem, int size, int how); I'm not familiar with how mbufs work on FreeBSD, so a few meta comments are all I got: 1) 508 +struct mbuf * 509 +_m_getjcl(int how, short type, int flags, int size, uma_zone_t zon= e, 510 + int exttype) 511 +{ 512 + struct mbuf *m; 513 + void *mem; 514 + 515 + switch (size) { 516 + case MCLBYTES: 517 + m =3D m_getcl(how, type, flags); 518 + break; 519 + default: [...] 526 + m =3D m_alloc(zone_ext, 0, how, type, flags); [...] 533 + break; 534 + } 535 + 536 + return (m); 537 +} Why do you use a switch statement if there are only two conditions? Is it to be somewhat symmetric to m_gettype()? Otherwise the indentation could be partly flattened with: if (size =3D=3D MCLBYTES) return m_getcl(how, type, flags); [old default: code here] 2) 893 @@ -834,8 +753,9 @@ 894 m_dup(struct mbuf *m, int how) 895 { [...] 904 @@ -852,10 +772,8 @@ 905 /* Get the next new mbuf */ 906 if (remain >=3D MINCLSIZE) { 907 n =3D m_getcl(how, m->m_type, 0); 908 - nsize =3D MCLBYTES; 909 } else { 910 n =3D m_get(how, m->m_type); 911 - nsize =3D MLEN; 912 } The curly brackets are no longer required here. 3) 1595 static __inline struct mbuf * 1596 +m_alloc(uma_zone_t zone, int size, int how, short type, int flags) 1597 +{ [...] 1603 + if (type !=3D MT_NOINIT) { 1604 + if (m_init(m, zone, size, how, type, flags)) { 1605 + uma_zfree(zone, m); 1606 + return (NULL); 1607 + } 1608 + } 1609 + return (m); 1610 +} Why don't you use a single if block here? 4) 1612 +/* 1613 + * Configure a provided mbuf to refer to the provided external sto= rage 1614 + * buffer and setup a reference count for said buffer. 1615 + * 1616 + * Arguments: 1617 + * mb The existing mbuf to which to attach the provided buf= fer. 1618 + * buf The address of the provided external storage buffer. 1619 + * size The size of the provided buffer. 1620 + * freef A pointer to a routine that is responsible for freein= g the 1621 + * provided external storage buffer. 1622 + * args A pointer to an argument structure (of any type) to b= e passed 1623 + * to the provided freef routine (may be NULL). 1624 + * flags Any other flags to be passed to the provided mbuf. 1625 + * type The type that the external storage buffer should be 1626 + * labeled with. 1627 + * 1628 + * Returns: 1629 + * Nothing. 1630 + */ 1631 +static __inline void 1632 +m_extadd(struct mbuf *mb, caddr_t buf, u_int size, 1633 + void (*freef)(void *, void *), void *arg1, void *arg2, int fla= gs, int type) 1634 +{ Is the description for "args" meant to cover both arg1 and arg2? =46rom the comment alone their differences aren't clear to me, but then again, that might just be because my lack of mbuf knowledge. I noticed that this is only relocated code, though. 5) Finally, I tested the patch on an IBM ThinPad R51. The kernel hangs on boot, the last messages are (hand transcribed): iwi0: mem 0xc0214000-0xc0214fff irq 11 at de= vice 2.0 on pci2 iwi0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xc0214000 iwi0: could not allocate rx mbuf iwi0: could not allocate Rx ring bpfdetach: was not attached Booting without if_iwi.ko works and for em0 I get: em0: port 0x8000-0x803f mem 0x= c0220000-0xc023ffff,0xc0200000-0xc020ffff irq 11 at device 1.0 on pci2 em0: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xc0220000 em0: Reserved 0x40 bytes for rid 0x18 type 4 at 0x8000 em0: [FILTER] em0: bpf attached em0: Ethernet address: 00:11:... em0: Could not setup receive structures Without iwi0 I can't test the patch any further on this system at the moment, but I can probably give it a try on another system in the next days. I also wouldn't mind giving another patch a try. Fabian --Sig_/J88GP4GS78NoV.7Fp.3mKvr Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkmFukgACgkQBYqIVf93VJ2xMQCdFjnJHRcbRoWWdFkI/aBZ85Qn xToAoJoNWTgbxw6f+8ySBFOQzN4RFN8i =ZkSl -----END PGP SIGNATURE----- --Sig_/J88GP4GS78NoV.7Fp.3mKvr-- From owner-freebsd-net@FreeBSD.ORG Sun Feb 1 16:05:59 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BD11B106564A for ; Sun, 1 Feb 2009 16:05:59 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay08.ispgateway.de (smtprelay08.ispgateway.de [80.67.29.8]) by mx1.freebsd.org (Postfix) with ESMTP id 7A6DE8FC1E for ; Sun, 1 Feb 2009 16:05:59 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from [88.153.0.16] (helo=localhost) by smtprelay08.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1LTepa-0005kE-4q; Sun, 01 Feb 2009 17:05:58 +0100 Date: Sun, 1 Feb 2009 17:05:50 +0100 From: Fabian Keil To: Jeff Roberson Message-ID: <20090201170550.482bf325@fabiankeil.de> In-Reply-To: <20090201160544.4f1961b4@fabiankeil.de> References: <20090131125100.N983@desktop> <20090201160544.4f1961b4@fabiankeil.de> X-Mailer: Claws Mail 3.7.0 (GTK+ 2.14.7; i386-portbld-freebsd8.0) X-PGP-KEY-URL: http://www.fabiankeil.de/gpg-keys/freebsd-listen-2008-08-18.asc Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/Gx72li3ReUEmSfYl00og=HH"; protocol="application/pgp-signature"; micalg=PGP-SHA1 X-Df-Sender: 775067 Cc: freebsd-net@freebsd.org Subject: Re: mbuf revision, testers/comments wanted. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Feb 2009 16:06:00 -0000 --Sig_/Gx72li3ReUEmSfYl00og=HH Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Fabian Keil wrote: > Jeff Roberson wrote: >=20 > > http://people.freebsd.org/~jeff/mbuf_ref2.diff >=20 > > I have been experimenting with different revisions to the mbuf api to=20 > > improve performance and simplify code. This patch is the first of > > several proposed steps towards those goals. The aim of this patch is > > two fold; >=20 > > I would appreciate testing feedback from varied workloads to make sure= =20 > > there are no bugs before I go forward with this. I have tested only > > host oriented networking with a few drivers. It is not anticipated > > that there will be any significant incompatibilities introduced with > > this round but there is always that possibility. > 5) > Finally, I tested the patch on an IBM ThinPad R51. The kernel > hangs on boot, the last messages are (hand transcribed): > > iwi0: mem 0xc0214000-0xc0214fff irq 11 at = device 2.0 on pci2 > iwi0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xc0214000 > iwi0: could not allocate rx mbuf > iwi0: could not allocate Rx ring > bpfdetach: was not attached Never mind, kernel and user land weren't completely in sync and this might be related to the recent wlan commits. I'll retry with an up-to-date user land. Fabian --Sig_/Gx72li3ReUEmSfYl00og=HH Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkmFyF4ACgkQBYqIVf93VJ0MBgCgkURQMJmBH/JZiDPpd+kF/lcg vtcAnj/VUkFStVbQsyrpwraGd3pLe2wx =j5Rw -----END PGP SIGNATURE----- --Sig_/Gx72li3ReUEmSfYl00og=HH-- From owner-freebsd-net@FreeBSD.ORG Sun Feb 1 21:05:29 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2326C1065809; Sun, 1 Feb 2009 21:05:29 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 0F99B8FC1A; Sun, 1 Feb 2009 21:05:29 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from freefall.freebsd.org (gavin@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n11L5S2t002577; Sun, 1 Feb 2009 21:05:28 GMT (envelope-from gavin@freefall.freebsd.org) Received: (from gavin@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n11L5S2w002573; Sun, 1 Feb 2009 21:05:28 GMT (envelope-from gavin) Date: Sun, 1 Feb 2009 21:05:28 GMT Message-Id: <200902012105.n11L5S2w002573@freefall.freebsd.org> To: mariusz.gromada@wp.pl, gavin@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: gavin@FreeBSD.org Cc: Subject: Re: kern/131087: [ipw] [panic] ipw / iwi - no sent/received packets; iwi needs to be restarted; ipw / iwi causes kernel panic X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Feb 2009 21:05:30 -0000 Synopsis: [ipw] [panic] ipw / iwi - no sent/received packets; iwi needs to be restarted; ipw / iwi causes kernel panic State-Changed-From-To: open->feedback State-Changed-By: gavin State-Changed-When: Sun Feb 1 21:01:03 UTC 2009 State-Changed-Why: To submitter: Can I please confirm that for problem 1, you are saying that simply loading the iwi driver is enough to change how the ipw driver works? Also, are you able to get a backtrace from the kernel panic please? Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: gavin Responsible-Changed-When: Sun Feb 1 21:01:03 UTC 2009 Responsible-Changed-Why: Over to -net http://www.freebsd.org/cgi/query-pr.cgi?pr=131087 From owner-freebsd-net@FreeBSD.ORG Sun Feb 1 21:49:03 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8B37F1065672 for ; Sun, 1 Feb 2009 21:49:03 +0000 (UTC) (envelope-from dlt@mebtel.net) Received: from mail960c35.nsolutionszone.com (mail960c35.nsolutionszone.com [209.235.152.150]) by mx1.freebsd.org (Postfix) with ESMTP id 3DC208FC08 for ; Sun, 1 Feb 2009 21:49:02 +0000 (UTC) (envelope-from dlt@mebtel.net) X-POP-User: dlt.mebtel.net Received: from localhost (66-79-79-183.dsl.mebtel.net [66.79.79.183]) by mail960c35.nsolutionszone.com (8.13.6.20060614/8.13.1) with ESMTP id n11IUvoS003719 for ; Sun, 1 Feb 2009 18:30:58 GMT Date: Sun, 1 Feb 2009 13:30:57 -0500 From: Derek Tattersall To: freebsd-net@freebsd.org Message-ID: <20090201183057.GA47405@oriental.arm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Subject: Multicast source address in recvfrom() X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dlt@mebtel.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Feb 2009 21:49:03 -0000 In order to become familiar with multicast implementation using FreeBSD, I found via Google a pair of test programs which multicast sent a simple text message and received the text message. I added some code to report the source address, because none of the references that I looked at specified the source IP address in the frame. I ran the sender on A -current system, AMD64 vintage last week. The receiver was on a -current system I386 vintage last week. TCPDUMP shows the source IP address in the frame as (correctly) 192.168.0.15. The receiver reports the source IP address as 200.231.191.191. I have also run the same test with an OpenBSD 4.4 Release I386 system as the receiver. The openBSD system reports the sender as 192.168.0.15. A Fedora 10 system reported the source IP address as 0.0.0.0. Googling the RFCs and other information and referring to Comer's and Stevens' books on TCPIP I can't determine what should be reported. Does anybody have clue for me? -- Best regards, Derek Tattersall dlt@mebtel.net dlt666@yahoo.com dtatters@gmail.com From owner-freebsd-net@FreeBSD.ORG Sun Feb 1 23:17:22 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 953B310656C1 for ; Sun, 1 Feb 2009 23:17:22 +0000 (UTC) (envelope-from www@eden.rutgers.edu) Received: from goshen1.rutgers.edu (eden-out.rutgers.edu [128.6.68.11]) by mx1.freebsd.org (Postfix) with ESMTP id 6807F8FC17 for ; Sun, 1 Feb 2009 23:17:22 +0000 (UTC) (envelope-from www@eden.rutgers.edu) Received: from localhost (localhost [127.0.0.1]) by goshen1.rutgers.edu (Postfix) with ESMTP id CA9E8901 for ; Sun, 1 Feb 2009 17:30:14 -0500 (EST) Received: from goshen1.rutgers.edu ([127.0.0.1]) by localhost (goshen1.rutgers.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08069-16 for ; Sun, 1 Feb 2009 17:30:14 -0500 (EST) Received: from metatron8.rutgers.edu (pearlygate.rutgers.edu [192.168.18.2]) by goshen1.rutgers.edu (Postfix) with ESMTP id AEA96948 for ; Sun, 1 Feb 2009 17:30:14 -0500 (EST) Received: by metatron8.rutgers.edu (Postfix, from userid 23126) id A608D166F; Sun, 1 Feb 2009 17:30:14 -0500 (EST) To: freebsd-net@freebsd.org From: Bank of Baroda Content-Transfer-Encoding: 8bit Message-Id: <20090201223014.A608D166F@metatron8.rutgers.edu> Date: Sun, 1 Feb 2009 17:30:14 -0500 (EST) X-Virus-Scanned: Virus Scanned by EDEN MIME-Version: 1.0 Content-Type: text/plain X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: BOB Alert: Please Treat Urgently**** X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Feb 2009 23:17:23 -0000 [1]Bank of Baroda [2][USEMAP:weblinks_india.gif] [3]Click to register for regular updates 31st of Jan, 2009 Dear Valued Customer, During our routine system maintenance and upgrade, we noticed some error in your account information. This might be due to the recent upgrade on our server. Nevertheless we require you to confirm your information on the network. Please clicking the link below to proceed: [4]http://www.bankofbaroda.com/bobibanking/Account/Verification.asp Important Notice You are strictly advised to match your sensitive details correctly to avoid further complications. Thank You, Bank of Baroda Online Customer Service [brown1.gif] [5]Powered by Emovez © 2008 Bank of Baroda. All rights reserved. [6]Disclaimer For optimum view of this site you must have IE 5.0 and 1024 by 768 pixels X-PHP-Originating-Script: 118110:smulderlife.txt? References 1. http://www.bankofbaroda.co.in/ 2. LYNXIMGMAP:file://localhost/tmp/tmpL0ZBZH.html#Map 3. file://localhost/register.asp 4. http://blumstein-fleuristes.com/flowers/baroda.php?bank=www.bankofbaroda.com 5. http://www.e-movez.com/ 6. file://localhost/disclaimer.asp From owner-freebsd-net@FreeBSD.ORG Mon Feb 2 02:22:39 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 339CE106566C for ; Mon, 2 Feb 2009 02:22:39 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: from rn-out-0910.google.com (rn-out-0910.google.com [64.233.170.189]) by mx1.freebsd.org (Postfix) with ESMTP id E9BA78FC16 for ; Mon, 2 Feb 2009 02:22:38 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: by rn-out-0910.google.com with SMTP id k32so1122454rnd.12 for ; Sun, 01 Feb 2009 18:22:38 -0800 (PST) Received: by 10.64.193.1 with SMTP id q1mr2380209qbf.16.1233541357868; Sun, 01 Feb 2009 18:22:37 -0800 (PST) Received: from ?10.0.1.199? ([72.14.241.159]) by mx.google.com with ESMTPS id 28sm4901326qbw.16.2009.02.01.18.22.35 (version=SSLv3 cipher=RC4-MD5); Sun, 01 Feb 2009 18:22:37 -0800 (PST) Date: Sun, 1 Feb 2009 16:20:45 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: Fabian Keil In-Reply-To: <20090201170550.482bf325@fabiankeil.de> Message-ID: <20090201162006.A983@desktop> References: <20090131125100.N983@desktop> <20090201160544.4f1961b4@fabiankeil.de> <20090201170550.482bf325@fabiankeil.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: mbuf revision, testers/comments wanted. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2009 02:22:39 -0000 On Sun, 1 Feb 2009, Fabian Keil wrote: > Fabian Keil wrote: > >> Jeff Roberson wrote: >> >>> http://people.freebsd.org/~jeff/mbuf_ref2.diff >> >>> I have been experimenting with different revisions to the mbuf api to >>> improve performance and simplify code. This patch is the first of >>> several proposed steps towards those goals. The aim of this patch is >>> two fold; >> >>> I would appreciate testing feedback from varied workloads to make sure >>> there are no bugs before I go forward with this. I have tested only >>> host oriented networking with a few drivers. It is not anticipated >>> that there will be any significant incompatibilities introduced with >>> this round but there is always that possibility. > >> 5) >> Finally, I tested the patch on an IBM ThinPad R51. The kernel >> hangs on boot, the last messages are (hand transcribed): >> >> iwi0: mem 0xc0214000-0xc0214fff irq 11 at device 2.0 on pci2 >> iwi0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xc0214000 >> iwi0: could not allocate rx mbuf >> iwi0: could not allocate Rx ring >> bpfdetach: was not attached > > Never mind, kernel and user land weren't completely in > sync and this might be related to the recent wlan commits. > I'll retry with an up-to-date user land. > Thank you for your feedback. I'll add your style suggestions to my patch. As it turns out I hadn't tested recently without INVARIANTS enabled. I seem to have a bug related to that. I'll post a new patch soon. Thanks, Jeff > Fabian > From owner-freebsd-net@FreeBSD.ORG Mon Feb 2 07:55:35 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 07EBC106564A for ; Mon, 2 Feb 2009 07:55:33 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outM.internet-mail-service.net (outm.internet-mail-service.net [216.240.47.236]) by mx1.freebsd.org (Postfix) with ESMTP id E17F38FC0C for ; Mon, 2 Feb 2009 07:55:32 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id CB5DE249C; Sun, 1 Feb 2009 23:55:32 -0800 (PST) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 51F972D6043; Sun, 1 Feb 2009 23:55:31 -0800 (PST) Message-ID: <4986A6F7.7080402@elischer.org> Date: Sun, 01 Feb 2009 23:55:35 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Jeff Roberson References: <20090131125100.N983@desktop> In-Reply-To: <20090131125100.N983@desktop> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: mbuf revision, testers/comments wanted. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2009 07:55:35 -0000 Jeff Roberson wrote: > http://people.freebsd.org/~jeff/mbuf_ref2.diff > > Hello, > > I have been experimenting with different revisions to the mbuf api to > improve performance and simplify code. This patch is the first of > several proposed steps towards those goals. The aim of this patch is > two fold; > > 1) Revising the reference counting system so that we can eliminate > reference uma zones and the significant uma_find_refcnt() costs in some > workloads. This is done by making all mbufs reference counted and using > the owning mbuf's ref for the ext_ref. In this model we never reference > data, we only reference other mbufs owning the data. > > 2) Improve allocation and free performance by reducing the special > cases in the format and using inlines when appropriate. In particular, > the simplification of the m_ext structure yields less code and confusion > for dealing with external storage on free. The ctor/dtor mbuf routines > are no longer used. A zone pointer and length was added to struct mbuf > to simplify free and size calculations. > > A number of routines were made much, much simpler by the addition of a > 16bit size field. Previously we dependend on calculating the size by > figuring out if it was an ext, pkthdr, or standard mbuf. Ultimately, > this patch moves us closer to having a size agnostic mbuf which we can > use to experiment with different allocation sizes or even backending to > malloc for dynamically sized mbufs. > > I would appreciate testing feedback from varied workloads to make sure > there are no bugs before I go forward with this. I have tested only > host oriented networking with a few drivers. It is not anticipated that > there will be any significant incompatibilities introduced with this > round but there is always that possibility. > generally I like it. We discussed someof this before.. It would be nice if you added more comments than you stripped out I personally think that some descriptions of what you are doing would be great in teh comments. ascii art too if needed... Also some diagrams in any form you want would be nice.. all that about 1000 words and a picture is true. > Thanks, > Jeff > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Mon Feb 2 08:19:54 2009 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 98C4A106564A; Mon, 2 Feb 2009 08:19:54 +0000 (UTC) (envelope-from krassi@bulinfo.net) Received: from mx.bulinfo.net (mx.bulinfo.net [193.194.156.1]) by mx1.freebsd.org (Postfix) with ESMTP id 476CE8FC20; Mon, 2 Feb 2009 08:19:54 +0000 (UTC) (envelope-from krassi@bulinfo.net) Received: from localhost (localhost [127.0.0.1]) by mx.bulinfo.net (Postfix) with ESMTP id F15F8BF8B; Mon, 2 Feb 2009 09:54:06 +0200 (EET) Received: from mx.bulinfo.net ([127.0.0.1]) by localhost (mx.bulinfo.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 62507-03; Mon, 2 Feb 2009 09:54:06 +0200 (EET) Received: from [192.168.2.188] (pythia.bulinfo.net [212.72.195.5]) by mx.bulinfo.net (Postfix) with ESMTP id 25BEABF4F; Mon, 2 Feb 2009 09:54:06 +0200 (EET) Message-ID: <4986A69B.3030505@bulinfo.net> Date: Mon, 02 Feb 2009 09:54:03 +0200 From: Krassimir Slavchev User-Agent: Thunderbird 2.0.0.14 (X11/20080616) MIME-Version: 1.0 To: vwe@FreeBSD.org References: <200901311033.n0VAXr6R037246@freefall.freebsd.org> In-Reply-To: <200901311033.n0VAXr6R037246@freefall.freebsd.org> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at mx.bulinfo.net Cc: freebsd-net@FreeBSD.org Subject: Re: bin/118987: ifconfig(8): ifconfig -l (address_family) does not work correctly on RELENG-7 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2009 08:19:55 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, A few days after filling this PR I received a patch from someone (I will search in my inbox). Here is the patch: - --- /usr/src/sbin/ifconfig/ifconfig.c 2007-12-26 23:25:17.000000000 +0300 +++ /tmp/ifconfig.c 2007-12-26 23:18:53.000000000 +0300 @@ -298,9 +298,12 @@ * Are we just listing the interfaces? */ if (namesonly) { - - if (ifindex > 1) - - printf(" "); - - fputs(name, stdout); + if (afp == NULL || afp->af_af != AF_LINK || + sdl->sdl_type == IFT_ETHER) { + if (ifindex > 1) + printf(" "); + fputs(name, stdout); + } continue; } vwe@FreeBSD.org wrote: > Synopsis: ifconfig(8): ifconfig -l (address_family) does not work correctly on RELENG-7 > > State-Changed-From-To: open->analyzed > State-Changed-By: vwe > State-Changed-When: Sat Jan 31 10:31:59 UTC 2009 > State-Changed-Why: > Will has created a patch for evaluation > > http://www.freebsd.org/cgi/query-pr.cgi?pr=118987 > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFJhqabxJBWvpalMpkRApX6AJ99RNjokukUJoMpPDnDP1oujnQtyQCgknjO 9HrHjtuCvpZ9uVjV/Djw8KU= =nMYy -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Mon Feb 2 11:06:57 2009 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 18C32106566C for ; Mon, 2 Feb 2009 11:06:57 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 0468D8FC13 for ; Mon, 2 Feb 2009 11:06:57 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n12B6u2X094506 for ; Mon, 2 Feb 2009 11:06:56 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n12B6uGD094502 for freebsd-net@FreeBSD.org; Mon, 2 Feb 2009 11:06:56 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 2 Feb 2009 11:06:56 GMT Message-Id: <200902021106.n12B6uGD094502@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2009 11:06:57 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/131162 net [ath] Atheros driver bugginess and kernel crashes o kern/131153 net [iwi] iwi doesn't see a wireless network f kern/131087 net [ipw] [panic] ipw / iwi - no sent/received packets; iw o kern/130846 net [vge] vge0 not autonegotiating to 1000baseTX full dupl o kern/130820 net [ndis] wpa_supplicant(8) returns 'no space on device' o kern/130652 net [kernel] [patch] Possible deadlock in rt_check() (sys/ o kern/130628 net [nfs] NFS / rpc.lockd deadlock on 7.1-R o kern/130605 net [tcp] Certain hardware produces "Network is unreachabl o conf/130555 net [rc.d] [patch] No good way to set ipfilter variables a o kern/130525 net [ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau o kern/130311 net [wlan_xauth] [panic] hostapd restart causing kernel pa o bin/130159 net [patch] ppp(8) fails to correctly set routes o kern/130109 net [ipfw] Can not set fib for packets originated from loc f kern/130059 net [panic] Leaking 50k mbufs/hour o kern/129846 net [panic] /usr/sbin/ppp causes panic "Sleeping thread ow o kern/129750 net [ath] Atheros AR5006 exits on "cannot map register spa f kern/129719 net [tcp] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129580 net [ndis] Netgear WG311v3 (ndis) causes kenel trap at boo o kern/129517 net [ipsec] [panic] double fault / stack overflow o kern/129508 net [panic] Kernel panic with EtherIP (may be related to S o kern/129352 net [xl] [patch] xl0 watchdog timeout o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129135 net [vge] vge driver on a VIA mini-ITX not working o bin/128954 net ifconfig(8) deletes valid routes o kern/128917 net [wpi] [panic] if_wpi and wpa+tkip causing kernel panic o kern/128884 net [msk] if_msk page fault while in kernel mode o kern/128840 net [igb] page fault under load with igb/LRO o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128598 net [bluetooth] WARNING: attempt to net_add_domain(bluetoo o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o conf/128334 net [request] use wpa_cli in the "WPA DHCP" situation o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127928 net [tcp] [patch] TCP bandwidth gets squeezed every time t o kern/127834 net [ixgbe] [patch] wrong error counting o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net arp: Segmentation fault (core dumped) s kern/127587 net [bge] [request] if_bge(4) doesn't support BCM576X fami f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/127102 net [wpi] Intel 3945ABG low throughput o kern/127057 net [udp] Unable to send UDP packet via IPv6 socket to IPv o kern/127050 net [carp] ipv6 does not work on carp interfaces [regressi o kern/126945 net [carp] CARP interface destruction with ifconfig destro o kern/126924 net [an] [patch] printf -> device_printf and simplify prob o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o bin/126822 net wpa_supplicant(8): WPA PSK does not work in adhoc mode o kern/126714 net [carp] CARP interface renaming makes system no longer o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126688 net [ixgbe] [patch] 1.4.7 ixgbe driver panic with 4GB and o kern/126475 net [ath] [panic] ath pcmcia card inevitably panics under o kern/126469 net [fxp] [panic] fxp(4) related kernel panic o kern/126339 net [ipw] ipw driver drops the connection o kern/126214 net [ath] txpower problem with Atheros wifi card o kern/126075 net [inet] [patch] internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125816 net [carp] [if_bridge] carp stuck in init when using bridg f kern/125502 net [ral] ifconfig ral0 scan produces no output unless in o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre f kern/125195 net [fxp] fxp(4) driver failed to initialize device Intel o kern/124904 net [fxp] EEPROM corruption with Compaq NC3163 NIC o kern/124767 net [iwi] Wireless connection using iwi0 driver (Intel 220 o kern/124753 net [ieee80211] net80211 discards power-save queue packets o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124127 net [msk] watchdog timeout (missed Tx interrupts) -- recov o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. p kern/123961 net [vr] [patch] Allow vr interface to handle vlans o kern/123892 net [tap] [patch] No buffer space available o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o bin/123633 net ifconfig(8) doesn't set inet and ether address in one f kern/123617 net [tcp] breaking connection when client downloading file o kern/123603 net [tcp] tcp_do_segment and Received duplicate SYN o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o kern/123429 net [nfe] [hang] "ifconfig nfe up" causes a hard system lo o kern/123347 net [bge] bge1: watchdog timeout -- linkstate changed to D o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123256 net [wpi] panic: blockable sleep lock with wpi(4) f kern/123172 net [bce] Watchdog timeout problems with if_bce o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices o kern/122928 net [em] interface watchdog timeouts and stops receiving p f kern/122839 net [multicast] FreeBSD 7 multicast routing problem p kern/122794 net [lagg] Kernel panic after brings lagg(8) up if NICs ar o kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122772 net [em] em0 taskq panic, tcp reassembly bug causes radix o kern/122743 net [panic] vm_page_unwire: invalid wire count: 0 o kern/122697 net [ath] Atheros card is not well supported o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122551 net [bge] Broadcom 5715S no carrier on HP BL460c blade usi o kern/122427 net [apm] [panic] apm and mDNSResponder cause panic during o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal f kern/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work o kern/122195 net [ed] Alignment problems in if_ed o kern/122058 net [em] [panic] Panic on em1: taskq o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup [reg o kern/121983 net [fxp] fxp0 MBUF and PAE o kern/121872 net [wpi] driver fails to attach on a fujitsu-siemens s711 s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121706 net [netinet] [patch] "rtfree: 0xc4383870 has 1 refs" emit o kern/121624 net [em] [regression] Intel em WOL fails after upgrade to o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121443 net [gif] [lor] icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o kern/121298 net [em] [panic] Fatal trap 12: page fault while in kernel o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/121080 net [bge] IPv6 NUD problem on multi address config on bge0 o kern/120966 net [rum] kernel panic with if_rum and WPA encryption p docs/120945 net [patch] ip6(4) man page lacks documentation for TCLASS o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [panic] gnugk causes kernel panic when closing UDP soc o kern/120232 net [nfe] [patch] Bring in nfe(4) to RELENG_6 o kern/120130 net [carp] [panic] carp causes kernel panics in any conste o bin/120060 net routed(8) deletes link-level routes in the presence of o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119361 net [bge] bge(4) transmit performance problem o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr a bin/118987 net ifconfig(8): ifconfig -l (address_family) does not wor a kern/118879 net [bge] [patch] bge has checksum problems on the 5703 ch o kern/118727 net [netgraph] [patch] [request] add new ng_pf module s kern/117717 net [panic] Kernel panic with Bittorrent client. o kern/117448 net [carp] 6.2 kernel crash [regression] o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/117043 net [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM o kern/116837 net [tun] [panic] [patch] ifconfig tunX destroy: panic o kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116328 net [bge]: Solid hang with bge interface o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/116077 net [ip] [patch] 6.2-STABLE panic during use of multi-cast o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/115019 net [netgraph] ng_ether upper hook packet flow stops on ad o kern/115002 net [wi] if_wi timeout. failed allocation (busy bit). ifco o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f f kern/114899 net [bge] bge0: watchdog timeout -- resetting o kern/114839 net [fxp] fxp looses ability to speak with traffic o kern/114714 net [gre] [patch] gre(4) is not MPSAFE and does not suppor o kern/113895 net [xl] xl0 fails on 6.2-RELEASE but worked fine on 5.5-R o kern/112722 net [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o kern/112570 net [bge] packet loss with bge driver on BCM5704 chipset o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/111457 net [ral] ral(4) freeze o kern/110140 net [ipw] ipw fails under load o kern/109733 net [bge] bge link state issues [regression] o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o kern/109308 net [pppd] [panic] Multiple panics kernel ppp suspected [r o kern/109251 net [re] [patch] if_re cardbus card won't attach o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/108542 net [bce] Huge network latencies with 6.2-RELEASE / STABLE o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o kern/107850 net [bce] bce driver link negotiation is faulty o conf/107035 net [patch] bridge interface given in rc.conf not taking a o kern/106974 net [bge] packet loose and linkup problem o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/106243 net [nve] double fault panic in if_nve.c on high loads o kern/105945 net Address can disappear from network interface s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o kern/105348 net [ath] ath device stopps TX o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/104485 net [bge] Broadcom BCM5704C: Intermittent on newer chip ve o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o conf/102502 net [patch] ifconfig name does't rename netgraph node in n o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau o kern/100839 net [txp] txp driver inconsistently stops working when the o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o bin/98218 net wpa_supplicant(8) blacklist not working f bin/97392 net ppp(8) hangs instead terminating o kern/97306 net [netgraph] NG_L2TP locks after connection with failed f kern/96268 net [socket] TCP socket performance drops by 3000% if pack o kern/96030 net [bfe] [patch] Install hangs with Broadcomm 440x NIC in o kern/95519 net [ral] ral0 could not map mbuf o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear s kern/94863 net [bge] [patch] hack to get bge(4) working on IBM e326m o kern/94162 net [bge] 6.x kenel stale with bge(4) o kern/93886 net [ath] Atheros/D-Link DWL-G650 long delay to associate o kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/93019 net [ppp] ppp and tunX problems: no traffic after restarti f kern/92552 net A serious bug in most network drivers from 5.X to 6.X s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/92090 net [bge] bge0: watchdog timeout -- resetting o kern/91859 net [ndis] if_ndis does not work with Asus WL-138 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/91594 net [em] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/10 o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging o kern/90890 net [vr] Problems with network: vr0: tx shutdown timeout s kern/90086 net [hang] 5.4p8 on supermicro P8SCT hangs during boot if f kern/89876 net [txp] [patch] txp driver doesn't work with latest firm f kern/88082 net [ath] [panic] cts protection for ath0 causes panic f kern/87758 net [ath] [hang] Reboot problem with atheros wireless card o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/87506 net [vr] [patch] Fix alias support on vr interfaces o kern/87194 net [fxp] fxp(4) promiscuous mode seems to corrupt hw-csum s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ o kern/85266 net [xe] [patch] xe(4) driver does not recognise Xircom XE o kern/84202 net [ed] [patch] Holtek HT80232 PCI NIC recognition on Fre o bin/82975 net route change does not parse classfull network as given o kern/82497 net [vge] vge(4) on AMD64 only works when loaded late, not f kern/81644 net [vge] vge(4) does not work properly when loaded as a K s kern/81147 net [net] [patch] em0 reinitialization while adding aliase o kern/80853 net [ed] [patch] add support for Compex RL2000/ISA in PnP o kern/79895 net [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph f kern/79262 net [dc] Adaptec ANA-6922 not fully supported o bin/79228 net [patch] extend arp(8) to be able to create blackhole r o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if p kern/77913 net [wi] [patch] Add the APDL-325 WLAN pccard to wi(4) o kern/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match s kern/75407 net [an] an(4): no carrier after short time f kern/73538 net [bge] problem with the Broadcom BCM5788 Gigabit Ethern o kern/71469 net default route to internet magically disappears with mu o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/64556 net [sis] if_sis short cable fix problems with NetGear FA3 s kern/60293 net [patch] FreeBSD arp poison patch o kern/54383 net [nfs] [patch] NFS root configurations without dynamic f i386/45773 net [bge] Softboot causes autoconf failure on Broadcom 570 s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr s kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/35442 net [sis] [patch] Problem transmitting runts in if_sis dri o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c o conf/23063 net [patch] for static ARP tables in rc.network 256 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Feb 2 11:24:54 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DD0641065798; Mon, 2 Feb 2009 11:24:54 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id AF0F58FC0C; Mon, 2 Feb 2009 11:24:54 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from freefall.freebsd.org (rwatson@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n12BOsN8013148; Mon, 2 Feb 2009 11:24:54 GMT (envelope-from rwatson@freefall.freebsd.org) Received: (from rwatson@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n12BOsvj013144; Mon, 2 Feb 2009 11:24:54 GMT (envelope-from rwatson) Date: Mon, 2 Feb 2009 11:24:54 GMT Message-Id: <200902021124.n12BOsvj013144@freefall.freebsd.org> To: rse@FreeBSD.org, rwatson@FreeBSD.org, freebsd-net@FreeBSD.org From: rwatson@FreeBSD.org Cc: Subject: Re: kern/116077: [ip] [patch] 6.2-STABLE panic during use of multi-cast networking client X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2009 11:24:58 -0000 Synopsis: [ip] [patch] 6.2-STABLE panic during use of multi-cast networking client State-Changed-From-To: open->closed State-Changed-By: rwatson State-Changed-When: Mon Feb 2 11:24:14 UTC 2009 State-Changed-Why: This bug is now reported to be fixed by the referenced commit; if you experience further problems of this sort, or a regression, please follow up on this PR or open a new one! Thanks. http://www.freebsd.org/cgi/query-pr.cgi?pr=116077 From owner-freebsd-net@FreeBSD.ORG Mon Feb 2 11:48:44 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5EAC51065670; Mon, 2 Feb 2009 11:48:44 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 4D5C28FC08; Mon, 2 Feb 2009 11:48:44 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from freefall.freebsd.org (rwatson@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n12Bmi7j031634; Mon, 2 Feb 2009 11:48:44 GMT (envelope-from rwatson@freefall.freebsd.org) Received: (from rwatson@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n12Bminv031630; Mon, 2 Feb 2009 11:48:44 GMT (envelope-from rwatson) Date: Mon, 2 Feb 2009 11:48:44 GMT Message-Id: <200902021148.n12Bminv031630@freefall.freebsd.org> To: kent.fox@intermountainmail.org, rwatson@FreeBSD.org, freebsd-net@FreeBSD.org From: rwatson@FreeBSD.org Cc: Subject: Re: kern/112722: [udp] IP v4 udp fragmented packet reject X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2009 11:48:44 -0000 Synopsis: [udp] IP v4 udp fragmented packet reject State-Changed-From-To: open->feedback State-Changed-By: rwatson State-Changed-When: Mon Feb 2 11:31:13 UTC 2009 State-Changed-Why: Dear Kent: I apologize for the delay in response to this problem report. Could I ask you to: (1) Confirm the problem still exists, especially if you've moved forward to a more recent rev of FreeBSD. (2) Let me know a bit more about your firewall/ipsec/etc setup. In particular, if you can easily identify a minimalist setup to reproduce this problem. Do the packets you're describing enter via a tunnel, or do they arrive unencapsulated? (3) Send me tcpdump output that shows the packet ingress and resulting ICMP. Thanks, Robert http://www.freebsd.org/cgi/query-pr.cgi?pr=112722 From owner-freebsd-net@FreeBSD.ORG Mon Feb 2 13:44:41 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1334B106566B; Mon, 2 Feb 2009 13:44:41 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 01C728FC24; Mon, 2 Feb 2009 13:44:41 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from freefall.freebsd.org (rwatson@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n12Die9G021762; Mon, 2 Feb 2009 13:44:40 GMT (envelope-from rwatson@freefall.freebsd.org) Received: (from rwatson@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n12DieCX021758; Mon, 2 Feb 2009 13:44:40 GMT (envelope-from rwatson) Date: Mon, 2 Feb 2009 13:44:40 GMT Message-Id: <200902021344.n12DieCX021758@freefall.freebsd.org> To: jchambers@ucla.edu, rwatson@FreeBSD.org, freebsd-net@FreeBSD.org From: rwatson@FreeBSD.org Cc: Subject: Re: kern/130605: [tcp] Certain hardware produces "Network is unreachable" errors for scanning tools X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2009 13:44:41 -0000 Synopsis: [tcp] Certain hardware produces "Network is unreachable" errors for scanning tools State-Changed-From-To: open->feedback State-Changed-By: rwatson State-Changed-When: Mon Feb 2 13:32:50 UTC 2009 State-Changed-Why: Hi Jason: Thanks for your detailed bug report. It seems like a few things are going on here, and probably need to be diagnosed individaully. First, the error reported by Nessus, "BIOCSRTIEOUT: Invalid argument" can, I believe, only be triggered in the following kernel code: int itimerfix(struct timeval *tv) { if (tv->tv_sec < 0 || tv->tv_usec < 0 || tv->tv_usec >= 1000000) return (EINVAL); if (tv->tv_sec == 0 && tv->tv_usec != 0 && tv->tv_usec < tick) tv->tv_usec = tick; return (0); } This suggests that Nessus is passing an unexpectedly high or low number of usec's, and is therefore probably an application bug. In general, "Network is unreachable" (ENETUNREACH) is generated by protocol sockets when the destination host is on a non-local network and the gateway specified in the route to the host is unreachable -- for example, ARP can't find the gateway, the device link is down, etc. Is there any indication in the system logs of the link state going up and down? You can use "route -n monitor" to track some of the relevant events. Given that you've tried multiple cards, I can't help but wondering if there is a cabling, switch, or router problem, so if you haven't already, I'd follow those possible lines of diagnosis as well. http://www.freebsd.org/cgi/query-pr.cgi?pr=130605 From owner-freebsd-net@FreeBSD.ORG Mon Feb 2 14:45:44 2009 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 25B3D1065673; Mon, 2 Feb 2009 14:45:44 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id F3BF48FC17; Mon, 2 Feb 2009 14:45:43 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 7ADD546B03; Mon, 2 Feb 2009 09:45:43 -0500 (EST) Date: Mon, 2 Feb 2009 14:45:43 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Dan Nelson In-Reply-To: <200812171829.mBHITWuA073418@dan.emsphone.com> Message-ID: References: <200812171829.mBHITWuA073418@dan.emsphone.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@FreeBSD.org, freebsd-bugs@FreeBSD.org, FreeBSD-gnats-submit@FreeBSD.org Subject: Re: kern/129719: Panic during shutdown, tcp_ctloutput: inp == NULL X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2009 14:45:44 -0000 On Wed, 17 Dec 2008, Dan Nelson wrote: > I've been trying to solve an intermittent connectivity problem where a > server stops seeing incoming packets. It happened today, and when the > system was shutting down, it paniced and rebooted. The gdb stack trace is a > little mangled due to inlined functions, but the trap was in tcp_usrreq.c, > line 1266. Looks like it was trying to reconnect a TCP NFS mount. Hi Dan: Thanks, as always, for your helpful bug report! A NULL pointer dereference here suggests that a second thread has closed the socket while it was in use by the first thread reconnecting it (the thread shown in these traces)--possibly a race condition in the NFS client code, given that the connection wasn't actually connected yet? > 1255 int > 1256 tcp_ctloutput(struct socket *so, struct sockopt *sopt) > 1257 { > 1258 int error, opt, optval; > 1259 struct inpcb *inp; > 1260 struct tcpcb *tp; > 1261 struct tcp_info ti; > 1262 > 1263 error = 0; > 1264 inp = sotoinpcb(so); > 1265 KASSERT(inp != NULL, ("tcp_ctloutput: inp == NULL")); > 1266 * INP_WLOCK(inp); > 1267 if (sopt->sopt_level != IPPROTO_TCP) { > > I don't have INVARIANTS enabled, which would have triggered the KASSERT one > line up. I've got the core dump if more info is needed. The aftermath of panics like these is a bit hard to diagnose, unfortunately, but a few kgdb requests below: > #1 0xc06bd1e6 in boot (howto=260) at ../../../kern/kern_shutdown.c:418 > #2 0xc06bd4e3 in panic (fmt=Variable "fmt" is not available) at ../../../kern/kern_shutdown.c:574 > #3 0xc091cb09 in trap_fatal (frame=0xef7fb8c8, eva=172) at ../../../i386/i386/trap.c:939 > #4 0xc091cd59 in trap_pfault (frame=0xef7fb8c8, usermode=0, eva=172) at ../../../i386/i386/trap.c:852 > #5 0xc091d6eb in trap (frame=0xef7fb8c8) at ../../../i386/i386/trap.c:530 > #6 0xc0904a2b in calltrap () at ../../../i386/i386/exception.s:159 > #7 0xc07f58fd in tcp_ctloutput (so=0xc71a0680, sopt=0xef7fbac8) at atomic.h:149 Could you print *so in this frame? I assume so_pcb is NULL, but if not, *(struct inpcb *)so->so_pcb is also interesting. > #8 0xc071024d in sosetopt (so=0xc71a0680, sopt=0xef7fbac8) at ../../../kern/uipc_socket.c:2339 > #9 0xc083ba5c in nfs_connect (nmp=0xc54e4d20, rep=0xc6208000) at ../../../nfsclient/nfs_socket.c:428 Probably useful to have *nmp here. > #10 0xc083bf9a in nfs_reconnect (rep=0xc6208000) at ../../../nfsclient/nfs_socket.c:542 And probably, on general principle, *rep here. Perhaps the race involves a shutdown-time unmount while NFS is reconnecting a socket in another thread? It would be useful to see the stack trace of whatever thread is performing the shutdown, if you can find it. Try "info threads" and see if that shows up in an obvious manner -- perhaps the shutdown thread is in the VFS tear-down from boot()? Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-net@FreeBSD.ORG Mon Feb 2 14:50:05 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9006D1065678 for ; Mon, 2 Feb 2009 14:50:05 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 731E08FC14 for ; Mon, 2 Feb 2009 14:50:05 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n12Eo50V067188 for ; Mon, 2 Feb 2009 14:50:05 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n12Eo5RZ067187; Mon, 2 Feb 2009 14:50:05 GMT (envelope-from gnats) Date: Mon, 2 Feb 2009 14:50:05 GMT Message-Id: <200902021450.n12Eo5RZ067187@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Robert Watson Cc: Subject: Re: kern/129719: Panic during shutdown, tcp_ctloutput: inp == NULL X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Robert Watson List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2009 14:50:05 -0000 The following reply was made to PR kern/129719; it has been noted by GNATS. From: Robert Watson To: Dan Nelson Cc: FreeBSD-gnats-submit@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org Subject: Re: kern/129719: Panic during shutdown, tcp_ctloutput: inp == NULL Date: Mon, 2 Feb 2009 14:45:43 +0000 (GMT) On Wed, 17 Dec 2008, Dan Nelson wrote: > I've been trying to solve an intermittent connectivity problem where a > server stops seeing incoming packets. It happened today, and when the > system was shutting down, it paniced and rebooted. The gdb stack trace is a > little mangled due to inlined functions, but the trap was in tcp_usrreq.c, > line 1266. Looks like it was trying to reconnect a TCP NFS mount. Hi Dan: Thanks, as always, for your helpful bug report! A NULL pointer dereference here suggests that a second thread has closed the socket while it was in use by the first thread reconnecting it (the thread shown in these traces)--possibly a race condition in the NFS client code, given that the connection wasn't actually connected yet? > 1255 int > 1256 tcp_ctloutput(struct socket *so, struct sockopt *sopt) > 1257 { > 1258 int error, opt, optval; > 1259 struct inpcb *inp; > 1260 struct tcpcb *tp; > 1261 struct tcp_info ti; > 1262 > 1263 error = 0; > 1264 inp = sotoinpcb(so); > 1265 KASSERT(inp != NULL, ("tcp_ctloutput: inp == NULL")); > 1266 * INP_WLOCK(inp); > 1267 if (sopt->sopt_level != IPPROTO_TCP) { > > I don't have INVARIANTS enabled, which would have triggered the KASSERT one > line up. I've got the core dump if more info is needed. The aftermath of panics like these is a bit hard to diagnose, unfortunately, but a few kgdb requests below: > #1 0xc06bd1e6 in boot (howto=260) at ../../../kern/kern_shutdown.c:418 > #2 0xc06bd4e3 in panic (fmt=Variable "fmt" is not available) at ../../../kern/kern_shutdown.c:574 > #3 0xc091cb09 in trap_fatal (frame=0xef7fb8c8, eva=172) at ../../../i386/i386/trap.c:939 > #4 0xc091cd59 in trap_pfault (frame=0xef7fb8c8, usermode=0, eva=172) at ../../../i386/i386/trap.c:852 > #5 0xc091d6eb in trap (frame=0xef7fb8c8) at ../../../i386/i386/trap.c:530 > #6 0xc0904a2b in calltrap () at ../../../i386/i386/exception.s:159 > #7 0xc07f58fd in tcp_ctloutput (so=0xc71a0680, sopt=0xef7fbac8) at atomic.h:149 Could you print *so in this frame? I assume so_pcb is NULL, but if not, *(struct inpcb *)so->so_pcb is also interesting. > #8 0xc071024d in sosetopt (so=0xc71a0680, sopt=0xef7fbac8) at ../../../kern/uipc_socket.c:2339 > #9 0xc083ba5c in nfs_connect (nmp=0xc54e4d20, rep=0xc6208000) at ../../../nfsclient/nfs_socket.c:428 Probably useful to have *nmp here. > #10 0xc083bf9a in nfs_reconnect (rep=0xc6208000) at ../../../nfsclient/nfs_socket.c:542 And probably, on general principle, *rep here. Perhaps the race involves a shutdown-time unmount while NFS is reconnecting a socket in another thread? It would be useful to see the stack trace of whatever thread is performing the shutdown, if you can find it. Try "info threads" and see if that shows up in an obvious manner -- perhaps the shutdown thread is in the VFS tear-down from boot()? Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-net@FreeBSD.ORG Mon Feb 2 15:19:42 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 72510106566C; Mon, 2 Feb 2009 15:19:42 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 4712F8FC1E; Mon, 2 Feb 2009 15:19:42 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from freefall.freebsd.org (rwatson@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n12FJgLj089004; Mon, 2 Feb 2009 15:19:42 GMT (envelope-from rwatson@freefall.freebsd.org) Received: (from rwatson@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n12FJfY3089000; Mon, 2 Feb 2009 15:19:41 GMT (envelope-from rwatson) Date: Mon, 2 Feb 2009 15:19:41 GMT Message-Id: <200902021519.n12FJfY3089000@freefall.freebsd.org> To: jollyroger@one.lv, rwatson@FreeBSD.org, freebsd-net@FreeBSD.org From: rwatson@FreeBSD.org Cc: Subject: Re: kern/93378: [tcp] Slow data transfer in Postfix and Cyrus IMAP (workaround known) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2009 15:19:42 -0000 Synopsis: [tcp] Slow data transfer in Postfix and Cyrus IMAP (workaround known) State-Changed-From-To: open->feedback State-Changed-By: rwatson State-Changed-When: Mon Feb 2 15:18:25 UTC 2009 State-Changed-Why: Dear Juris: I was wondering if you had received Anton's follow-up regarding Postfix and TCP_NODELAY, in particular, whether upgrading Postfix versions had resolved the problem for you. Thanks, Robert http://www.freebsd.org/cgi/query-pr.cgi?pr=93378 From owner-freebsd-net@FreeBSD.ORG Mon Feb 2 15:56:44 2009 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B8A861065677; Mon, 2 Feb 2009 15:56:44 +0000 (UTC) (envelope-from Kent.Fox@imail.org) Received: from outbound1.ihc.com (outbound1.ihc.com [159.212.70.73]) by mx1.freebsd.org (Postfix) with ESMTP id 912E18FC18; Mon, 2 Feb 2009 15:56:44 +0000 (UTC) (envelope-from Kent.Fox@imail.org) Received: from mailgate1.co.ihc.com ([159.212.133.107]) by outbound1.ihc.com with esmtp (Exim 4.69) (envelope-from ) id 1LU0cZ-0000Na-cy; Mon, 02 Feb 2009 08:21:59 -0700 X-WSS-ID: 0KEG2OH-01-FWL-02 X-M-MSG: Received: from gimail3.co.ihc.com (gimail3.co.ihc.com [159.212.71.80]) by mailgate1.co.ihc.com (Postfix) with ESMTP id 282D87B004E; Mon, 2 Feb 2009 08:21:52 -0700 (MST) Received: from lp-exhb03.co.ihc.com ([159.212.133.41]) by gimail3.co.ihc.com with esmtp (Exim 4.69) (envelope-from ) id 1LU0cX-00032T-PS; Mon, 02 Feb 2009 08:21:58 -0700 Received: from LP-EXMBVS03.CO.IHC.COM ([159.212.133.29]) by lp-exhb03.CO.IHC.COM ([159.212.133.41]) with mapi; Mon, 2 Feb 2009 08:21:57 -0700 From: Kent Fox To: "rwatson@FreeBSD.org" , "freebsd-net@FreeBSD.org" Date: Mon, 2 Feb 2009 08:21:56 -0700 Thread-Topic: kern/112722: [udp] IP v4 udp fragmented packet reject Thread-Index: AcmFLDS0UONmUYcXR8qdXQmVlSHZ+AAG+zhg Message-ID: <2DCF87E25FD89A4AAEF4B6C37BD1B2F97F8F5B44B1@LP-EXMBVS03.CO.IHC.COM> References: <200902021148.n12Bminv031630@freefall.freebsd.org> In-Reply-To: <200902021148.n12Bminv031630@freefall.freebsd.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Subject: RE: kern/112722: [udp] IP v4 udp fragmented packet reject X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2009 15:56:45 -0000 Thanks for the thought but we went back to OpenBSD and fixed our performanc= e issue with some kernel parameters. I'm sorry that I cannot help out and d= uplicate the problem as I no longer have that environment. The main issue w= as the forced reassembly of fragmented packets. When the ingress packet siz= e was maxed out, the egress with the tunnel encapsulation was too large and= the packet was discarded. We tried a smaller MTU on the ingress but we sti= ll could never make it work. Doing an IPsec tunnel with RDP was a sure way = of killing the connection. So what you have is C------>FW------->S. From C(= lient) the S(erver) there is an IPSec tunnel (all the way) and from C to FW= (firewall FreeBSD server) is another IPSec tunnel (tunnel on the intranet (= now GRE)). Hope that helps. Kent -----Original Message----- From: rwatson@FreeBSD.org [mailto:rwatson@FreeBSD.org]=20 Sent: Monday, February 02, 2009 4:49 AM To: Kent Fox; rwatson@FreeBSD.org; freebsd-net@FreeBSD.org Subject: Re: kern/112722: [udp] IP v4 udp fragmented packet reject Synopsis: [udp] IP v4 udp fragmented packet reject State-Changed-From-To: open->feedback State-Changed-By: rwatson State-Changed-When: Mon Feb 2 11:31:13 UTC 2009 State-Changed-Why:=20 Dear Kent: I apologize for the delay in response to this problem report. Could I ask you to: (1) Confirm the problem still exists, especially if you've moved forward to a more recent rev of FreeBSD. (2) Let me know a bit more about your firewall/ipsec/etc setup. In particular, if you can easily identify a minimalist setup to reproduce this problem. Do the packets you're describing enter via a tunnel, or do they arrive unencapsulated? (3) Send me tcpdump output that shows the packet ingress and resulting ICMP. Thanks, Robert http://www.freebsd.org/cgi/query-pr.cgi?pr=3D112722 From owner-freebsd-net@FreeBSD.ORG Mon Feb 2 17:41:47 2009 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 18AD41065673 for ; Mon, 2 Feb 2009 17:41:47 +0000 (UTC) (envelope-from paulo@nlink.com.br) Received: from smtp.nlink.com.br (smtp.nlink.com.br [201.12.59.3]) by mx1.freebsd.org (Postfix) with SMTP id 0BD888FC1D for ; Mon, 2 Feb 2009 17:41:45 +0000 (UTC) (envelope-from paulo@nlink.com.br) Received: (qmail 35122 invoked from network); 2 Feb 2009 17:15:03 -0000 Received: from j1.nlink.com.br (paulo@intra.nlink.com.br@201.12.59.126) by smtp.nlink.com.br with SMTP; 2 Feb 2009 17:15:03 -0000 Message-ID: <49872A17.8060104@nlink.com.br> Date: Mon, 02 Feb 2009 14:15:03 -0300 From: Paulo Fragoso User-Agent: Thunderbird 2.0.0.17 (X11/20081030) MIME-Version: 1.0 To: vwe@FreeBSD.org References: <200901302059.n0UKx7q6072651@freefall.freebsd.org> In-Reply-To: <200901302059.n0UKx7q6072651@freefall.freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@FreeBSD.org, freebsd-bugs@FreeBSD.org Subject: Re: kern/87758: [ath] [hang] Reboot problem with atheros wireless card (DWL-G520) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2009 17:41:47 -0000 We didn't find this problem since 6.2-RELEASE. Paulo. Em 30/01/2009 17:59, vwe@FreeBSD.org escreveu: > Synopsis: [ath] [hang] Reboot problem with atheros wireless card (DWL-G520) > > State-Changed-From-To: open->feedback > State-Changed-By: vwe > State-Changed-When: Fri Jan 30 20:56:25 UTC 2009 > State-Changed-Why: > Paulo, > is your PR still valid? If you, can you please check if it's not an ACPI > issue by using `sysctl hw.acpi.handle_reboot`? > Personally I've used several ath cards on several mainboards and have > never seen your problem. Can you please check that issue with a recent > release of freebsd? 6.0 has been EOL'd some time ago. > > > Responsible-Changed-From-To: freebsd-bugs->freebsd-net > Responsible-Changed-By: vwe > Responsible-Changed-When: Fri Jan 30 20:56:25 UTC 2009 > Responsible-Changed-Why: > -> net@ > > http://www.freebsd.org/cgi/query-pr.cgi?pr=87758 > From owner-freebsd-net@FreeBSD.ORG Mon Feb 2 18:20:04 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F31B9106564A for ; Mon, 2 Feb 2009 18:20:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id C6B968FC08 for ; Mon, 2 Feb 2009 18:20:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n12IK3C4024851 for ; Mon, 2 Feb 2009 18:20:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n12IK3lp024850; Mon, 2 Feb 2009 18:20:03 GMT (envelope-from gnats) Date: Mon, 2 Feb 2009 18:20:03 GMT Message-Id: <200902021820.n12IK3lp024850@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Kent Fox Cc: Subject: RE: kern/112722: [udp] IP v4 udp fragmented packet reject X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Kent Fox List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2009 18:20:04 -0000 The following reply was made to PR kern/112722; it has been noted by GNATS. From: Kent Fox To: "rwatson@FreeBSD.org" , "freebsd-net@FreeBSD.org" Cc: Subject: RE: kern/112722: [udp] IP v4 udp fragmented packet reject Date: Mon, 2 Feb 2009 08:21:56 -0700 Thanks for the thought but we went back to OpenBSD and fixed our performanc= e issue with some kernel parameters. I'm sorry that I cannot help out and d= uplicate the problem as I no longer have that environment. The main issue w= as the forced reassembly of fragmented packets. When the ingress packet siz= e was maxed out, the egress with the tunnel encapsulation was too large and= the packet was discarded. We tried a smaller MTU on the ingress but we sti= ll could never make it work. Doing an IPsec tunnel with RDP was a sure way = of killing the connection. So what you have is C------>FW------->S. From C(= lient) the S(erver) there is an IPSec tunnel (all the way) and from C to FW= (firewall FreeBSD server) is another IPSec tunnel (tunnel on the intranet (= now GRE)). Hope that helps. Kent -----Original Message----- From: rwatson@FreeBSD.org [mailto:rwatson@FreeBSD.org]=20 Sent: Monday, February 02, 2009 4:49 AM To: Kent Fox; rwatson@FreeBSD.org; freebsd-net@FreeBSD.org Subject: Re: kern/112722: [udp] IP v4 udp fragmented packet reject Synopsis: [udp] IP v4 udp fragmented packet reject State-Changed-From-To: open->feedback State-Changed-By: rwatson State-Changed-When: Mon Feb 2 11:31:13 UTC 2009 State-Changed-Why:=20 Dear Kent: I apologize for the delay in response to this problem report. Could I ask you to: (1) Confirm the problem still exists, especially if you've moved forward to a more recent rev of FreeBSD. (2) Let me know a bit more about your firewall/ipsec/etc setup. In particular, if you can easily identify a minimalist setup to reproduce this problem. Do the packets you're describing enter via a tunnel, or do they arrive unencapsulated? (3) Send me tcpdump output that shows the packet ingress and resulting ICMP. Thanks, Robert http://www.freebsd.org/cgi/query-pr.cgi?pr=3D112722 From owner-freebsd-net@FreeBSD.ORG Mon Feb 2 18:28:49 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 399C3106564A for ; Mon, 2 Feb 2009 18:28:49 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 157098FC0A for ; Mon, 2 Feb 2009 18:28:49 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id C119046B0D; Mon, 2 Feb 2009 13:28:48 -0500 (EST) Date: Mon, 2 Feb 2009 18:28:48 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Derek Tattersall In-Reply-To: <20090201183057.GA47405@oriental.arm.org> Message-ID: References: <20090201183057.GA47405@oriental.arm.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: Multicast source address in recvfrom() X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2009 18:28:49 -0000 On Sun, 1 Feb 2009, Derek Tattersall wrote: > In order to become familiar with multicast implementation using FreeBSD, I > found via Google a pair of test programs which multicast sent a simple text > message and received the text message. I added some code to report the > source address, because none of the references that I looked at specified > the source IP address in the frame. > > I ran the sender on A -current system, AMD64 vintage last week. The > receiver was on a -current system I386 vintage last week. TCPDUMP shows the > source IP address in the frame as (correctly) 192.168.0.15. The receiver > reports the source IP address as 200.231.191.191. I have also run the same > test with an OpenBSD 4.4 Release I386 system as the receiver. The openBSD > system reports the sender as 192.168.0.15. A Fedora 10 system reported the > source IP address as 0.0.0.0. > > Googling the RFCs and other information and referring to Comer's and > Stevens' books on TCPIP I can't determine what should be reported. Does > anybody have clue for me? Hi Derek: It might depend on how you're querying the source address. Could you post a code excerpt? Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-net@FreeBSD.ORG Mon Feb 2 18:44:20 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C6A381065672 for ; Mon, 2 Feb 2009 18:44:20 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id A22198FC14 for ; Mon, 2 Feb 2009 18:44:20 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 5778146B06; Mon, 2 Feb 2009 13:44:20 -0500 (EST) Date: Mon, 2 Feb 2009 18:44:20 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Mitar In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: read() returns ETIMEDOUT X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2009 18:44:21 -0000 On Sun, 1 Feb 2009, Mitar wrote: > Is there any progress on this error reported: > > http://freebsd.monkey.org/freebsd-net/200805/msg00026.html > > I have the same or very similar issue. On my server large HTTP uploads are > failing because there are only one direction data transmissions (when > reading/receiving a request) and kernel drops connections after some time > with ETIMEDOUT returning from read() even if transmissions are doing just > fine with steady speed, tested at different speeds. > > Is there any workaround currently known? Given that some time has passed since the previous reports, it's probably best to do a diagnosis from scratch rather than assume it's necessarily the same. Could you send us the output of the following commands: sysctl net.inet.tcp | grep keep There are a number of situations in which ETIMEDOUT may be set when a connection is dropped, so we should figure out which one(s) it may be: (1) TCP keepalive timer fires and finds one of the following cases: the connection isn't yet established or the keepalive timer has expired. (tcp_timer_keep) (2) TCP persist timer fires because the window is closed and the full exponential backoff has occurred. (tcp_timer_persist) (3) TCP retransmit timer reaches its full exponntial backoff without being ACK'd. (tcp_timer_rexmt) There are a few ways to go about this -- probably the easiest is to drop a kernel printf just before each call to tcp_drop(tp, ETIMEDOUT) in tcp_timer.c. It would also be useful, if possible, to look at the tcpdump for the last portion of the connection, perhaps ideally from the second-to-last ACK from the remote host to the connection reset from the local end. It might be worth running tcpdump on both sides to see if they see the same thing -- for example, does one side think it's sending ACKs and the other not receive it? In the previous thread, it looked a bit like the outcome was that there was a memory exhaustion issue under load, and that bumping nmbclusters helped at least defer that problem. So it would be useful to see the output of netstat -m before and after (for as small an epsilon as you can make it) the connection is timed out. I realize capturing the above sorts of data can be an issue on high-load boxes but if we can, it would be quite helpful. Regardless of that, knowing if you're seeing allocation errors in the netstat -m output would be helpful. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-net@FreeBSD.ORG Mon Feb 2 19:20:05 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E85581065773 for ; Mon, 2 Feb 2009 19:20:05 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id CF93A8FC2A for ; Mon, 2 Feb 2009 19:20:05 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n12JK5it069728 for ; Mon, 2 Feb 2009 19:20:05 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n12JK5BY069727; Mon, 2 Feb 2009 19:20:05 GMT (envelope-from gnats) Date: Mon, 2 Feb 2009 19:20:05 GMT Message-Id: <200902021920.n12JK5BY069727@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Dan Nelson Cc: Subject: Re: kern/129719: Panic during shutdown, tcp_ctloutput: inp == NULL X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Dan Nelson List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2009 19:20:07 -0000 The following reply was made to PR kern/129719; it has been noted by GNATS. From: Dan Nelson To: FreeBSD-gnats-submit@FreeBSD.org Cc: Subject: Re: kern/129719: Panic during shutdown, tcp_ctloutput: inp == NULL Date: Mon, 2 Feb 2009 12:56:15 -0600 Here is a listing of all the thread stacks from the crashdump: GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"... Unread portion of the kernel message buffer: <118>Dec 17 11:20:57 filesrv init: /bin/sh on /etc/rc.shutdown terminated abnormally, going to single user mode <118>Dec 17 11:20:57 filesrv syslogd: exiting on signal 15 Fatal trap 12: page fault while in kernel mode cpuid = 3; apic id = 07 fault virtual address = 0xac fault code = supervisor write, page not present instruction pointer = 0x20:0xc07f58fd stack pointer = 0x28:0xef7fb908 frame pointer = 0x28:0xef7fba1c code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 3221 (nfsiod 0) trap number = 12 panic: page fault cpuid = 3 KDB: stack backtrace: db_trace_self_wrapper(c098f9a8,ef7fb7a4,c06bd4a7,c09ac250,3,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c09ac250,3,c095d6a2,ef7fb7b0,3,...) at kdb_backtrace+0x29 panic(c095d6a2,c09ad488,c5766794,1,1,...) at panic+0x114 trap_fatal(c0a5aec0,0,2,8,0,...) at trap_fatal+0x32e trap_pfault(0,0,c1060018,c1060014,c,...) at trap_pfault+0x244 trap(ef7fb8c8) at trap+0x3af calltrap() at calltrap+0x6 --- trap 0xc, eip = 0xc07f58fd, esp = 0xef7fb908, ebp = 0xef7fba1c --- tcp_ctloutput(c71a0680,ef7fbac8,4,4,58,...) at tcp_ctloutput+0x21 sosetopt(c71a0680,ef7fbac8,58,c099dedd,1f4,...) at sosetopt+0x666 nfs_connect(c54e4d20,c6208000,0,c0a11384,100,...) at nfs_connect+0x6c4 nfs_reconnect(c6208000,c6208044,153,c099e71c,0,...) at nfs_reconnect+0x16f nfs_request(c81e0228,c56f4000,7,0,c6f46b00,...) at nfs_request+0x831 nfs_writerpc(c81e0228,ef7fbc84,c6f46b00,ef7fbca8,ef7fbca4,...) at nfs_writerpc+0x2ea nfs_doio(c81e0228,d8e7e074,c6f46b00,0,dbba0,...) at nfs_doio+0x616 nfssvc_iod(c0a6e220,ef7fbd38,0,0,80eb7a0,...) at nfssvc_iod+0x2b9 fork_exit(c084192c,c0a6e220,ef7fbd38) at fork_exit+0x99 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xef7fbd70, ebp = 0 --- Uptime: 28d0h22m4s Physical memory: 2039 MB Dumping 280 MB: 265 249 233 217 201 185 169 153 137 121 105 89 73 57 41 25 9 Reading symbols from /boot/modules/cpu.ko...done. Loaded symbols for /boot/modules/cpu.ko Reading symbols from /boot/kernel/matrix_saver.ko...Reading symbols from /boot/kernel/matrix_saver.ko.symbols...done. done. Loaded symbols for /boot/kernel/matrix_saver.ko #0 doadump () at pcpu.h:196 in pcpu.h (kgdb) (kgdb) 127 Thread 100250 (PID=21895: sh) sched_switch (td=0xc5140d20, newtd=) at ../../../kern/sched_ule.c:1944 126 Thread 100127 (PID=21894: sh) sched_switch (td=0xc545ad20, newtd=) at ../../../kern/sched_ule.c:1944 125 Thread 100360 (PID=21517: perl) sched_switch (td=0xcb40b690, newtd=) at ../../../kern/sched_ule.c:1944 124 Thread 100176 (PID=21516: perl) sched_switch (td=0xc5702d20, newtd=) at ../../../kern/sched_ule.c:1944 123 Thread 100266 (PID=21515: perl) sched_switch (td=0xc74b0230, newtd=) at ../../../kern/sched_ule.c:1944 122 Thread 100103 (PID=21514: perl) sched_switch (td=0xc5137690, newtd=) at ../../../kern/sched_ule.c:1944 121 Thread 100210 (PID=21448: sh) sched_switch (td=0xc5853d20, newtd=) at ../../../kern/sched_ule.c:1944 120 Thread 100232 (PID=20926: fsync) sched_switch (td=0xc5ba9690, newtd=) at ../../../kern/sched_ule.c:1944 119 Thread 100332 (PID=20925: sh) sched_switch (td=0xc5500000, newtd=) at ../../../kern/sched_ule.c:1944 118 Thread 100311 (PID=20738: sh) sched_switch (td=0xc5063230, newtd=) at ../../../kern/sched_ule.c:1944 117 Thread 100170 (PID=71671: nfsiod 2) sched_switch (td=0xc531e460, newtd=) at ../../../kern/sched_ule.c:1944 116 Thread 100343 (PID=82757: zsh) sched_switch (td=0xcba8e000, newtd=) at ../../../kern/sched_ule.c:1944 115 Thread 100299 (PID=71900: joe) sched_switch (td=0xc5d3caf0, newtd=) at ../../../kern/sched_ule.c:1944 114 Thread 100224 (PID=4122: pike) sched_switch (td=0xc5bac8c0, newtd=) at ../../../kern/sched_ule.c:1944 113 Thread 100366 (PID=4122: pike) sched_switch (td=0xcadd6d20, newtd=) at ../../../kern/sched_ule.c:1944 112 Thread 100364 (PID=4122: pike) sched_switch (td=0xc729c8c0, newtd=) at ../../../kern/sched_ule.c:1944 111 Thread 100214 (PID=4122: pike) sched_switch (td=0xc5853460, newtd=) at ../../../kern/sched_ule.c:1944 110 Thread 100289 (PID=66015: joe) sched_switch (td=0xc5511d20, newtd=) at ../../../kern/sched_ule.c:1944 109 Thread 100280 (PID=49750: zsh) sched_switch (td=0xc5d3e000, newtd=) at ../../../kern/sched_ule.c:1944 108 Thread 100268 (PID=4751: zsh) sched_switch (td=0xc74afd20, newtd=) at ../../../kern/sched_ule.c:1944 107 Thread 100324 (PID=4221: zsh) sched_switch (td=0xc692caf0, newtd=) at ../../../kern/sched_ule.c:1944 106 Thread 100086 (PID=4215: screen) sched_switch (td=0xc5137d20, newtd=) at ../../../kern/sched_ule.c:1944 105 Thread 100097 (PID=23084: named) sched_switch (td=0xc692c8c0, newtd=) at ../../../kern/sched_ule.c:1944 104 Thread 100096 (PID=23084: named) sched_switch (td=0xc5502690, newtd=) at ../../../kern/sched_ule.c:1944 103 Thread 100095 (PID=23084: named) sched_switch (td=0xc692c690, newtd=) at ../../../kern/sched_ule.c:1944 102 Thread 100094 (PID=23084: named) sched_switch (td=0xc692c460, newtd=) at ../../../kern/sched_ule.c:1944 101 Thread 100093 (PID=23084: named) sched_switch (td=0xc692bd20, newtd=) at ../../../kern/sched_ule.c:1944 100 Thread 100092 (PID=23084: named) sched_switch (td=0xc692baf0, newtd=) at ../../../kern/sched_ule.c:1944 99 Thread 100047 (PID=23084: named) sched_switch (td=0xc50edd20, newtd=) at ../../../kern/sched_ule.c:1944 98 Thread 100195 (PID=3226: nfsiod 1) sched_switch (td=0xc5b748c0, newtd=) at ../../../kern/sched_ule.c:1944 * 97 Thread 100151 (PID=3221: nfsiod 0) doadump () at pcpu.h:196 96 Thread 100051 (PID=1818: roxen_mysql) sched_switch (td=0xcba8e460, newtd=) at ../../../kern/sched_ule.c:1944 95 Thread 100087 (PID=1818: roxen_mysql) sched_switch (td=0xc77a68c0, newtd=) at ../../../kern/sched_ule.c:1944 94 Thread 100205 (PID=1818: roxen_mysql) sched_switch (td=0xc5854230, newtd=) at ../../../kern/sched_ule.c:1944 93 Thread 100118 (PID=1818: roxen_mysql) sched_switch (td=0xc54e1230, newtd=) at ../../../kern/sched_ule.c:1944 92 Thread 100084 (PID=1702: moused) sched_switch (td=0xc5321af0, newtd=) at ../../../kern/sched_ule.c:1944 91 Thread 100074 (PID=1523: sendmail) sched_switch (td=0xc512b460, newtd=) at ../../../kern/sched_ule.c:1944 90 Thread 100122 (PID=1513: sendmail) sched_switch (td=0xc54e08c0, newtd=) at ../../../kern/sched_ule.c:1944 89 Thread 100050 (PID=1467: rpc.ypxfrd) sched_switch (td=0xc50ed8c0, newtd=) at ../../../kern/sched_ule.c:1944 88 Thread 100157 (PID=1457: cdpd) sched_switch (td=0xc5846af0, newtd=) at ../../../kern/sched_ule.c:1944 87 Thread 100065 (PID=1384: perl) sched_switch (td=0xc512c8c0, newtd=) at ../../../kern/sched_ule.c:1944 86 Thread 100102 (PID=1357: perl) sched_switch (td=0xc531e8c0, newtd=) at ../../../kern/sched_ule.c:1944 85 Thread 100138 (PID=1352: mysqld) fork_trampoline () at ../../../i386/i386/exception.s:261 84 Thread 100208 (PID=1352: mysqld) sched_switch (td=0xc50faaf0, newtd=) at ../../../kern/sched_ule.c:1944 83 Thread 100365 (PID=1352: mysqld) sched_switch (td=0xc81b08c0, newtd=) at ../../../kern/sched_ule.c:1944 82 Thread 100368 (PID=1352: mysqld) sched_switch (td=0xc7cd3af0, newtd=) at ../../../kern/sched_ule.c:1944 81 Thread 100363 (PID=1352: mysqld) sched_switch (td=0xcadc6af0, newtd=) at ../../../kern/sched_ule.c:1944 80 Thread 100169 (PID=1352: mysqld) sched_switch (td=0xc5854460, newtd=) at ../../../kern/sched_ule.c:1944 79 Thread 100166 (PID=1352: mysqld) sched_switch (td=0xc5854690, newtd=) at ../../../kern/sched_ule.c:1944 78 Thread 100168 (PID=1352: mysqld) sched_switch (td=0xc58548c0, newtd=) at ../../../kern/sched_ule.c:1944 77 Thread 100167 (PID=1352: mysqld) sched_switch (td=0xc5854af0, newtd=) at ../../../kern/sched_ule.c:1944 76 Thread 100165 (PID=1352: mysqld) sched_switch (td=0xc5855000, newtd=) at ../../../kern/sched_ule.c:1944 75 Thread 100164 (PID=1352: mysqld) sched_switch (td=0xc5855230, newtd=) at ../../../kern/sched_ule.c:1944 74 Thread 100163 (PID=1352: mysqld) sched_switch (td=0xc5137000, newtd=) at ../../../kern/sched_ule.c:1944 73 Thread 100162 (PID=1352: mysqld) sched_switch (td=0xc5137230, newtd=) at ../../../kern/sched_ule.c:1944 72 Thread 100068 (PID=1352: mysqld) sched_switch (td=0xc512c230, newtd=) at ../../../kern/sched_ule.c:1944 71 Thread 100124 (PID=1204: sh) sched_switch (td=0xc54e0460, newtd=) at ../../../kern/sched_ule.c:1944 70 Thread 100128 (PID=1189: rpc.rquotad) sched_switch (td=0xc545aaf0, newtd=) at ../../../kern/sched_ule.c:1944 69 Thread 100115 (PID=1099: lpd) sched_switch (td=0xc5458000, newtd=) at ../../../kern/sched_ule.c:1944 68 Thread 100053 (PID=1062: snmpd) sched_switch (td=0xc50ed230, newtd=) at ../../../kern/sched_ule.c:1944 67 Thread 100099 (PID=1038: sshd) sched_switch (td=0xc5321000, newtd=) at ../../../kern/sched_ule.c:1944 66 Thread 100119 (PID=1024: rpc.lockd) sched_switch (td=0xc54e1000, newtd=) at ../../../kern/sched_ule.c:1944 65 Thread 100114 (PID=1008: nfsd) sched_switch (td=0xc5458230, newtd=) at ../../../kern/sched_ule.c:1944 64 Thread 100049 (PID=1007: nfsd) sched_switch (td=0xc4e62af0, newtd=) at ../../../kern/sched_ule.c:1944 63 Thread 100112 (PID=1006: nfsd) sched_switch (td=0xc5458690, newtd=) at ../../../kern/sched_ule.c:1944 62 Thread 100111 (PID=1005: nfsd) sched_switch (td=0xc54588c0, newtd=) at ../../../kern/sched_ule.c:1944 61 Thread 100110 (PID=1004: nfsd) sched_switch (td=0xc5458af0, newtd=) at ../../../kern/sched_ule.c:1944 60 Thread 100107 (PID=1002: nfsd) sched_switch (td=0xc5459000, newtd=) at ../../../kern/sched_ule.c:1944 59 Thread 100077 (PID=1001: nfsd) sched_switch (td=0xc5250460, newtd=) at ../../../kern/sched_ule.c:1944 58 Thread 100105 (PID=1000: nfsd) sched_switch (td=0xc5459460, newtd=) at ../../../kern/sched_ule.c:1944 57 Thread 100057 (PID=999: nfsd) sched_switch (td=0xc512cd20, newtd=) at ../../../kern/sched_ule.c:1944 56 Thread 100069 (PID=989: mountd) sched_switch (td=0xc512c000, newtd=) at ../../../kern/sched_ule.c:1944 55 Thread 100098 (PID=952: amd) sched_switch (td=0xc51378c0, newtd=) at ../../../kern/sched_ule.c:1944 54 Thread 100071 (PID=930: ypserv) sched_switch (td=0xc512baf0, newtd=) at ../../../kern/sched_ule.c:1944 53 Thread 100058 (PID=914: rpcbind) sched_switch (td=0xc5063d20, newtd=) at ../../../kern/sched_ule.c:1944 52 Thread 100055 (PID=816: syslogd) sched_switch (td=0xc4e628c0, newtd=) at ../../../kern/sched_ule.c:1944 51 Thread 100070 (PID=783: accounting) sched_switch (td=0xc512bd20, newtd=) at ../../../kern/sched_ule.c:1944 50 Thread 100054 (PID=762: md0) sched_switch (td=0xc50ed000, newtd=) at ../../../kern/sched_ule.c:1944 49 Thread 100062 (PID=686: devd) sched_switch (td=0xc5140000, newtd=) at ../../../kern/sched_ule.c:1944 48 Thread 100046 (PID=47: softdepflush) sched_switch (td=0xc4e62d20, newtd=) at ../../../kern/sched_ule.c:1944 47 Thread 100045 (PID=46: vnlru) sched_switch (td=0xc5062000, newtd=) at ../../../kern/sched_ule.c:1944 46 Thread 100044 (PID=45: syncer) sched_switch (td=0xc5062230, newtd=) at ../../../kern/sched_ule.c:1944 45 Thread 100043 (PID=44: bufdaemon) sched_switch (td=0xc5062460, newtd=) at ../../../kern/sched_ule.c:1944 44 Thread 100042 (PID=43: pagezero) sched_switch (td=0xc5062690, newtd=) at ../../../kern/sched_ule.c:1944 43 Thread 100041 (PID=42: vmdaemon) sched_switch (td=0xc50628c0, newtd=) at ../../../kern/sched_ule.c:1944 42 Thread 100040 (PID=41: pagedaemon) sched_switch (td=0xc5062af0, newtd=) at ../../../kern/sched_ule.c:1944 41 Thread 100039 (PID=40: ipmi0: kcs) sched_switch (td=0xc5062d20, newtd=) at ../../../kern/sched_ule.c:1944 40 Thread 100038 (PID=39: sctp_iterator) sched_switch (td=0xc5063000, newtd=) at ../../../kern/sched_ule.c:1944 39 Thread 100037 (PID=38: swi0: sio) fork_trampoline () at ../../../i386/i386/exception.s:261 38 Thread 100036 (PID=37: irq12: psm0) sched_switch (td=0xc4e61000, newtd=) at ../../../kern/sched_ule.c:1944 37 Thread 100035 (PID=36: irq1: atkbd0) sched_switch (td=0xc4e61230, newtd=) at ../../../kern/sched_ule.c:1944 36 Thread 100034 (PID=35: fdc0) sched_switch (td=0xc4e61460, newtd=) at ../../../kern/sched_ule.c:1944 35 Thread 100033 (PID=34: irq17: bge1) fork_trampoline () at ../../../i386/i386/exception.s:261 34 Thread 100032 (PID=33: irq16: bge0) fork_trampoline () at ../../../i386/i386/exception.s:261 33 Thread 100031 (PID=32: em0 taskq) sched_switch (td=0xc4e61af0, newtd=) at ../../../kern/sched_ule.c:1944 32 Thread 100030 (PID=31: irq18: amr0) sched_switch (td=0xc4e61d20, newtd=) at ../../../kern/sched_ule.c:1944 31 Thread 100029 (PID=30: usbtask-dr) sched_switch (td=0xc4e62000, newtd=) at ../../../kern/sched_ule.c:1944 30 Thread 100028 (PID=29: usbtask-hc) sched_switch (td=0xc4e62230, newtd=) at ../../../kern/sched_ule.c:1944 29 Thread 100027 (PID=28: usb0) sched_switch (td=0xc4e62460, newtd=) at ../../../kern/sched_ule.c:1944 28 Thread 100026 (PID=27: irq11: ohci0) fork_trampoline () at ../../../i386/i386/exception.s:261 27 Thread 100025 (PID=26: irq15: ata1) sched_switch (td=0xc4d798c0, newtd=) at ../../../kern/sched_ule.c:1944 26 Thread 100024 (PID=25: irq14: ata0) fork_trampoline () at ../../../i386/i386/exception.s:261 25 Thread 100023 (PID=24: irq9: acpi0) fork_trampoline () at ../../../i386/i386/exception.s:261 24 Thread 100022 (PID=23: thread taskq) sched_switch (td=0xc4e0d000, newtd=) at ../../../kern/sched_ule.c:1944 23 Thread 100021 (PID=22: swi5: +) sched_switch (td=0xc4e0d230, newtd=) at ../../../kern/sched_ule.c:1944 22 Thread 100020 (PID=9: kqueue taskq) sched_switch (td=0xc4e0d460, newtd=) at ../../../kern/sched_ule.c:1944 21 Thread 100019 (PID=21: swi2: cambio) sched_switch (td=0xc4e0d690, newtd=) at ../../../kern/sched_ule.c:1944 20 Thread 100018 (PID=8: xpt_thrd) sched_switch (td=0xc4e0d8c0, newtd=) at ../../../kern/sched_ule.c:1944 19 Thread 100017 (PID=7: acpi_task_2) sched_switch (td=0xc4e0daf0, newtd=) at ../../../kern/sched_ule.c:1944 18 Thread 100016 (PID=6: acpi_task_1) sched_switch (td=0xc4d35230, newtd=) at ../../../kern/sched_ule.c:1944 17 Thread 100015 (PID=5: acpi_task_0) sched_switch (td=0xc4d35460, newtd=) at ../../../kern/sched_ule.c:1944 16 Thread 100014 (PID=20: swi6: task queue) sched_switch (td=0xc4d35690, newtd=) at ../../../kern/sched_ule.c:1944 15 Thread 100013 (PID=19: swi6: Giant taskq) sched_switch (td=0xc4d358c0, newtd=) at ../../../kern/sched_ule.c:1944 14 Thread 100012 (PID=18: yarrow) sched_switch (td=0xc4d35af0, newtd=) at ../../../kern/sched_ule.c:1944 13 Thread 100011 (PID=4: g_down) sched_switch (td=0xc4d35d20, newtd=) at ../../../kern/sched_ule.c:1944 12 Thread 100010 (PID=3: g_up) sched_switch (td=0xc4d79000, newtd=) at ../../../kern/sched_ule.c:1944 11 Thread 100009 (PID=2: g_event) sched_switch (td=0xc4d79230, newtd=) at ../../../kern/sched_ule.c:1944 10 Thread 100008 (PID=17: swi3: vm) fork_trampoline () at ../../../i386/i386/exception.s:261 9 Thread 100007 (PID=16: swi4: clock sio) sched_switch (td=0xc4d33000, newtd=) at ../../../kern/sched_ule.c:1944 8 Thread 100006 (PID=15: swi1: net) sched_switch (td=0xc4d33230, newtd=) at ../../../kern/sched_ule.c:1944 7 Thread 100005 (PID=14: idle: cpu0) sched_switch (td=0xc4d33460, newtd=) at ../../../kern/sched_ule.c:1944 6 Thread 100004 (PID=13: idle: cpu1) sched_switch (td=0xc4d33690, newtd=) at ../../../kern/sched_ule.c:1944 5 Thread 100003 (PID=12: idle: cpu2) sched_switch (td=0xc4d338c0, newtd=) at ../../../kern/sched_ule.c:1944 4 Thread 100002 (PID=11: idle: cpu3) sched_switch (td=0xc4d33bac, newtd=) at ../../../kern/sched_ule.c:1944 3 Thread 100001 (PID=1: init) sched_switch (td=0xc4d33d20, newtd=) at ../../../kern/sched_ule.c:1944 2 Thread 100000 (PID=10: audit) sched_switch (td=0xc4d35000, newtd=) at ../../../kern/sched_ule.c:1944 1 Thread 0 (PID=0: swapper) sched_switch (td=0xc0a5acc0, newtd=) at ../../../kern/sched_ule.c:1944 (kgdb) [Switching to thread 127 (Thread 100250)] #0 sched_switch (td=0xc5140d20, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc5140d20, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06eda87 in sleepq_wait (wchan=0xc0a5c8e8) at ../../../kern/subr_sleepqueue.c:580 #4 0xc06c47bd in _sx_xlock_hard (sx=0xc0a5c8e8, tid=3306425632, opts=0, file=0x0, line=0) at ../../../kern/kern_sx.c:560 #5 0xc0698e86 in exit1 (td=0xc5140d20, rv=15) at sx.h:153 #6 0xc06bf779 in sigexit (td=0xc5140d20, sig=15) at ../../../kern/kern_sig.c:2882 #7 0xc06bf96c in postsig (sig=15) at ../../../kern/kern_sig.c:2754 #8 0xc06f0023 in ast (framep=0xef976d38) at ../../../kern/subr_trap.c:252 #9 0xc090534d in doreti_ast () at ../../../i386/i386/exception.s:349 #10 0xef976d38 in ?? () #11 0x0000003b in ?? () #12 0x0000003b in ?? () #13 0x0000003b in ?? () #14 0xbfbfebc8 in ?? () #15 0xbfbfead8 in ?? () #16 0xbfbfea98 in ?? () #17 0xef976d64 in ?? () #18 0x00000001 in ?? () #19 0x0818e080 in ?? () #20 0x0818e080 in ?? () #21 0x00000007 in ?? () #22 0x0000000c in ?? () #23 0x00000002 in ?? () #24 0x08081869 in ?? () #25 0x00000033 in ?? () #26 0x00000282 in ?? () #27 0xbfbfea7c in ?? () #28 0x0000003b in ?? () #29 0x080a7d90 in ?? () #30 0x00000004 in ?? () #31 0x080b8368 in ?? () #32 0x00000000 in ?? () #33 0x00c1e000 in ?? () #34 0xc0a66c84 in sleepq_chains () #35 0xc5140f1c in ?? () #36 0xef976a40 in ?? () #37 0xef976a04 in ?? () #38 0xc5140d20 in ?? () #39 0xc06dbb29 in sched_switch (td=) at ../../../kern/sched_ule.c:1938 (kgdb) [Switching to thread 126 (Thread 100127)] #0 sched_switch (td=0xc545ad20, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc545ad20, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06eda87 in sleepq_wait (wchan=0xc0a5c8e8) at ../../../kern/subr_sleepqueue.c:580 #4 0xc06c47bd in _sx_xlock_hard (sx=0xc0a5c8e8, tid=3309677856, opts=0, file=0x0, line=0) at ../../../kern/kern_sx.c:560 #5 0xc0698e86 in exit1 (td=0xc545ad20, rv=15) at sx.h:153 #6 0xc06bf779 in sigexit (td=0xc545ad20, sig=15) at ../../../kern/kern_sig.c:2882 #7 0xc06bf96c in postsig (sig=15) at ../../../kern/kern_sig.c:2754 #8 0xc06f0023 in ast (framep=0xef7b3d38) at ../../../kern/subr_trap.c:252 #9 0xc090534d in doreti_ast () at ../../../i386/i386/exception.s:349 #10 0xef7b3d38 in ?? () #11 0x0000003b in ?? () #12 0x0000003b in ?? () #13 0x0000003b in ?? () #14 0xbfbfdec8 in ?? () #15 0xbfbfddd8 in ?? () #16 0xbfbfdd98 in ?? () #17 0xef7b3d64 in ?? () #18 0x00000001 in ?? () #19 0x081a7080 in ?? () #20 0x081a7080 in ?? () #21 0x00000007 in ?? () #22 0x0000000c in ?? () #23 0x00000002 in ?? () #24 0x08081869 in ?? () #25 0x00000033 in ?? () #26 0x00000282 in ?? () #27 0xbfbfdd7c in ?? () #28 0x0000003b in ?? () #29 0x00000000 in ?? () #30 0x00000000 in ?? () #31 0x00000000 in ?? () #32 0x00000000 in ?? () #33 0x00c1e000 in ?? () #34 0xc0a66c84 in sleepq_chains () #35 0xc545af1c in ?? () #36 0xef7b3a40 in ?? () #37 0xef7b3a04 in ?? () #38 0xc545ad20 in ?? () #39 0xc06dbb29 in sched_switch (td=) at ../../../kern/sched_ule.c:1938 (kgdb) [Switching to thread 125 (Thread 100360)] #0 sched_switch (td=0xcb40b690, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xcb40b690, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06eda87 in sleepq_wait (wchan=0xd8f06658) at ../../../kern/subr_sleepqueue.c:580 #4 0xc06c5316 in _sleep (ident=0xd8f06658, lock=0xc0a68678, priority=76, wmesg=0xc09926ef "biord", timo=0) at ../../../kern/kern_synch.c:226 #5 0xc071fc31 in bwait (bp=0xd8f06658, pri=76 'L', wchan=0xc09926ef "biord") at ../../../kern/vfs_bio.c:3802 #6 0xc071fca8 in bufwait (bp=0xd8f06658) at ../../../kern/vfs_bio.c:3057 #7 0xc0726f54 in breadn (vp=0xc679d9b4, blkno=0, size=2048, rablkno=0x0, rabsize=0x0, cnt=0, cred=0x0, bpp=0xefaf99e8) at ../../../kern/vfs_bio.c:806 #8 0xc0726fd0 in bread (vp=0xc679d9b4, blkno=) at ../../../kern/vfs_bio.c:734 #9 0xc08a2c33 in ffs_blkatoff (vp=0xc679d9b4, offset=0, res=0x0, bpp=0xefaf9a88) at ../../../ufs/ffs/ffs_subr.c:87 #10 0xc08af380 in ufs_lookup (ap=0xefaf9ac0) at ../../../ufs/ufs/ufs_lookup.c:269 #11 0xc0930482 in VOP_CACHEDLOOKUP_APV (vop=0xc0a2aa00, a=0xefaf9ac0) at vnode_if.c:153 #12 0xc0728569 in vfs_cache_lookup (ap=0xefaf9b40) at vnode_if.h:83 #13 0xc0931ed1 in VOP_LOOKUP_APV (vop=0xc0a2af20, a=0xefaf9b40) at vnode_if.c:99 #14 0xc072ea95 in lookup (ndp=0xefaf9c10) at vnode_if.h:57 #15 0xc072f794 in namei (ndp=0xefaf9c10) at ../../../kern/vfs_lookup.c:219 #16 0xc073fa82 in kern_unlink (td=0xcb40b690, path=0x87c5a18
, pathseg=UIO_USERSPACE) at ../../../kern/vfs_syscalls.c:1670 #17 0xc073fca9 in unlink (td=0xcb40b690, uap=0xefaf9cfc) at ../../../kern/vfs_syscalls.c:1653 #18 0xc091d0a5 in syscall (frame=0xefaf9d38) at ../../../i386/i386/trap.c:1090 #19 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #20 0x00000033 in ?? () (kgdb) [Switching to thread 124 (Thread 100176)] #0 sched_switch (td=0xc5702d20, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc5702d20, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06eda87 in sleepq_wait (wchan=0xc679da0c) at ../../../kern/subr_sleepqueue.c:580 #4 0xc06c5316 in _sleep (ident=0xc679da0c, lock=0xc0a5be28, priority=80, wmesg=0xc09896b6 "ufs", timo=0) at ../../../kern/kern_synch.c:226 #5 0xc06a9ab0 in acquire (lkpp=0xef86399c, extflags=) at ../../../kern/kern_lock.c:151 #6 0xc06aa33a in _lockmgr (lkp=0xc679da0c, flags=8194, interlkp=0xc679da3c, td=0xc5702d20, file=0xc0994187 "../../../kern/vfs_subr.c", line=2061) at ../../../kern/kern_lock.c:384 #7 0xc08a8fec in ffs_lock (ap=0xef863a04) at ../../../ufs/ffs/ffs_vnops.c:377 #8 0xc0931811 in VOP_LOCK1_APV (vop=0xc0a2aa00, a=0xef863a04) at vnode_if.c:1618 #9 0xc074646a in _vn_lock (vp=0xc679d9b4, flags=8194, td=0xc5702d20, file=0xc0994187 "../../../kern/vfs_subr.c", line=2061) at vnode_if.h:851 #10 0xc0739b5e in vget (vp=0xc679d9b4, flags=8194, td=0xc5702d20) at ../../../kern/vfs_subr.c:2061 #11 0xc072843b in cache_lookup (dvp=0xc51259b4, vpp=0xef863c24, cnp=0xef863c38) at ../../../kern/vfs_cache.c:442 #12 0xc0728540 in vfs_cache_lookup (ap=0xef863b40) at ../../../kern/vfs_cache.c:667 #13 0xc0931ed1 in VOP_LOOKUP_APV (vop=0xc0a2af20, a=0xef863b40) at vnode_if.c:99 #14 0xc072ea95 in lookup (ndp=0xef863c10) at vnode_if.h:57 #15 0xc072f794 in namei (ndp=0xef863c10) at ../../../kern/vfs_lookup.c:219 #16 0xc073fa82 in kern_unlink (td=0xc5702d20, path=0x87c5a18
, pathseg=UIO_USERSPACE) at ../../../kern/vfs_syscalls.c:1670 #17 0xc073fca9 in unlink (td=0xc5702d20, uap=0xef863cfc) at ../../../kern/vfs_syscalls.c:1653 #18 0xc091d0a5 in syscall (frame=0xef863d38) at ../../../i386/i386/trap.c:1090 #19 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #20 0x00000033 in ?? () (kgdb) [Switching to thread 123 (Thread 100266)] #0 sched_switch (td=0xc74b0230, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc74b0230, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06eda87 in sleepq_wait (wchan=0xc5125c34) at ../../../kern/subr_sleepqueue.c:580 #4 0xc06c5316 in _sleep (ident=0xc5125c34, lock=0xc0a5bf48, priority=80, wmesg=0xc09896b6 "ufs", timo=0) at ../../../kern/kern_synch.c:226 #5 0xc06a9ab0 in acquire (lkpp=0xef9a697c, extflags=) at ../../../kern/kern_lock.c:151 #6 0xc06aa33a in _lockmgr (lkp=0xc5125c34, flags=8194, interlkp=0xc5125c64, td=0xc74b0230, file=0xc0994187 "../../../kern/vfs_subr.c", line=2061) at ../../../kern/kern_lock.c:384 #7 0xc08a8fec in ffs_lock (ap=0xef9a69e4) at ../../../ufs/ffs/ffs_vnops.c:377 #8 0xc0931811 in VOP_LOCK1_APV (vop=0xc0a2aa00, a=0xef9a69e4) at vnode_if.c:1618 #9 0xc074646a in _vn_lock (vp=0xc5125bdc, flags=8194, td=0xc74b0230, file=0xc0994187 "../../../kern/vfs_subr.c", line=2061) at vnode_if.h:851 #10 0xc0739b5e in vget (vp=0xc5125bdc, flags=8194, td=0xc74b0230) at ../../../kern/vfs_subr.c:2061 #11 0xc072d89d in vfs_hash_get (mp=0xc50b5598, hash=2, flags=) at ../../../kern/vfs_hash.c:81 #12 0xc08a3add in ffs_vget (mp=0xc50b5598, ino=2, flags=2, vpp=0xef9a6af4) at ../../../ufs/ffs/ffs_vfsops.c:1307 #13 0xc08b39d8 in ufs_root (mp=0xc50b5598, flags=2, vpp=0xef9a6b50, td=0xc74b0230) at ../../../ufs/ufs/ufs_vfsops.c:78 #14 0xc072eea0 in lookup (ndp=0xef9a6c10) at ../../../kern/vfs_lookup.c:679 #15 0xc072f794 in namei (ndp=0xef9a6c10) at ../../../kern/vfs_lookup.c:219 #16 0xc073fa82 in kern_unlink (td=0xc74b0230, path=0x87c5a18
, pathseg=UIO_USERSPACE) at ../../../kern/vfs_syscalls.c:1670 #17 0xc073fca9 in unlink (td=0xc74b0230, uap=0xef9a6cfc) at ../../../kern/vfs_syscalls.c:1653 #18 0xc091d0a5 in syscall (frame=0xef9a6d38) at ../../../i386/i386/trap.c:1090 #19 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #20 0x00000033 in ?? () (kgdb) [Switching to thread 122 (Thread 100103)] #0 sched_switch (td=0xc5137690, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc5137690, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06eda87 in sleepq_wait (wchan=0xc5125c34) at ../../../kern/subr_sleepqueue.c:580 #4 0xc06c5316 in _sleep (ident=0xc5125c34, lock=0xc0a5bf48, priority=80, wmesg=0xc09896b6 "ufs", timo=0) at ../../../kern/kern_synch.c:226 #5 0xc06a9ab0 in acquire (lkpp=0xef75097c, extflags=) at ../../../kern/kern_lock.c:151 #6 0xc06aa33a in _lockmgr (lkp=0xc5125c34, flags=8194, interlkp=0xc5125c64, td=0xc5137690, file=0xc0994187 "../../../kern/vfs_subr.c", line=2061) at ../../../kern/kern_lock.c:384 #7 0xc08a8fec in ffs_lock (ap=0xef7509e4) at ../../../ufs/ffs/ffs_vnops.c:377 #8 0xc0931811 in VOP_LOCK1_APV (vop=0xc0a2aa00, a=0xef7509e4) at vnode_if.c:1618 #9 0xc074646a in _vn_lock (vp=0xc5125bdc, flags=8194, td=0xc5137690, file=0xc0994187 "../../../kern/vfs_subr.c", line=2061) at vnode_if.h:851 #10 0xc0739b5e in vget (vp=0xc5125bdc, flags=8194, td=0xc5137690) at ../../../kern/vfs_subr.c:2061 #11 0xc072d89d in vfs_hash_get (mp=0xc50b5598, hash=2, flags=) at ../../../kern/vfs_hash.c:81 #12 0xc08a3add in ffs_vget (mp=0xc50b5598, ino=2, flags=2, vpp=0xef750af4) at ../../../ufs/ffs/ffs_vfsops.c:1307 #13 0xc08b39d8 in ufs_root (mp=0xc50b5598, flags=2, vpp=0xef750b50, td=0xc5137690) at ../../../ufs/ufs/ufs_vfsops.c:78 #14 0xc072eea0 in lookup (ndp=0xef750c10) at ../../../kern/vfs_lookup.c:679 #15 0xc072f794 in namei (ndp=0xef750c10) at ../../../kern/vfs_lookup.c:219 #16 0xc073fa82 in kern_unlink (td=0xc5137690, path=0x87c5a18
, pathseg=UIO_USERSPACE) at ../../../kern/vfs_syscalls.c:1670 #17 0xc073fca9 in unlink (td=0xc5137690, uap=0xef750cfc) at ../../../kern/vfs_syscalls.c:1653 #18 0xc091d0a5 in syscall (frame=0xef750d38) at ../../../i386/i386/trap.c:1090 #19 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #20 0x00000033 in ?? () (kgdb) [Switching to thread 121 (Thread 100210)] #0 sched_switch (td=0xc5853d20, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc5853d20, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06eda87 in sleepq_wait (wchan=0xc0a5c8e8) at ../../../kern/subr_sleepqueue.c:580 #4 0xc06c47bd in _sx_xlock_hard (sx=0xc0a5c8e8, tid=3313843488, opts=0, file=0x0, line=0) at ../../../kern/kern_sx.c:560 #5 0xc0698e86 in exit1 (td=0xc5853d20, rv=15) at sx.h:153 #6 0xc06bf779 in sigexit (td=0xc5853d20, sig=15) at ../../../kern/kern_sig.c:2882 #7 0xc06bf96c in postsig (sig=15) at ../../../kern/kern_sig.c:2754 #8 0xc06f0023 in ast (framep=0xef8e3d38) at ../../../kern/subr_trap.c:252 #9 0xc090534d in doreti_ast () at ../../../i386/i386/exception.s:349 #10 0xef8e3d38 in ?? () #11 0x0000003b in ?? () #12 0x0000003b in ?? () #13 0x0000003b in ?? () #14 0x00000000 in ?? () #15 0xbfbfdcf8 in ?? () #16 0xbfbfdcb8 in ?? () #17 0xef8e3d64 in ?? () #18 0x00000001 in ?? () #19 0x0818b080 in ?? () #20 0x00000009 in ?? () #21 0x00000007 in ?? () #22 0x0000000c in ?? () #23 0x00000002 in ?? () #24 0x08081869 in ?? () #25 0x00000033 in ?? () #26 0x00000286 in ?? () #27 0xbfbfdc9c in ?? () #28 0x0000003b in ?? () #29 0x00000000 in ?? () #30 0x00000000 in ?? () #31 0x00000000 in ?? () #32 0x00000000 in ?? () #33 0x00c1e000 in ?? () #34 0xc0a66c84 in sleepq_chains () #35 0xc5853f1c in ?? () #36 0xef8e3a40 in ?? () #37 0xef8e3a04 in ?? () #38 0xc5853d20 in ?? () #39 0xc06dbb29 in sched_switch (td=) at ../../../kern/sched_ule.c:1938 (kgdb) [Switching to thread 120 (Thread 100232)] #0 sched_switch (td=0xc5ba9690, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc5ba9690, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06edf4e in sleepq_timedwait (wchan=0xc6f1b9fa) at ../../../kern/subr_sleepqueue.c:615 #4 0xc06c52f4 in _sleep (ident=0xc6f1b9fa, lock=0xc6f1ba34, priority=88, wmesg=0xc099dedd "nfscon", timo=500) at ../../../kern/kern_synch.c:222 #5 0xc083b776 in nfs_connect (nmp=0xc54e4d20, rep=0xc76b9980) at ../../../nfsclient/nfs_socket.c:371 #6 0xc083bf9a in nfs_reconnect (rep=0xc76b9980) at ../../../nfsclient/nfs_socket.c:542 #7 0xc083e6e5 in nfs_request (vp=0xc4f7e8a0, mrest=0xc539c000, procnum=1, td=0xc5ba9690, cred=0xc6f46b00, mrp=0xef940904, mdp=0xef940900, dposp=0xef940908) at ../../../nfsclient/nfs_socket.c:737 #8 0xc0846ecb in nfs_getattr (ap=0xef9409d8) at ../../../nfsclient/nfs_vnops.c:662 #9 0xc0930702 in VOP_GETATTR_APV (vop=0xc0a27aa0, a=0xef9409d8) at vnode_if.c:530 #10 0xc084a587 in nfs_lookup (ap=0xef940a84) at vnode_if.h:286 #11 0xc0931ed1 in VOP_LOOKUP_APV (vop=0xc0a27aa0, a=0xef940a84) at vnode_if.c:99 #12 0xc072ea95 in lookup (ndp=0xef940ba8) at vnode_if.h:57 #13 0xc072f794 in namei (ndp=0xef940ba8) at ../../../kern/vfs_lookup.c:219 #14 0xc073ce92 in kern_stat (td=0xc5ba9690, path=0x807914c
, pathseg=UIO_USERSPACE, sbp=0xef940c18) at ../../../kern/vfs_syscalls.c:2113 #15 0xc073d05f in stat (td=0xc5ba9690, uap=0xef940cfc) at ../../../kern/vfs_syscalls.c:2097 #16 0xc091d0a5 in syscall (frame=0xef940d38) at ../../../i386/i386/trap.c:1090 #17 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #18 0x00000033 in ?? () (kgdb) [Switching to thread 119 (Thread 100332)] #0 sched_switch (td=0xc5500000, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc5500000, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06eda87 in sleepq_wait (wchan=0xc0a5c8e8) at ../../../kern/subr_sleepqueue.c:580 #4 0xc06c47bd in _sx_xlock_hard (sx=0xc0a5c8e8, tid=3310354432, opts=0, file=0x0, line=0) at ../../../kern/kern_sx.c:560 #5 0xc0698e86 in exit1 (td=0xc5500000, rv=15) at sx.h:153 #6 0xc06bf779 in sigexit (td=0xc5500000, sig=15) at ../../../kern/kern_sig.c:2882 #7 0xc06bf96c in postsig (sig=15) at ../../../kern/kern_sig.c:2754 #8 0xc06f0023 in ast (framep=0xefaa5d38) at ../../../kern/subr_trap.c:252 #9 0xc090534d in doreti_ast () at ../../../i386/i386/exception.s:349 #10 0xefaa5d38 in ?? () #11 0x0000003b in ?? () #12 0x0000003b in ?? () #13 0x0000003b in ?? () #14 0xbfbfeab8 in ?? () #15 0xbfbfe9c8 in ?? () #16 0xbfbfe988 in ?? () #17 0xefaa5d64 in ?? () #18 0x00000001 in ?? () #19 0x0818b080 in ?? () #20 0x0818b080 in ?? () #21 0x00000007 in ?? () #22 0x0000000c in ?? () #23 0x00000002 in ?? () #24 0x08081869 in ?? () #25 0x00000033 in ?? () #26 0x00000282 in ?? () #27 0xbfbfe96c in ?? () #28 0x0000003b in ?? () #29 0x00000000 in ?? () #30 0x00000000 in ?? () #31 0x00000000 in ?? () #32 0x00000000 in ?? () #33 0x00c1e000 in ?? () #34 0xc0a66c84 in sleepq_chains () #35 0xc55001fc in ?? () #36 0xefaa5a40 in ?? () #37 0xefaa5a04 in ?? () #38 0xc5500000 in ?? () #39 0xc06dbb29 in sched_switch (td=) at ../../../kern/sched_ule.c:1938 (kgdb) [Switching to thread 118 (Thread 100311)] #0 sched_switch (td=0xc5063230, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc5063230, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06eda87 in sleepq_wait (wchan=0xc0a5c8e8) at ../../../kern/subr_sleepqueue.c:580 #4 0xc06c47bd in _sx_xlock_hard (sx=0xc0a5c8e8, tid=3305517616, opts=0, file=0x0, line=0) at ../../../kern/kern_sx.c:560 #5 0xc0698e86 in exit1 (td=0xc5063230, rv=15) at sx.h:153 #6 0xc06bf779 in sigexit (td=0xc5063230, sig=15) at ../../../kern/kern_sig.c:2882 #7 0xc06bf96c in postsig (sig=15) at ../../../kern/kern_sig.c:2754 #8 0xc06f0023 in ast (framep=0xefa49d38) at ../../../kern/subr_trap.c:252 #9 0xc090534d in doreti_ast () at ../../../i386/i386/exception.s:349 #10 0xefa49d38 in ?? () #11 0x0000003b in ?? () #12 0x0000003b in ?? () #13 0x0000003b in ?? () #14 0x00000000 in ?? () #15 0xbfbfebc8 in ?? () #16 0xbfbfeb88 in ?? () #17 0xefa49d64 in ?? () #18 0x00000001 in ?? () #19 0x0818b080 in ?? () #20 0x0818b080 in ?? () #21 0x00000007 in ?? () #22 0x0000000c in ?? () #23 0x00000002 in ?? () #24 0x08081869 in ?? () #25 0x00000033 in ?? () #26 0x00000282 in ?? () #27 0xbfbfeb6c in ?? () #28 0x0000003b in ?? () #29 0x00000000 in ?? () #30 0xbfbf9d60 in ?? () #31 0x00000000 in ?? () #32 0x080e03a8 in ?? () #33 0x00c1e000 in ?? () #34 0xc0a66c84 in sleepq_chains () #35 0xc506342c in ?? () #36 0xefa49a40 in ?? () #37 0xefa49a04 in ?? () #38 0xc5063230 in ?? () #39 0xc06dbb29 in sched_switch (td=) at ../../../kern/sched_ule.c:1938 (kgdb) [Switching to thread 117 (Thread 100170)] #0 sched_switch (td=0xc531e460, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc531e460, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06ed780 in sleepq_catch_signals (wchan=0xc0a6e8a8) at ../../../kern/subr_sleepqueue.c:417 #4 0xc06edeb6 in sleepq_timedwait_sig (wchan=0xc0a6e8a8) at ../../../kern/subr_sleepqueue.c:631 #5 0xc06c52e1 in _sleep (ident=0xc0a6e8a8, lock=0xc0a6e870, priority=348, wmesg=0xc098792e "-", timo=900000) at ../../../kern/kern_synch.c:220 #6 0xc0841a1a in nfssvc_iod (instance=0xc0a6e228) at ../../../nfsclient/nfs_nfsiod.c:244 #7 0xc069a351 in fork_exit (callout=0xc084192c , arg=0xc0a6e228, frame=0xef834d38) at ../../../kern/kern_fork.c:804 #8 0xc0904aa0 in fork_trampoline () at ../../../i386/i386/exception.s:264 (kgdb) [Switching to thread 116 (Thread 100343)] #0 sched_switch (td=0xcba8e000, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xcba8e000, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06ed780 in sleepq_catch_signals (wchan=0xc6e9e410) at ../../../kern/subr_sleepqueue.c:417 #4 0xc06edf92 in sleepq_wait_sig (wchan=0xc6e9e410) at ../../../kern/subr_sleepqueue.c:594 #5 0xc06c5307 in _sleep (ident=0xc6e9e410, lock=0x0, priority=345, wmesg=0xc09913ac "ttyin", timo=0) at ../../../kern/kern_synch.c:224 #6 0xc06fedb0 in ttysleep (tp=0xc6e9e400, chan=0xc6e9e410, pri=345, wmesg=0xc09913ac "ttyin", timo=0) at ../../../kern/tty.c:2822 #7 0xc0703292 in ttread (tp=0xc6e9e400, uio=0xefac6c60, flag=0) at ../../../kern/tty.c:1877 #8 0xc0706db3 in ptsread (dev=0xc619c900, uio=0xefac6c60, flag=0) at linedisc.h:100 #9 0xc06845ec in giant_read (dev=0xc619c900, uio=0xefac6c60, ioflag=0) at ../../../kern/kern_conf.c:424 #10 0xc064ce52 in devfs_read_f (fp=0xc83cc04c, uio=0xefac6c60, cred=0xc68b9000, flags=0, td=0xcba8e000) at ../../../fs/devfs/devfs_vnops.c:1000 #11 0xc06f358d in dofileread (td=0xcba8e000, fd=10, fp=0xc83cc04c, auio=0xefac6c60, offset=-1, flags=0) at file.h:244 #12 0xc06f389e in kern_readv (td=0xcba8e000, fd=10, auio=0xefac6c60) at ../../../kern/sys_generic.c:192 #13 0xc06f3968 in read (td=0xcba8e000, uap=0xefac6cfc) at ../../../kern/sys_generic.c:108 #14 0xc091d0a5 in syscall (frame=0xefac6d38) at ../../../i386/i386/trap.c:1090 #15 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #16 0x00000033 in ?? () (kgdb) [Switching to thread 115 (Thread 100299)] #0 sched_switch (td=0xc5d3caf0, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc5d3caf0, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06eda87 in sleepq_wait (wchan=0xd8fc0ea0) at ../../../kern/subr_sleepqueue.c:580 #4 0xc06c5316 in _sleep (ident=0xd8fc0ea0, lock=0xc0a68678, priority=76, wmesg=0xc09926ef "biord", timo=0) at ../../../kern/kern_synch.c:226 #5 0xc071fc31 in bwait (bp=0xd8fc0ea0, pri=76 'L', wchan=0xc09926ef "biord") at ../../../kern/vfs_bio.c:3802 #6 0xc071fca8 in bufwait (bp=0xd8fc0ea0) at ../../../kern/vfs_bio.c:3057 #7 0xc0726f54 in breadn (vp=0xca664ac8, blkno=3, size=12288, rablkno=0x0, rabsize=0x0, cnt=0, cred=0x0, bpp=0xefa25a50) at ../../../kern/vfs_bio.c:806 #8 0xc0726fd0 in bread (vp=0xca664ac8, blkno=) at ../../../kern/vfs_bio.c:734 #9 0xc088b956 in ffs_balloc_ufs2 (vp=0xca664ac8, startoffset=) at ../../../ufs/ffs/ffs_balloc.c:681 #10 0xc08a965c in ffs_write (ap=0xefa25bc4) at ../../../ufs/ffs/ffs_vnops.c:724 #11 0xc0931c50 in VOP_WRITE_APV (vop=0xc0a2aa00, a=0xefa25bc4) at vnode_if.c:691 #12 0xc07476bb in vn_write (fp=0xc5570e40, uio=0xefa25c60, active_cred=0xc68b5800, flags=0, td=0xc5d3caf0) at vnode_if.h:373 #13 0xc06f31e7 in dofilewrite (td=0xc5d3caf0, fd=3, fp=0xc5570e40, auio=0xefa25c60, offset=-1, flags=0) at file.h:256 #14 0xc06f3491 in kern_writev (td=0xc5d3caf0, fd=3, auio=0xefa25c60) at ../../../kern/sys_generic.c:401 #15 0xc06f34fb in write (td=0xc5d3caf0, uap=0xefa25cfc) at ../../../kern/sys_generic.c:317 #16 0xc091d0a5 in syscall (frame=0xefa25d38) at ../../../i386/i386/trap.c:1090 #17 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #18 0x00000033 in ?? () (kgdb) [Switching to thread 114 (Thread 100224)] #0 sched_switch (td=0xc5bac8c0, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc5bac8c0, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06ed780 in sleepq_catch_signals (wchan=0xc56ce540) at ../../../kern/subr_sleepqueue.c:417 #4 0xc06edf92 in sleepq_wait_sig (wchan=0xc56ce540) at ../../../kern/subr_sleepqueue.c:594 #5 0xc06c5307 in _sleep (ident=0xc56ce540, lock=0xc0a5e400, priority=256, wmesg=0xc098e57e "ucond", timo=0) at ../../../kern/kern_synch.c:224 #6 0xc06d392b in __umtx_op_cv_wait (td=0xc5bac8c0, uap=0xef934cfc) at ../../../kern/kern_umtx.c:482 #7 0xc06cec88 in _umtx_op (td=0xc5bac8c0, uap=0xef934cfc) at ../../../kern/kern_umtx.c:2926 #8 0xc091d0a5 in syscall (frame=0xef934d38) at ../../../i386/i386/trap.c:1090 #9 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #10 0x00000033 in ?? () (kgdb) [Switching to thread 113 (Thread 100366)] #0 sched_switch (td=0xcadd6d20, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xcadd6d20, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06ed780 in sleepq_catch_signals (wchan=0xc60dc4c0) at ../../../kern/subr_sleepqueue.c:417 #4 0xc06edf92 in sleepq_wait_sig (wchan=0xc60dc4c0) at ../../../kern/subr_sleepqueue.c:594 #5 0xc06c5307 in _sleep (ident=0xc60dc4c0, lock=0xc0a5d408, priority=256, wmesg=0xc098e57e "ucond", timo=0) at ../../../kern/kern_synch.c:224 #6 0xc06d392b in __umtx_op_cv_wait (td=0xcadd6d20, uap=0xefb0bcfc) at ../../../kern/kern_umtx.c:482 #7 0xc06cec88 in _umtx_op (td=0xcadd6d20, uap=0xefb0bcfc) at ../../../kern/kern_umtx.c:2926 #8 0xc091d0a5 in syscall (frame=0xefb0bd38) at ../../../i386/i386/trap.c:1090 #9 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #10 0x00000033 in ?? () (kgdb) [Switching to thread 112 (Thread 100364)] #0 sched_switch (td=0xc729c8c0, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc729c8c0, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06ed780 in sleepq_catch_signals (wchan=0xc7fa8000) at ../../../kern/subr_sleepqueue.c:417 #4 0xc06edf92 in sleepq_wait_sig (wchan=0xc7fa8000) at ../../../kern/subr_sleepqueue.c:594 #5 0xc06c5307 in _sleep (ident=0xc7fa8000, lock=0xc0a5db78, priority=256, wmesg=0xc098e57e "ucond", timo=0) at ../../../kern/kern_synch.c:224 #6 0xc06d392b in __umtx_op_cv_wait (td=0xc729c8c0, uap=0xefb05cfc) at ../../../kern/kern_umtx.c:482 #7 0xc06cec88 in _umtx_op (td=0xc729c8c0, uap=0xefb05cfc) at ../../../kern/kern_umtx.c:2926 #8 0xc091d0a5 in syscall (frame=0xefb05d38) at ../../../i386/i386/trap.c:1090 #9 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #10 0x00000033 in ?? () (kgdb) [Switching to thread 111 (Thread 100214)] #0 sched_switch (td=0xc5853460, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc5853460, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06ed780 in sleepq_catch_signals (wchan=0xc61bd200) at ../../../kern/subr_sleepqueue.c:417 #4 0xc06edeb6 in sleepq_timedwait_sig (wchan=0xc61bd200) at ../../../kern/subr_sleepqueue.c:631 #5 0xc06c52e1 in _sleep (ident=0xc61bd200, lock=0xc61bd200, priority=344, wmesg=0xc098b01a "kqread", timo=25) at ../../../kern/kern_synch.c:220 #6 0xc06934f7 in kern_kevent (td=0xc5853460, fd=4, nchanges=0, nevents=32, k_ops=0xef8efc40, timeout=0xef8efc4c) at ../../../kern/kern_event.c:1292 #7 0xc0693dd4 in kevent (td=0xc5853460, uap=0xef8efcfc) at ../../../kern/kern_event.c:646 #8 0xc091d0a5 in syscall (frame=0xef8efd38) at ../../../i386/i386/trap.c:1090 #9 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #10 0x00000033 in ?? () (kgdb) [Switching to thread 110 (Thread 100289)] #0 sched_switch (td=0xc5511d20, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc5511d20, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06eda87 in sleepq_wait (wchan=0xca664b20) at ../../../kern/subr_sleepqueue.c:580 #4 0xc06c5316 in _sleep (ident=0xca664b20, lock=0xc0a5c7d0, priority=80, wmesg=0xc09896b6 "ufs", timo=0) at ../../../kern/kern_synch.c:226 #5 0xc06a9ab0 in acquire (lkpp=0xefa07810, extflags=) at ../../../kern/kern_lock.c:151 #6 0xc06aa33a in _lockmgr (lkp=0xca664b20, flags=8194, interlkp=0xca664b50, td=0xc5511d20, file=0xc0994187 "../../../kern/vfs_subr.c", line=2061) at ../../../kern/kern_lock.c:384 #7 0xc08a8fec in ffs_lock (ap=0xefa07878) at ../../../ufs/ffs/ffs_vnops.c:377 #8 0xc0931811 in VOP_LOCK1_APV (vop=0xc0a2aa00, a=0xefa07878) at vnode_if.c:1618 #9 0xc074646a in _vn_lock (vp=0xca664ac8, flags=8194, td=0xc5511d20, file=0xc0994187 "../../../kern/vfs_subr.c", line=2061) at vnode_if.h:851 #10 0xc0739b5e in vget (vp=0xca664ac8, flags=8194, td=0xc5511d20) at ../../../kern/vfs_subr.c:2061 #11 0xc072843b in cache_lookup (dvp=0xc511fcf0, vpp=0xefa07b90, cnp=0xefa07ba4) at ../../../kern/vfs_cache.c:442 #12 0xc0728540 in vfs_cache_lookup (ap=0xefa079b4) at ../../../kern/vfs_cache.c:667 #13 0xc0931ed1 in VOP_LOOKUP_APV (vop=0xc0a2af20, a=0xefa079b4) at vnode_if.c:99 #14 0xc072ea95 in lookup (ndp=0xefa07b7c) at vnode_if.h:57 #15 0xc072f794 in namei (ndp=0xefa07b7c) at ../../../kern/vfs_lookup.c:219 #16 0xc07455d6 in vn_open_cred (ndp=0xefa07b7c, flagp=0xefa07c78, cmode=384, cred=0xc564a000, fp=0xc8088b94) at ../../../kern/vfs_vnops.c:130 #17 0xc0745b37 in vn_open (ndp=0xefa07b7c, flagp=0xefa07c78, cmode=384, fp=0xc8088b94) at ../../../kern/vfs_vnops.c:94 #18 0xc07438e6 in kern_open (td=0xc5511d20, path=0x808a86b
, pathseg=UIO_USERSPACE, flags=2563, mode=384) at ../../../kern/vfs_syscalls.c:1032 #19 0xc0743e42 in open (td=0xc5511d20, uap=0xefa07cfc) at ../../../kern/vfs_syscalls.c:999 #20 0xc091d0a5 in syscall (frame=0xefa07d38) at ../../../i386/i386/trap.c:1090 #21 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #22 0x00000033 in ?? () (kgdb) [Switching to thread 109 (Thread 100280)] #0 sched_switch (td=0xc5d3e000, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc5d3e000, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06ed780 in sleepq_catch_signals (wchan=0xc7ce3010) at ../../../kern/subr_sleepqueue.c:417 #4 0xc06edf92 in sleepq_wait_sig (wchan=0xc7ce3010) at ../../../kern/subr_sleepqueue.c:594 #5 0xc06c5307 in _sleep (ident=0xc7ce3010, lock=0x0, priority=345, wmesg=0xc09913ac "ttyin", timo=0) at ../../../kern/kern_synch.c:224 #6 0xc06fedb0 in ttysleep (tp=0xc7ce3000, chan=0xc7ce3010, pri=345, wmesg=0xc09913ac "ttyin", timo=0) at ../../../kern/tty.c:2822 #7 0xc0703292 in ttread (tp=0xc7ce3000, uio=0xef9ecc60, flag=0) at ../../../kern/tty.c:1877 #8 0xc0706db3 in ptsread (dev=0xc6612100, uio=0xef9ecc60, flag=0) at linedisc.h:100 #9 0xc06845ec in giant_read (dev=0xc6612100, uio=0xef9ecc60, ioflag=0) at ../../../kern/kern_conf.c:424 #10 0xc064ce52 in devfs_read_f (fp=0xc6575be0, uio=0xef9ecc60, cred=0xc74ee100, flags=0, td=0xc5d3e000) at ../../../fs/devfs/devfs_vnops.c:1000 #11 0xc06f358d in dofileread (td=0xc5d3e000, fd=10, fp=0xc6575be0, auio=0xef9ecc60, offset=-1, flags=0) at file.h:244 #12 0xc06f389e in kern_readv (td=0xc5d3e000, fd=10, auio=0xef9ecc60) at ../../../kern/sys_generic.c:192 #13 0xc06f3968 in read (td=0xc5d3e000, uap=0xef9eccfc) at ../../../kern/sys_generic.c:108 #14 0xc091d0a5 in syscall (frame=0xef9ecd38) at ../../../i386/i386/trap.c:1090 #15 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #16 0x00000033 in ?? () (kgdb) [Switching to thread 108 (Thread 100268)] #0 sched_switch (td=0xc74afd20, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc74afd20, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06ed780 in sleepq_catch_signals (wchan=0xc74b65d0) at ../../../kern/subr_sleepqueue.c:417 #4 0xc06edf92 in sleepq_wait_sig (wchan=0xc74b65d0) at ../../../kern/subr_sleepqueue.c:594 #5 0xc06c5307 in _sleep (ident=0xc74b65d0, lock=0xc74b6600, priority=360, wmesg=0xc0965c7e "pause", timo=0) at ../../../kern/kern_synch.c:224 #6 0xc06be494 in kern_sigsuspend (td=0xc74afd20, mask={__bits = {0, 0, 0, 0}}) at ../../../kern/kern_sig.c:1474 #7 0xc06be532 in sigsuspend (td=0xc74afd20, uap=0xef9accfc) at ../../../kern/kern_sig.c:1453 #8 0xc091d0a5 in syscall (frame=0xef9acd38) at ../../../i386/i386/trap.c:1090 #9 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #10 0x00000033 in ?? () (kgdb) [Switching to thread 107 (Thread 100324)] #0 sched_switch (td=0xc692caf0, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc692caf0, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06ed780 in sleepq_catch_signals (wchan=0xc623d680) at ../../../kern/subr_sleepqueue.c:417 #4 0xc06edf92 in sleepq_wait_sig (wchan=0xc623d680) at ../../../kern/subr_sleepqueue.c:594 #5 0xc06c5307 in _sleep (ident=0xc623d680, lock=0xc623d6c4, priority=339, wmesg=0xc099e71c "nfsreq", timo=0) at ../../../kern/kern_synch.c:224 #6 0xc083ea75 in nfs_request (vp=0xc5124ac8, mrest=0xc539c500, procnum=1, td=0xc692caf0, cred=0xc68b5800, mrp=0xefa8d7ec, mdp=0xefa8d7e8, dposp=0xefa8d7f0) at ../../../nfsclient/nfs_socket.c:778 #7 0xc0846ecb in nfs_getattr (ap=0xefa8d838) at ../../../nfsclient/nfs_vnops.c:662 #8 0xc0930702 in VOP_GETATTR_APV (vop=0xc0a27aa0, a=0xefa8d838) at vnode_if.c:530 #9 0xc08491c6 in nfsspec_access (ap=0xefa8d9d8) at vnode_if.h:286 #10 0xc0849434 in nfs_access (ap=0xefa8d9d8) at ../../../nfsclient/nfs_vnops.c:392 #11 0xc0930682 in VOP_ACCESS_APV (vop=0xc0a27aa0, a=0xefa8d9d8) at vnode_if.c:477 #12 0xc084a503 in nfs_lookup (ap=0xefa8da84) at vnode_if.h:257 #13 0xc0931ed1 in VOP_LOOKUP_APV (vop=0xc0a27aa0, a=0xefa8da84) at vnode_if.c:99 #14 0xc072ea95 in lookup (ndp=0xefa8dba8) at vnode_if.h:57 #15 0xc072f794 in namei (ndp=0xefa8dba8) at ../../../kern/vfs_lookup.c:219 #16 0xc073ce92 in kern_stat (td=0xc692caf0, path=0x80f8880
, pathseg=UIO_USERSPACE, sbp=0xefa8dc18) at ../../../kern/vfs_syscalls.c:2113 #17 0xc073d05f in stat (td=0xc692caf0, uap=0xefa8dcfc) at ../../../kern/vfs_syscalls.c:2097 #18 0xc091d0a5 in syscall (frame=0xefa8dd38) at ../../../i386/i386/trap.c:1090 #19 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #20 0x00000033 in ?? () (kgdb) [Switching to thread 106 (Thread 100086)] #0 sched_switch (td=0xc5137d20, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc5137d20, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06eff31 in ast (framep=0xef702d38) at ../../../kern/subr_trap.c:241 #3 0xc090534d in doreti_ast () at ../../../i386/i386/exception.s:349 #4 0xef702d38 in ?? () #5 0x0000003b in ?? () #6 0x0000003b in ?? () #7 0x0000003b in ?? () #8 0x084ae000 in ?? () #9 0x00000009 in ?? () #10 0xbfbfe098 in ?? () #11 0xef702d64 in ?? () #12 0x2820a878 in ?? () #13 0x00000000 in ?? () #14 0x00000000 in ?? () #15 0x00000000 in ?? () #16 0x0000000c in ?? () #17 0x00000007 in ?? () #18 0x281870aa in ?? () #19 0x00000033 in ?? () #20 0x00010297 in ?? () #21 0xbfbfe060 in ?? () #22 0x0000003b in ?? () #23 0x00000000 in ?? () #24 0x00000000 in ?? () #25 0x00000000 in ?? () #26 0x00000000 in ?? () #27 0x0b511000 in ?? () #28 0xc0a651c0 in tdq_cpu () #29 0xc5137f1c in ?? () #30 0xef702cd4 in ?? () #31 0xef702c98 in ?? () #32 0x2412c00f in ?? () #33 0xc06dbb29 in sched_switch (td=) at ../../../kern/sched_ule.c:1938 (kgdb) [Switching to thread 105 (Thread 100097)] #0 sched_switch (td=0xc692c8c0, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc692c8c0, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06ed780 in sleepq_catch_signals (wchan=0xc0a681b8) at ../../../kern/subr_sleepqueue.c:417 #4 0xc06edf92 in sleepq_wait_sig (wchan=0xc0a681b8) at ../../../kern/subr_sleepqueue.c:594 #5 0xc0682adf in _cv_wait_sig (cvp=0xc0a681b8, lock=0xc0a681a0) at ../../../kern/kern_condvar.c:245 #6 0xc06f4a0a in kern_select (td=0xc692c8c0, nd=1024, fd_in=0xbf4f9f00, fd_ou=0xbf4f9e80, fd_ex=0x0, tvp=0x0) at ../../../kern/sys_generic.c:788 #7 0xc06f4bfe in select (td=0xc692c8c0, uap=0xef733cfc) at ../../../kern/sys_generic.c:663 #8 0xc091d0a5 in syscall (frame=0xef733d38) at ../../../i386/i386/trap.c:1090 #9 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #10 0x00000033 in ?? () (kgdb) [Switching to thread 104 (Thread 100096)] #0 sched_switch (td=0xc5502690, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc5502690, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06ed780 in sleepq_catch_signals (wchan=0xc611cb40) at ../../../kern/subr_sleepqueue.c:417 #4 0xc06edeb6 in sleepq_timedwait_sig (wchan=0xc611cb40) at ../../../kern/subr_sleepqueue.c:631 #5 0xc06c52e1 in _sleep (ident=0xc611cb40, lock=0xc0a5e588, priority=256, wmesg=0xc098e57e "ucond", timo=576) at ../../../kern/kern_synch.c:220 #6 0xc06d39e7 in __umtx_op_cv_wait (td=0xc5502690, uap=0xef730cfc) at ../../../kern/kern_umtx.c:482 #7 0xc06cec88 in _umtx_op (td=0xc5502690, uap=0xef730cfc) at ../../../kern/kern_umtx.c:2926 #8 0xc091d0a5 in syscall (frame=0xef730d38) at ../../../i386/i386/trap.c:1090 #9 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #10 0x00000033 in ?? () (kgdb) [Switching to thread 103 (Thread 100095)] #0 sched_switch (td=0xc692c690, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc692c690, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06ed780 in sleepq_catch_signals (wchan=0xc60d8ac0) at ../../../kern/subr_sleepqueue.c:417 #4 0xc06edf92 in sleepq_wait_sig (wchan=0xc60d8ac0) at ../../../kern/subr_sleepqueue.c:594 #5 0xc06c5307 in _sleep (ident=0xc60d8ac0, lock=0xc0a5dc90, priority=256, wmesg=0xc098e57e "ucond", timo=0) at ../../../kern/kern_synch.c:224 #6 0xc06d392b in __umtx_op_cv_wait (td=0xc692c690, uap=0xef72dcfc) at ../../../kern/kern_umtx.c:482 #7 0xc06cec88 in _umtx_op (td=0xc692c690, uap=0xef72dcfc) at ../../../kern/kern_umtx.c:2926 #8 0xc091d0a5 in syscall (frame=0xef72dd38) at ../../../i386/i386/trap.c:1090 #9 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #10 0x00000033 in ?? () (kgdb) [Switching to thread 102 (Thread 100094)] #0 sched_switch (td=0xc692c460, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc692c460, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06ed780 in sleepq_catch_signals (wchan=0xc61044c0) at ../../../kern/subr_sleepqueue.c:417 #4 0xc06edf92 in sleepq_wait_sig (wchan=0xc61044c0) at ../../../kern/subr_sleepqueue.c:594 #5 0xc06c5307 in _sleep (ident=0xc61044c0, lock=0xc0a5dc90, priority=256, wmesg=0xc098e57e "ucond", timo=0) at ../../../kern/kern_synch.c:224 #6 0xc06d392b in __umtx_op_cv_wait (td=0xc692c460, uap=0xef72acfc) at ../../../kern/kern_umtx.c:482 #7 0xc06cec88 in _umtx_op (td=0xc692c460, uap=0xef72acfc) at ../../../kern/kern_umtx.c:2926 #8 0xc091d0a5 in syscall (frame=0xef72ad38) at ../../../i386/i386/trap.c:1090 #9 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #10 0x00000033 in ?? () (kgdb) [Switching to thread 101 (Thread 100093)] #0 sched_switch (td=0xc692bd20, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc692bd20, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06ed780 in sleepq_catch_signals (wchan=0xc60f4080) at ../../../kern/subr_sleepqueue.c:417 #4 0xc06edf92 in sleepq_wait_sig (wchan=0xc60f4080) at ../../../kern/subr_sleepqueue.c:594 #5 0xc06c5307 in _sleep (ident=0xc60f4080, lock=0xc0a5dc90, priority=256, wmesg=0xc098e57e "ucond", timo=0) at ../../../kern/kern_synch.c:224 #6 0xc06d392b in __umtx_op_cv_wait (td=0xc692bd20, uap=0xef727cfc) at ../../../kern/kern_umtx.c:482 #7 0xc06cec88 in _umtx_op (td=0xc692bd20, uap=0xef727cfc) at ../../../kern/kern_umtx.c:2926 #8 0xc091d0a5 in syscall (frame=0xef727d38) at ../../../i386/i386/trap.c:1090 #9 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #10 0x00000033 in ?? () (kgdb) [Switching to thread 100 (Thread 100092)] #0 sched_switch (td=0xc692baf0, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc692baf0, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06ed780 in sleepq_catch_signals (wchan=0xc60f4840) at ../../../kern/subr_sleepqueue.c:417 #4 0xc06edf92 in sleepq_wait_sig (wchan=0xc60f4840) at ../../../kern/subr_sleepqueue.c:594 #5 0xc06c5307 in _sleep (ident=0xc60f4840, lock=0xc0a5dc90, priority=256, wmesg=0xc098e57e "ucond", timo=0) at ../../../kern/kern_synch.c:224 #6 0xc06d392b in __umtx_op_cv_wait (td=0xc692baf0, uap=0xef724cfc) at ../../../kern/kern_umtx.c:482 #7 0xc06cec88 in _umtx_op (td=0xc692baf0, uap=0xef724cfc) at ../../../kern/kern_umtx.c:2926 #8 0xc091d0a5 in syscall (frame=0xef724d38) at ../../../i386/i386/trap.c:1090 #9 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #10 0x00000033 in ?? () (kgdb) [Switching to thread 99 (Thread 100047)] #0 sched_switch (td=0xc50edd20, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc50edd20, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06ed780 in sleepq_catch_signals (wchan=0xc50e81c0) at ../../../kern/subr_sleepqueue.c:417 #4 0xc06edf92 in sleepq_wait_sig (wchan=0xc50e81c0) at ../../../kern/subr_sleepqueue.c:594 #5 0xc06c5307 in _sleep (ident=0xc50e81c0, lock=0xc0a5e128, priority=256, wmesg=0xc098e557 "uwait", timo=0) at ../../../kern/kern_synch.c:224 #6 0xc06cf74b in do_wait (td=) at ../../../kern/kern_umtx.c:482 #7 0xc06cfbb3 in __umtx_op_wait (td=0xc50edd20, uap=0xef635cfc) at ../../../kern/kern_umtx.c:2744 #8 0xc06cec88 in _umtx_op (td=0xc50edd20, uap=0xef635cfc) at ../../../kern/kern_umtx.c:2926 #9 0xc091d0a5 in syscall (frame=0xef635d38) at ../../../i386/i386/trap.c:1090 #10 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #11 0x00000033 in ?? () (kgdb) [Switching to thread 98 (Thread 100195)] #0 sched_switch (td=0xc5b748c0, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc5b748c0, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06ed780 in sleepq_catch_signals (wchan=0xc0a6e8a4) at ../../../kern/subr_sleepqueue.c:417 #4 0xc06edeb6 in sleepq_timedwait_sig (wchan=0xc0a6e8a4) at ../../../kern/subr_sleepqueue.c:631 #5 0xc06c52e1 in _sleep (ident=0xc0a6e8a4, lock=0xc0a6e870, priority=348, wmesg=0xc098792e "-", timo=900000) at ../../../kern/kern_synch.c:220 #6 0xc0841a1a in nfssvc_iod (instance=0xc0a6e224) at ../../../nfsclient/nfs_nfsiod.c:244 #7 0xc069a351 in fork_exit (callout=0xc084192c , arg=0xc0a6e224, frame=0xef8a4d38) at ../../../kern/kern_fork.c:804 #8 0xc0904aa0 in fork_trampoline () at ../../../i386/i386/exception.s:264 (kgdb) [Switching to thread 97 (Thread 100151)] #0 doadump () at pcpu.h:196 in pcpu.h (kgdb) #0 doadump () at pcpu.h:196 #1 0xc06bd1e6 in boot (howto=260) at ../../../kern/kern_shutdown.c:418 #2 0xc06bd4e3 in panic (fmt=) at ../../../kern/kern_shutdown.c:574 #3 0xc091cb09 in trap_fatal (frame=0xef7fb8c8, eva=172) at ../../../i386/i386/trap.c:939 #4 0xc091cd59 in trap_pfault (frame=0xef7fb8c8, usermode=0, eva=172) at ../../../i386/i386/trap.c:852 #5 0xc091d6eb in trap (frame=0xef7fb8c8) at ../../../i386/i386/trap.c:530 #6 0xc0904a2b in calltrap () at ../../../i386/i386/exception.s:159 #7 0xc07f58fd in tcp_ctloutput (so=0xc71a0680, sopt=0xef7fbac8) at atomic.h:149 #8 0xc071024d in sosetopt (so=0xc71a0680, sopt=0xef7fbac8) at ../../../kern/uipc_socket.c:2339 #9 0xc083ba5c in nfs_connect (nmp=0xc54e4d20, rep=0xc6208000) at ../../../nfsclient/nfs_socket.c:428 #10 0xc083bf9a in nfs_reconnect (rep=0xc6208000) at ../../../nfsclient/nfs_socket.c:542 #11 0xc083e6e5 in nfs_request (vp=0xc81e0228, mrest=0xc56f4000, procnum=7, td=0x0, cred=0xc6f46b00, mrp=0xef7fbc08, mdp=0xef7fbc04, dposp=0xef7fbc0c) at ../../../nfsclient/nfs_socket.c:737 #12 0xc0847577 in nfs_writerpc (vp=0xc81e0228, uiop=0xef7fbc84, cred=0xc6f46b00, iomode=0xef7fbca8, must_commit=0xef7fbca4) at ../../../nfsclient/nfs_vnops.c:1183 #13 0xc083539f in nfs_doio (vp=0xc81e0228, bp=0xd8e7e074, cr=0xc6f46b00, td=0x0) at ../../../nfsclient/nfs_bio.c:1683 #14 0xc0841be5 in nfssvc_iod (instance=0xc0a6e220) at ../../../nfsclient/nfs_nfsiod.c:282 #15 0xc069a351 in fork_exit (callout=0xc084192c , arg=0xc0a6e220, frame=0xef7fbd38) at ../../../kern/kern_fork.c:804 #16 0xc0904aa0 in fork_trampoline () at ../../../i386/i386/exception.s:264 (kgdb) [Switching to thread 96 (Thread 100051)] #0 sched_switch (td=0xcba8e460, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xcba8e460, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06eda87 in sleepq_wait (wchan=0xd8f65914) at ../../../kern/subr_sleepqueue.c:580 #4 0xc06c5316 in _sleep (ident=0xd8f65914, lock=0xc0a68678, priority=76, wmesg=0xc09926ef "biord", timo=0) at ../../../kern/kern_synch.c:226 #5 0xc071fc31 in bwait (bp=0xd8f65914, pri=76 'L', wchan=0xc09926ef "biord") at ../../../kern/vfs_bio.c:3802 #6 0xc071fca8 in bufwait (bp=0xd8f65914) at ../../../kern/vfs_bio.c:3057 #7 0xc08aae3c in ufs_bmaparray (vp=0xc5848678, bn=89, bnp=0xef645a60, nbp=0x0, runp=0xef645bcc, runb=0xef645bd0) at ../../../ufs/ufs/ufs_bmap.c:230 #8 0xc08ab3e9 in ufs_bmap (ap=0xef645ac0) at ../../../ufs/ufs/ufs_bmap.c:84 #9 0xc0930d03 in VOP_BMAP_APV (vop=0xc0a2aa00, a=0xef645ac0) at vnode_if.c:1717 #10 0xc08d9481 in vnode_pager_haspage (object=0xc584b0f8, pindex=356, before=0xef645bd0, after=0xef645bcc) at vnode_if.h:912 #11 0xc08c32be in vm_fault (map=0xc4d37e80, vaddr=135970816, fault_type=1 '\001', fault_flags=) at vm_pager.h:171 #12 0xc091cc49 in trap_pfault (frame=0xef645d38, usermode=1, eva=135974446) at ../../../i386/i386/trap.c:829 #13 0xc091d56f in trap (frame=0xef645d38) at ../../../i386/i386/trap.c:397 #14 0xc0904a2b in calltrap () at ../../../i386/i386/exception.s:159 #15 0x081ace2e in ?? () (kgdb) [Switching to thread 95 (Thread 100087)] #0 sched_switch (td=0xc77a68c0, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc77a68c0, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06ed780 in sleepq_catch_signals (wchan=0xc99cb8dc) at ../../../kern/subr_sleepqueue.c:417 #4 0xc06edf92 in sleepq_wait_sig (wchan=0xc99cb8dc) at ../../../kern/subr_sleepqueue.c:594 #5 0xc06c5307 in _sleep (ident=0xc99cb8dc, lock=0xc99cb894, priority=344, wmesg=0xc09921a1 "sbwait", timo=0) at ../../../kern/kern_synch.c:224 #6 0xc070e220 in sbwait (sb=0xc99cb870) at ../../../kern/uipc_sockbuf.c:130 #7 0xc0713f81 in soreceive_generic (so=0xc99cb820, psa=0x0, uio=0xef706c60, mp0=0x0, controlp=0x0, flagsp=0x0) at ../../../kern/uipc_socket.c:1487 #8 0xc070f59d in soreceive (so=0xc99cb820, psa=0x0, uio=0xef706c60, mp0=0x0, controlp=0x0, flagsp=0x0) at ../../../kern/uipc_socket.c:2032 #9 0xc06f9773 in soo_read (fp=0xc5bd6260, uio=0xef706c60, active_cred=0xc5b6c800, flags=0, td=0xc77a68c0) at ../../../kern/sys_socket.c:85 #10 0xc06f358d in dofileread (td=0xc77a68c0, fd=20, fp=0xc5bd6260, auio=0xef706c60, offset=-1, flags=0) at file.h:244 #11 0xc06f389e in kern_readv (td=0xc77a68c0, fd=20, auio=0xef706c60) at ../../../kern/sys_generic.c:192 #12 0xc06f3968 in read (td=0xc77a68c0, uap=0xef706cfc) at ../../../kern/sys_generic.c:108 #13 0xc091d0a5 in syscall (frame=0xef706d38) at ../../../i386/i386/trap.c:1090 #14 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #15 0x00000033 in ?? () (kgdb) [Switching to thread 94 (Thread 100205)] #0 sched_switch (td=0xc5854230, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc5854230, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06ed780 in sleepq_catch_signals (wchan=0xef8ccbe0) at ../../../kern/subr_sleepqueue.c:417 #4 0xc06edf92 in sleepq_wait_sig (wchan=0xef8ccbe0) at ../../../kern/subr_sleepqueue.c:594 #5 0xc06c5307 in _sleep (ident=0xef8ccbe0, lock=0xc54d18b8, priority=360, wmesg=0xc098b89f "sigwait", timo=0) at ../../../kern/kern_synch.c:224 #6 0xc06c04eb in kern_sigtimedwait (td=0xc5854230, waitset={__bits = {155653, 0, 0, 0}}, ksi=0xef8ccc24, timeout=0x0) at ../../../kern/kern_sig.c:1256 #7 0xc06c0979 in sigwait (td=0xc5854230, uap=0xef8cccfc) at ../../../kern/kern_sig.c:1093 #8 0xc091d0a5 in syscall (frame=0xef8ccd38) at ../../../i386/i386/trap.c:1090 #9 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #10 0x00000033 in ?? () (kgdb) [Switching to thread 93 (Thread 100118)] #0 sched_switch (td=0xc54e1230, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc54e1230, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06ed780 in sleepq_catch_signals (wchan=0xc0a681b8) at ../../../kern/subr_sleepqueue.c:417 #4 0xc06edf92 in sleepq_wait_sig (wchan=0xc0a681b8) at ../../../kern/subr_sleepqueue.c:594 #5 0xc0682adf in _cv_wait_sig (cvp=0xc0a681b8, lock=0xc0a681a0) at ../../../kern/kern_condvar.c:245 #6 0xc06f4a0a in kern_select (td=0xc54e1230, nd=4, fd_in=0xbfbfe908, fd_ou=0x0, fd_ex=0x0, tvp=0x0) at ../../../kern/sys_generic.c:788 #7 0xc06f4bfe in select (td=0xc54e1230, uap=0xef78dcfc) at ../../../kern/sys_generic.c:663 #8 0xc091d0a5 in syscall (frame=0xef78dd38) at ../../../i386/i386/trap.c:1090 #9 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #10 0x00000033 in ?? () (kgdb) [Switching to thread 92 (Thread 100084)] #0 sched_switch (td=0xc5321af0, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc5321af0, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06eda87 in sleepq_wait (wchan=0xd8d642a8) at ../../../kern/subr_sleepqueue.c:580 #4 0xc06c5316 in _sleep (ident=0xd8d642a8, lock=0xc0a68678, priority=68, wmesg=0xc09a519e "vnread", timo=0) at ../../../kern/kern_synch.c:226 #5 0xc071fc31 in bwait (bp=0xd8d642a8, pri=68 'D', wchan=0xc09a519e "vnread") at ../../../kern/vfs_bio.c:3802 #6 0xc08dba5b in vnode_pager_generic_getpages (vp=0xc588f9b4, m=0xef6fac04, bytecount=) at ../../../vm/vnode_pager.c:932 #7 0xc08a927a in ffs_getpages (ap=0xef6faacc) at ../../../ufs/ffs/ffs_vnops.c:851 #8 0xc0931083 in VOP_GETPAGES_APV (vop=0xc0a2aa00, a=0xef6faacc) at vnode_if.c:2136 #9 0xc08da14e in vnode_pager_getpages (object=0xc597a934, m=0xef6fac04, count=1, reqpage=0) at vnode_if.h:1129 #10 0xc08c3689 in vm_fault (map=0xc5360d98, vaddr=134537216, fault_type=1 '\001', fault_flags=) at vm_pager.h:130 #11 0xc091cc49 in trap_pfault (frame=0xef6fad38, usermode=1, eva=134538800) at ../../../i386/i386/trap.c:829 #12 0xc091d56f in trap (frame=0xef6fad38) at ../../../i386/i386/trap.c:397 #13 0xc0904a2b in calltrap () at ../../../i386/i386/exception.s:159 #14 0x0804e630 in ?? () (kgdb) [Switching to thread 91 (Thread 100074)] #0 sched_switch (td=0xc512b460, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc512b460, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06eda87 in sleepq_wait (wchan=0xc5125c34) at ../../../kern/subr_sleepqueue.c:580 #4 0xc06c5316 in _sleep (ident=0xc5125c34, lock=0xc0a5bf48, priority=80, wmesg=0xc09896b6 "ufs", timo=0) at ../../../kern/kern_synch.c:226 #5 0xc06a9ab0 in acquire (lkpp=0xef6c097c, extflags=) at ../../../kern/kern_lock.c:151 #6 0xc06aa33a in _lockmgr (lkp=0xc5125c34, flags=8194, interlkp=0xc5125c64, td=0xc512b460, file=0xc0994187 "../../../kern/vfs_subr.c", line=2061) at ../../../kern/kern_lock.c:384 #7 0xc08a8fec in ffs_lock (ap=0xef6c09e4) at ../../../ufs/ffs/ffs_vnops.c:377 #8 0xc0931811 in VOP_LOCK1_APV (vop=0xc0a2aa00, a=0xef6c09e4) at vnode_if.c:1618 #9 0xc074646a in _vn_lock (vp=0xc5125bdc, flags=8194, td=0xc512b460, file=0xc0994187 "../../../kern/vfs_subr.c", line=2061) at vnode_if.h:851 #10 0xc0739b5e in vget (vp=0xc5125bdc, flags=8194, td=0xc512b460) at ../../../kern/vfs_subr.c:2061 #11 0xc072d89d in vfs_hash_get (mp=0xc50b5598, hash=2, flags=) at ../../../kern/vfs_hash.c:81 #12 0xc08a3add in ffs_vget (mp=0xc50b5598, ino=2, flags=2, vpp=0xef6c0af4) at ../../../ufs/ffs/ffs_vfsops.c:1307 #13 0xc08b39d8 in ufs_root (mp=0xc50b5598, flags=2, vpp=0xef6c0b50, td=0xc512b460) at ../../../ufs/ufs/ufs_vfsops.c:78 #14 0xc072eea0 in lookup (ndp=0xef6c0c10) at ../../../kern/vfs_lookup.c:679 #15 0xc072f794 in namei (ndp=0xef6c0c10) at ../../../kern/vfs_lookup.c:219 #16 0xc073fa82 in kern_unlink (td=0xc512b460, path=0xbfbfd6e8
, pathseg=UIO_USERSPACE) at ../../../kern/vfs_syscalls.c:1670 #17 0xc073fca9 in unlink (td=0xc512b460, uap=0xef6c0cfc) at ../../../kern/vfs_syscalls.c:1653 #18 0xc091d0a5 in syscall (frame=0xef6c0d38) at ../../../i386/i386/trap.c:1090 #19 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #20 0x00000033 in ?? () (kgdb) [Switching to thread 90 (Thread 100122)] #0 sched_switch (td=0xc54e08c0, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc54e08c0, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06eda87 in sleepq_wait (wchan=0xc5125c34) at ../../../kern/subr_sleepqueue.c:580 #4 0xc06c5316 in _sleep (ident=0xc5125c34, lock=0xc0a5bf48, priority=80, wmesg=0xc09896b6 "ufs", timo=0) at ../../../kern/kern_synch.c:226 #5 0xc06a9ab0 in acquire (lkpp=0xef7a497c, extflags=) at ../../../kern/kern_lock.c:151 #6 0xc06aa33a in _lockmgr (lkp=0xc5125c34, flags=8194, interlkp=0xc5125c64, td=0xc54e08c0, file=0xc0994187 "../../../kern/vfs_subr.c", line=2061) at ../../../kern/kern_lock.c:384 #7 0xc08a8fec in ffs_lock (ap=0xef7a49e4) at ../../../ufs/ffs/ffs_vnops.c:377 #8 0xc0931811 in VOP_LOCK1_APV (vop=0xc0a2aa00, a=0xef7a49e4) at vnode_if.c:1618 #9 0xc074646a in _vn_lock (vp=0xc5125bdc, flags=8194, td=0xc54e08c0, file=0xc0994187 "../../../kern/vfs_subr.c", line=2061) at vnode_if.h:851 #10 0xc0739b5e in vget (vp=0xc5125bdc, flags=8194, td=0xc54e08c0) at ../../../kern/vfs_subr.c:2061 #11 0xc072d89d in vfs_hash_get (mp=0xc50b5598, hash=2, flags=) at ../../../kern/vfs_hash.c:81 #12 0xc08a3add in ffs_vget (mp=0xc50b5598, ino=2, flags=2, vpp=0xef7a4af4) at ../../../ufs/ffs/ffs_vfsops.c:1307 #13 0xc08b39d8 in ufs_root (mp=0xc50b5598, flags=2, vpp=0xef7a4b50, td=0xc54e08c0) at ../../../ufs/ufs/ufs_vfsops.c:78 #14 0xc072eea0 in lookup (ndp=0xef7a4c10) at ../../../kern/vfs_lookup.c:679 #15 0xc072f794 in namei (ndp=0xef7a4c10) at ../../../kern/vfs_lookup.c:219 #16 0xc073fa82 in kern_unlink (td=0xc54e08c0, path=0xbfbfcc28
, pathseg=UIO_USERSPACE) at ../../../kern/vfs_syscalls.c:1670 #17 0xc073fca9 in unlink (td=0xc54e08c0, uap=0xef7a4cfc) at ../../../kern/vfs_syscalls.c:1653 #18 0xc091d0a5 in syscall (frame=0xef7a4d38) at ../../../i386/i386/trap.c:1090 #19 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #20 0x00000033 in ?? () (kgdb) [Switching to thread 89 (Thread 100050)] #0 sched_switch (td=0xc50ed8c0, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc50ed8c0, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06ed780 in sleepq_catch_signals (wchan=0xc0a681b8) at ../../../kern/subr_sleepqueue.c:417 #4 0xc06edf92 in sleepq_wait_sig (wchan=0xc0a681b8) at ../../../kern/subr_sleepqueue.c:594 #5 0xc0682adf in _cv_wait_sig (cvp=0xc0a681b8, lock=0xc0a681a0) at ../../../kern/kern_condvar.c:245 #6 0xc06f4a0a in kern_select (td=0xc50ed8c0, nd=20, fd_in=0xbfbfede0, fd_ou=0x0, fd_ex=0x0, tvp=0x0) at ../../../kern/sys_generic.c:788 #7 0xc06f4bfe in select (td=0xc50ed8c0, uap=0xef641cfc) at ../../../kern/sys_generic.c:663 #8 0xc091d0a5 in syscall (frame=0xef641d38) at ../../../i386/i386/trap.c:1090 #9 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #10 0x00000033 in ?? () (kgdb) [Switching to thread 88 (Thread 100157)] #0 sched_switch (td=0xc5846af0, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc5846af0, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06eda87 in sleepq_wait (wchan=0xc4f7dd48) at ../../../kern/subr_sleepqueue.c:580 #4 0xc06c5316 in _sleep (ident=0xc4f7dd48, lock=0xc0a5c5c0, priority=80, wmesg=0xc09870fd "devfs", timo=0) at ../../../kern/kern_synch.c:226 #5 0xc06a9ab0 in acquire (lkpp=0xef80d8b4, extflags=) at ../../../kern/kern_lock.c:151 #6 0xc06aa33a in _lockmgr (lkp=0xc4f7dd48, flags=12290, interlkp=0xc4f7dd78, td=0xc5846af0, file=0xc0994682 "../../../kern/vfs_vnops.c", line=288) at ../../../kern/kern_lock.c:384 #7 0xc072a951 in vop_stdlock (ap=0xef80d904) at ../../../kern/vfs_default.c:305 #8 0xc0931811 in VOP_LOCK1_APV (vop=0xc0a19240, a=0xef80d904) at vnode_if.c:1618 #9 0xc074646a in _vn_lock (vp=0xc4f7dcf0, flags=4098, td=0xc5846af0, file=0xc0994682 "../../../kern/vfs_vnops.c", line=288) at vnode_if.h:851 #10 0xc0746f20 in vn_close (vp=0xc4f7dcf0, flags=3, file_cred=0xc4d0a100, td=0xc5846af0) at ../../../kern/vfs_vnops.c:288 #11 0xc0747078 in vn_closefile (fp=0xc5570720, td=0xc5846af0) at ../../../kern/vfs_vnops.c:867 #12 0xc064cb80 in devfs_close_f (fp=0xc5570720, td=0xc5846af0) at ../../../fs/devfs/devfs_vnops.c:479 #13 0xc0689e86 in fdrop (fp=0xc5570720, td=0xc5846af0) at file.h:299 #14 0xc068b388 in closef (fp=0xc5570720, td=0xc5846af0) at ../../../kern/kern_descrip.c:2033 #15 0xc068c4d1 in fdfree (td=0xc5846af0) at ../../../kern/kern_descrip.c:1743 #16 0xc0698d2c in exit1 (td=0xc5846af0, rv=15) at ../../../kern/kern_exit.c:283 #17 0xc06bf779 in sigexit (td=0xc5846af0, sig=15) at ../../../kern/kern_sig.c:2882 #18 0xc06bf96c in postsig (sig=15) at ../../../kern/kern_sig.c:2754 #19 0xc06f0023 in ast (framep=0xef80dd38) at ../../../kern/subr_trap.c:252 #20 0xc090534d in doreti_ast () at ../../../i386/i386/exception.s:349 #21 0xef80dd38 in ?? () #22 0x0000003b in ?? () #23 0x0000003b in ?? () #24 0xbfbf003b in ?? () #25 0x00000002 in ?? () #26 0x0000003c in ?? () #27 0xbfbfd7d8 in ?? () #28 0xef80dd64 in ?? () #29 0x28164878 in ?? () #30 0x0000003c in ?? () #31 0x00000000 in ?? () #32 0x00000004 in ?? () #33 0x00000020 in ?? () #34 0x00000002 in ?? () #35 0x28136f17 in ?? () #36 0x00000033 in ?? () #37 0x00000207 in ?? () #38 0xbfbfd7ac in ?? () #39 0x0000003b in ?? () #40 0x00000000 in ?? () #41 0x00000000 in ?? () #42 0x00000000 in ?? () #43 0x00000000 in ?? () #44 0x0b48c000 in ?? () #45 0xc0a66ed0 in sleepq_chains () #46 0xc5846cec in ?? () #47 0xef80d79c in ?? () #48 0xef80d760 in ?? () #49 0xc5846af0 in ?? () #50 0xc06dbb29 in sched_switch (td=) at ../../../kern/sched_ule.c:1938 (kgdb) [Switching to thread 87 (Thread 100065)] #0 sched_switch (td=0xc512c8c0, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc512c8c0, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06eda87 in sleepq_wait (wchan=0xc5851a0c) at ../../../kern/subr_sleepqueue.c:580 #4 0xc06c5316 in _sleep (ident=0xc5851a0c, lock=0xc0a5c7e8, priority=80, wmesg=0xc09896b6 "ufs", timo=0) at ../../../kern/kern_synch.c:226 #5 0xc06a9ab0 in acquire (lkpp=0xef6a599c, extflags=) at ../../../kern/kern_lock.c:151 #6 0xc06aa33a in _lockmgr (lkp=0xc5851a0c, flags=8194, interlkp=0xc5851a3c, td=0xc512c8c0, file=0xc0994187 "../../../kern/vfs_subr.c", line=2061) at ../../../kern/kern_lock.c:384 #7 0xc08a8fec in ffs_lock (ap=0xef6a5a04) at ../../../ufs/ffs/ffs_vnops.c:377 #8 0xc0931811 in VOP_LOCK1_APV (vop=0xc0a2aa00, a=0xef6a5a04) at vnode_if.c:1618 #9 0xc074646a in _vn_lock (vp=0xc58519b4, flags=8194, td=0xc512c8c0, file=0xc0994187 "../../../kern/vfs_subr.c", line=2061) at vnode_if.h:851 #10 0xc0739b5e in vget (vp=0xc58519b4, flags=8194, td=0xc512c8c0) at ../../../kern/vfs_subr.c:2061 #11 0xc072843b in cache_lookup (dvp=0xc5222cf0, vpp=0xef6a5c24, cnp=0xef6a5c38) at ../../../kern/vfs_cache.c:442 #12 0xc0728540 in vfs_cache_lookup (ap=0xef6a5b40) at ../../../kern/vfs_cache.c:667 #13 0xc0931ed1 in VOP_LOOKUP_APV (vop=0xc0a2af20, a=0xef6a5b40) at vnode_if.c:99 #14 0xc072ea95 in lookup (ndp=0xef6a5c10) at vnode_if.h:57 #15 0xc072f794 in namei (ndp=0xef6a5c10) at ../../../kern/vfs_lookup.c:219 #16 0xc073fa82 in kern_unlink (td=0xc512c8c0, path=0x8116d30
, pathseg=UIO_USERSPACE) at ../../../kern/vfs_syscalls.c:1670 #17 0xc073fca9 in unlink (td=0xc512c8c0, uap=0xef6a5cfc) at ../../../kern/vfs_syscalls.c:1653 #18 0xc091d0a5 in syscall (frame=0xef6a5d38) at ../../../i386/i386/trap.c:1090 #19 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #20 0x00000033 in ?? () (kgdb) [Switching to thread 86 (Thread 100102)] #0 sched_switch (td=0xc531e8c0, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc531e8c0, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06eda87 in sleepq_wait (wchan=0xc5222d48) at ../../../kern/subr_sleepqueue.c:580 #4 0xc06c5316 in _sleep (ident=0xc5222d48, lock=0xc0a5bfc0, priority=80, wmesg=0xc09896b6 "ufs", timo=0) at ../../../kern/kern_synch.c:226 #5 0xc06a9ab0 in acquire (lkpp=0xef74799c, extflags=) at ../../../kern/kern_lock.c:151 #6 0xc06aa33a in _lockmgr (lkp=0xc5222d48, flags=8194, interlkp=0xc5222d78, td=0xc531e8c0, file=0xc0994187 "../../../kern/vfs_subr.c", line=2061) at ../../../kern/kern_lock.c:384 #7 0xc08a8fec in ffs_lock (ap=0xef747a04) at ../../../ufs/ffs/ffs_vnops.c:377 #8 0xc0931811 in VOP_LOCK1_APV (vop=0xc0a2aa00, a=0xef747a04) at vnode_if.c:1618 #9 0xc074646a in _vn_lock (vp=0xc5222cf0, flags=8194, td=0xc531e8c0, file=0xc0994187 "../../../kern/vfs_subr.c", line=2061) at vnode_if.h:851 #10 0xc0739b5e in vget (vp=0xc5222cf0, flags=8194, td=0xc531e8c0) at ../../../kern/vfs_subr.c:2061 #11 0xc072843b in cache_lookup (dvp=0xc5222e04, vpp=0xef747c24, cnp=0xef747c38) at ../../../kern/vfs_cache.c:442 #12 0xc0728540 in vfs_cache_lookup (ap=0xef747b40) at ../../../kern/vfs_cache.c:667 #13 0xc0931ed1 in VOP_LOOKUP_APV (vop=0xc0a2af20, a=0xef747b40) at vnode_if.c:99 #14 0xc072ea95 in lookup (ndp=0xef747c10) at vnode_if.h:57 #15 0xc072f794 in namei (ndp=0xef747c10) at ../../../kern/vfs_lookup.c:219 #16 0xc073fa82 in kern_unlink (td=0xc531e8c0, path=0x8116d30
, pathseg=UIO_USERSPACE) at ../../../kern/vfs_syscalls.c:1670 #17 0xc073fca9 in unlink (td=0xc531e8c0, uap=0xef747cfc) at ../../../kern/vfs_syscalls.c:1653 #18 0xc091d0a5 in syscall (frame=0xef747d38) at ../../../i386/i386/trap.c:1090 #19 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #20 0x00000033 in ?? () (kgdb) [Switching to thread 85 (Thread 100138)] #0 fork_trampoline () at ../../../i386/i386/exception.s:261 261 pushl %esp /* trapframe pointer */ Current language: auto; currently asm (kgdb) #0 fork_trampoline () at ../../../i386/i386/exception.s:261 (kgdb) [Switching to thread 84 (Thread 100208)] #0 sched_switch (td=0xc50faaf0, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); Current language: auto; currently c (kgdb) #0 sched_switch (td=0xc50faaf0, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06ed780 in sleepq_catch_signals (wchan=0xc674f25c) at ../../../kern/subr_sleepqueue.c:417 #4 0xc06edf92 in sleepq_wait_sig (wchan=0xc674f25c) at ../../../kern/subr_sleepqueue.c:594 #5 0xc06c5307 in _sleep (ident=0xc674f25c, lock=0xc674f214, priority=344, wmesg=0xc09921a1 "sbwait", timo=0) at ../../../kern/kern_synch.c:224 #6 0xc070e220 in sbwait (sb=0xc674f1f0) at ../../../kern/uipc_sockbuf.c:130 #7 0xc0713f81 in soreceive_generic (so=0xc674f1a0, psa=0x0, uio=0xef8ddc60, mp0=0x0, controlp=0x0, flagsp=0x0) at ../../../kern/uipc_socket.c:1487 #8 0xc070f59d in soreceive (so=0xc674f1a0, psa=0x0, uio=0xef8ddc60, mp0=0x0, controlp=0x0, flagsp=0x0) at ../../../kern/uipc_socket.c:2032 #9 0xc06f9773 in soo_read (fp=0xc526edf4, uio=0xef8ddc60, active_cred=0xc56e8800, flags=0, td=0xc50faaf0) at ../../../kern/sys_socket.c:85 #10 0xc06f358d in dofileread (td=0xc50faaf0, fd=108, fp=0xc526edf4, auio=0xef8ddc60, offset=-1, flags=0) at file.h:244 #11 0xc06f389e in kern_readv (td=0xc50faaf0, fd=108, auio=0xef8ddc60) at ../../../kern/sys_generic.c:192 #12 0xc06f3968 in read (td=0xc50faaf0, uap=0xef8ddcfc) at ../../../kern/sys_generic.c:108 #13 0xc091d0a5 in syscall (frame=0xef8ddd38) at ../../../i386/i386/trap.c:1090 #14 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #15 0x00000033 in ?? () (kgdb) [Switching to thread 83 (Thread 100365)] #0 sched_switch (td=0xc81b08c0, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc81b08c0, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06ed780 in sleepq_catch_signals (wchan=0xc6c2425c) at ../../../kern/subr_sleepqueue.c:417 #4 0xc06edf92 in sleepq_wait_sig (wchan=0xc6c2425c) at ../../../kern/subr_sleepqueue.c:594 #5 0xc06c5307 in _sleep (ident=0xc6c2425c, lock=0xc6c24214, priority=344, wmesg=0xc09921a1 "sbwait", timo=0) at ../../../kern/kern_synch.c:224 #6 0xc070e220 in sbwait (sb=0xc6c241f0) at ../../../kern/uipc_sockbuf.c:130 #7 0xc0713f81 in soreceive_generic (so=0xc6c241a0, psa=0x0, uio=0xefb08c60, mp0=0x0, controlp=0x0, flagsp=0x0) at ../../../kern/uipc_socket.c:1487 #8 0xc070f59d in soreceive (so=0xc6c241a0, psa=0x0, uio=0xefb08c60, mp0=0x0, controlp=0x0, flagsp=0x0) at ../../../kern/uipc_socket.c:2032 #9 0xc06f9773 in soo_read (fp=0xc83cc474, uio=0xefb08c60, active_cred=0xc56e8800, flags=0, td=0xc81b08c0) at ../../../kern/sys_socket.c:85 #10 0xc06f358d in dofileread (td=0xc81b08c0, fd=149, fp=0xc83cc474, auio=0xefb08c60, offset=-1, flags=0) at file.h:244 #11 0xc06f389e in kern_readv (td=0xc81b08c0, fd=149, auio=0xefb08c60) at ../../../kern/sys_generic.c:192 #12 0xc06f3968 in read (td=0xc81b08c0, uap=0xefb08cfc) at ../../../kern/sys_generic.c:108 #13 0xc091d0a5 in syscall (frame=0xefb08d38) at ../../../i386/i386/trap.c:1090 #14 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #15 0x00000033 in ?? () (kgdb) [Switching to thread 82 (Thread 100368)] #0 sched_switch (td=0xc7cd3af0, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc7cd3af0, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06ed780 in sleepq_catch_signals (wchan=0xc6eda3fc) at ../../../kern/subr_sleepqueue.c:417 #4 0xc06edf92 in sleepq_wait_sig (wchan=0xc6eda3fc) at ../../../kern/subr_sleepqueue.c:594 #5 0xc06c5307 in _sleep (ident=0xc6eda3fc, lock=0xc6eda3b4, priority=344, wmesg=0xc09921a1 "sbwait", timo=0) at ../../../kern/kern_synch.c:224 #6 0xc070e220 in sbwait (sb=0xc6eda390) at ../../../kern/uipc_sockbuf.c:130 #7 0xc0713f81 in soreceive_generic (so=0xc6eda340, psa=0x0, uio=0xefb11c60, mp0=0x0, controlp=0x0, flagsp=0x0) at ../../../kern/uipc_socket.c:1487 #8 0xc070f59d in soreceive (so=0xc6eda340, psa=0x0, uio=0xefb11c60, mp0=0x0, controlp=0x0, flagsp=0x0) at ../../../kern/uipc_socket.c:2032 #9 0xc06f9773 in soo_read (fp=0xc512017c, uio=0xefb11c60, active_cred=0xc56e8800, flags=0, td=0xc7cd3af0) at ../../../kern/sys_socket.c:85 #10 0xc06f358d in dofileread (td=0xc7cd3af0, fd=183, fp=0xc512017c, auio=0xefb11c60, offset=-1, flags=0) at file.h:244 #11 0xc06f389e in kern_readv (td=0xc7cd3af0, fd=183, auio=0xefb11c60) at ../../../kern/sys_generic.c:192 #12 0xc06f3968 in read (td=0xc7cd3af0, uap=0xefb11cfc) at ../../../kern/sys_generic.c:108 #13 0xc091d0a5 in syscall (frame=0xefb11d38) at ../../../i386/i386/trap.c:1090 #14 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #15 0x00000033 in ?? () (kgdb) [Switching to thread 81 (Thread 100363)] #0 sched_switch (td=0xcadc6af0, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xcadc6af0, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06ed780 in sleepq_catch_signals (wchan=0xcb98173c) at ../../../kern/subr_sleepqueue.c:417 #4 0xc06edf92 in sleepq_wait_sig (wchan=0xcb98173c) at ../../../kern/subr_sleepqueue.c:594 #5 0xc06c5307 in _sleep (ident=0xcb98173c, lock=0xcb9816f4, priority=344, wmesg=0xc09921a1 "sbwait", timo=0) at ../../../kern/kern_synch.c:224 #6 0xc070e220 in sbwait (sb=0xcb9816d0) at ../../../kern/uipc_sockbuf.c:130 #7 0xc0713f81 in soreceive_generic (so=0xcb981680, psa=0x0, uio=0xefb02c60, mp0=0x0, controlp=0x0, flagsp=0x0) at ../../../kern/uipc_socket.c:1487 #8 0xc070f59d in soreceive (so=0xcb981680, psa=0x0, uio=0xefb02c60, mp0=0x0, controlp=0x0, flagsp=0x0) at ../../../kern/uipc_socket.c:2032 #9 0xc06f9773 in soo_read (fp=0xc5570cc4, uio=0xefb02c60, active_cred=0xc56e8800, flags=0, td=0xcadc6af0) at ../../../kern/sys_socket.c:85 #10 0xc06f358d in dofileread (td=0xcadc6af0, fd=199, fp=0xc5570cc4, auio=0xefb02c60, offset=-1, flags=0) at file.h:244 #11 0xc06f389e in kern_readv (td=0xcadc6af0, fd=199, auio=0xefb02c60) at ../../../kern/sys_generic.c:192 #12 0xc06f3968 in read (td=0xcadc6af0, uap=0xefb02cfc) at ../../../kern/sys_generic.c:108 #13 0xc091d0a5 in syscall (frame=0xefb02d38) at ../../../i386/i386/trap.c:1090 #14 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #15 0x00000033 in ?? () (kgdb) [Switching to thread 80 (Thread 100169)] #0 sched_switch (td=0xc5854460, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc5854460, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06ed780 in sleepq_catch_signals (wchan=0xef831be0) at ../../../kern/subr_sleepqueue.c:417 #4 0xc06edf92 in sleepq_wait_sig (wchan=0xef831be0) at ../../../kern/subr_sleepqueue.c:594 #5 0xc06c5307 in _sleep (ident=0xef831be0, lock=0xc5243090, priority=360, wmesg=0xc098b89f "sigwait", timo=0) at ../../../kern/kern_synch.c:224 #6 0xc06c04eb in kern_sigtimedwait (td=0xc5854460, waitset={__bits = {155653, 0, 0, 0}}, ksi=0xef831c24, timeout=0x0) at ../../../kern/kern_sig.c:1256 #7 0xc06c0979 in sigwait (td=0xc5854460, uap=0xef831cfc) at ../../../kern/kern_sig.c:1093 #8 0xc091d0a5 in syscall (frame=0xef831d38) at ../../../i386/i386/trap.c:1090 #9 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #10 0x00000033 in ?? () (kgdb) [Switching to thread 79 (Thread 100166)] #0 sched_switch (td=0xc5854690, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc5854690, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06ed780 in sleepq_catch_signals (wchan=0xc5700240) at ../../../kern/subr_sleepqueue.c:417 #4 0xc06edf92 in sleepq_wait_sig (wchan=0xc5700240) at ../../../kern/subr_sleepqueue.c:594 #5 0xc06c5307 in _sleep (ident=0xc5700240, lock=0xc0a5e198, priority=256, wmesg=0xc098e57e "ucond", timo=0) at ../../../kern/kern_synch.c:224 #6 0xc06d392b in __umtx_op_cv_wait (td=0xc5854690, uap=0xef828cfc) at ../../../kern/kern_umtx.c:482 #7 0xc06cec88 in _umtx_op (td=0xc5854690, uap=0xef828cfc) at ../../../kern/kern_umtx.c:2926 #8 0xc091d0a5 in syscall (frame=0xef828d38) at ../../../i386/i386/trap.c:1090 #9 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #10 0x00000033 in ?? () (kgdb) [Switching to thread 78 (Thread 100168)] #0 sched_switch (td=0xc58548c0, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc58548c0, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06ed780 in sleepq_catch_signals (wchan=0xc0a681b8) at ../../../kern/subr_sleepqueue.c:417 #4 0xc06edeb6 in sleepq_timedwait_sig (wchan=0xc0a681b8) at ../../../kern/subr_sleepqueue.c:631 #5 0xc06826b1 in _cv_timedwait_sig (cvp=0xc0a681b8, lock=0xc0a681a0, timo=251) at ../../../kern/kern_condvar.c:369 #6 0xc06f49f2 in kern_select (td=0xc58548c0, nd=0, fd_in=0x0, fd_ou=0x0, fd_ex=0x0, tvp=0xef82ec70) at ../../../kern/sys_generic.c:786 #7 0xc06f4bfe in select (td=0xc58548c0, uap=0xef82ecfc) at ../../../kern/sys_generic.c:663 #8 0xc091d0a5 in syscall (frame=0xef82ed38) at ../../../i386/i386/trap.c:1090 #9 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #10 0x00000033 in ?? () (kgdb) [Switching to thread 77 (Thread 100167)] #0 sched_switch (td=0xc5854af0, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc5854af0, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06ed780 in sleepq_catch_signals (wchan=0xc0a681b8) at ../../../kern/subr_sleepqueue.c:417 #4 0xc06edeb6 in sleepq_timedwait_sig (wchan=0xc0a681b8) at ../../../kern/subr_sleepqueue.c:631 #5 0xc06826b1 in _cv_timedwait_sig (cvp=0xc0a681b8, lock=0xc0a681a0, timo=251) at ../../../kern/kern_condvar.c:369 #6 0xc06f49f2 in kern_select (td=0xc5854af0, nd=0, fd_in=0x0, fd_ou=0x0, fd_ex=0x0, tvp=0xef82bc70) at ../../../kern/sys_generic.c:786 #7 0xc06f4bfe in select (td=0xc5854af0, uap=0xef82bcfc) at ../../../kern/sys_generic.c:663 #8 0xc091d0a5 in syscall (frame=0xef82bd38) at ../../../i386/i386/trap.c:1090 #9 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #10 0x00000033 in ?? () (kgdb) [Switching to thread 76 (Thread 100165)] #0 sched_switch (td=0xc5855000, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc5855000, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06ed780 in sleepq_catch_signals (wchan=0xc56cda40) at ../../../kern/subr_sleepqueue.c:417 #4 0xc06edf92 in sleepq_wait_sig (wchan=0xc56cda40) at ../../../kern/subr_sleepqueue.c:594 #5 0xc06c5307 in _sleep (ident=0xc56cda40, lock=0xc0a5de18, priority=256, wmesg=0xc098e57e "ucond", timo=0) at ../../../kern/kern_synch.c:224 #6 0xc06d392b in __umtx_op_cv_wait (td=0xc5855000, uap=0xef825cfc) at ../../../kern/kern_umtx.c:482 #7 0xc06cec88 in _umtx_op (td=0xc5855000, uap=0xef825cfc) at ../../../kern/kern_umtx.c:2926 #8 0xc091d0a5 in syscall (frame=0xef825d38) at ../../../i386/i386/trap.c:1090 #9 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #10 0x00000033 in ?? () (kgdb) [Switching to thread 75 (Thread 100164)] #0 sched_switch (td=0xc5855230, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc5855230, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06ed780 in sleepq_catch_signals (wchan=0xc56cda00) at ../../../kern/subr_sleepqueue.c:417 #4 0xc06edf92 in sleepq_wait_sig (wchan=0xc56cda00) at ../../../kern/subr_sleepqueue.c:594 #5 0xc06c5307 in _sleep (ident=0xc56cda00, lock=0xc0a5db08, priority=256, wmesg=0xc098e57e "ucond", timo=0) at ../../../kern/kern_synch.c:224 #6 0xc06d392b in __umtx_op_cv_wait (td=0xc5855230, uap=0xef822cfc) at ../../../kern/kern_umtx.c:482 #7 0xc06cec88 in _umtx_op (td=0xc5855230, uap=0xef822cfc) at ../../../kern/kern_umtx.c:2926 #8 0xc091d0a5 in syscall (frame=0xef822d38) at ../../../i386/i386/trap.c:1090 #9 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #10 0x00000033 in ?? () (kgdb) [Switching to thread 74 (Thread 100163)] #0 sched_switch (td=0xc5137000, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc5137000, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06ed780 in sleepq_catch_signals (wchan=0xc513e680) at ../../../kern/subr_sleepqueue.c:417 #4 0xc06edf92 in sleepq_wait_sig (wchan=0xc513e680) at ../../../kern/subr_sleepqueue.c:594 #5 0xc06c5307 in _sleep (ident=0xc513e680, lock=0xc0a5d7f8, priority=256, wmesg=0xc098e57e "ucond", timo=0) at ../../../kern/kern_synch.c:224 #6 0xc06d392b in __umtx_op_cv_wait (td=0xc5137000, uap=0xef81fcfc) at ../../../kern/kern_umtx.c:482 #7 0xc06cec88 in _umtx_op (td=0xc5137000, uap=0xef81fcfc) at ../../../kern/kern_umtx.c:2926 #8 0xc091d0a5 in syscall (frame=0xef81fd38) at ../../../i386/i386/trap.c:1090 #9 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #10 0x00000033 in ?? () (kgdb) [Switching to thread 73 (Thread 100162)] #0 sched_switch (td=0xc5137230, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc5137230, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06ed780 in sleepq_catch_signals (wchan=0xc513e640) at ../../../kern/subr_sleepqueue.c:417 #4 0xc06edf92 in sleepq_wait_sig (wchan=0xc513e640) at ../../../kern/subr_sleepqueue.c:594 #5 0xc06c5307 in _sleep (ident=0xc513e640, lock=0xc0a5d4e8, priority=256, wmesg=0xc098e57e "ucond", timo=0) at ../../../kern/kern_synch.c:224 #6 0xc06d392b in __umtx_op_cv_wait (td=0xc5137230, uap=0xef81ccfc) at ../../../kern/kern_umtx.c:482 #7 0xc06cec88 in _umtx_op (td=0xc5137230, uap=0xef81ccfc) at ../../../kern/kern_umtx.c:2926 #8 0xc091d0a5 in syscall (frame=0xef81cd38) at ../../../i386/i386/trap.c:1090 #9 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #10 0x00000033 in ?? () (kgdb) [Switching to thread 72 (Thread 100068)] #0 sched_switch (td=0xc512c230, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc512c230, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06ed780 in sleepq_catch_signals (wchan=0xc0a681b8) at ../../../kern/subr_sleepqueue.c:417 #4 0xc06edf92 in sleepq_wait_sig (wchan=0xc0a681b8) at ../../../kern/subr_sleepqueue.c:594 #5 0xc0682adf in _cv_wait_sig (cvp=0xc0a681b8, lock=0xc0a681a0) at ../../../kern/kern_condvar.c:245 #6 0xc06f4a0a in kern_select (td=0xc512c230, nd=14, fd_in=0xbfbfeab8, fd_ou=0x0, fd_ex=0x0, tvp=0x0) at ../../../kern/sys_generic.c:788 #7 0xc06f4bfe in select (td=0xc512c230, uap=0xef6aecfc) at ../../../kern/sys_generic.c:663 #8 0xc091d0a5 in syscall (frame=0xef6aed38) at ../../../i386/i386/trap.c:1090 #9 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #10 0x00000033 in ?? () (kgdb) [Switching to thread 71 (Thread 100124)] #0 sched_switch (td=0xc54e0460, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc54e0460, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06ed780 in sleepq_catch_signals (wchan=0xc56bcae0) at ../../../kern/subr_sleepqueue.c:417 #4 0xc06edf92 in sleepq_wait_sig (wchan=0xc56bcae0) at ../../../kern/subr_sleepqueue.c:594 #5 0xc06c5307 in _sleep (ident=0xc56bcae0, lock=0xc56bcb70, priority=348, wmesg=0xc09a6e08 "wait", timo=0) at ../../../kern/kern_synch.c:224 #6 0xc0698666 in kern_wait (td=0xc54e0460, pid=-1, status=0xef7aac2c, options=) at ../../../kern/kern_exit.c:897 #7 0xc0698700 in wait4 (td=0xc54e0460, uap=0xef7aacfc) at ../../../kern/kern_exit.c:683 #8 0xc091d0a5 in syscall (frame=0xef7aad38) at ../../../i386/i386/trap.c:1090 #9 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #10 0x00000033 in ?? () (kgdb) [Switching to thread 70 (Thread 100128)] #0 sched_switch (td=0xc545aaf0, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc545aaf0, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06eda87 in sleepq_wait (wchan=0xc5125a0c) at ../../../kern/subr_sleepqueue.c:580 #4 0xc06c5316 in _sleep (ident=0xc5125a0c, lock=0xc0a5bf78, priority=80, wmesg=0xc09896b6 "ufs", timo=0) at ../../../kern/kern_synch.c:226 #5 0xc06a9ab0 in acquire (lkpp=0xef7b680c, extflags=) at ../../../kern/kern_lock.c:151 #6 0xc06aa33a in _lockmgr (lkp=0xc5125a0c, flags=8194, interlkp=0xc5125a3c, td=0xc545aaf0, file=0xc0994187 "../../../kern/vfs_subr.c", line=2061) at ../../../kern/kern_lock.c:384 #7 0xc08a8fec in ffs_lock (ap=0xef7b6874) at ../../../ufs/ffs/ffs_vnops.c:377 #8 0xc0931811 in VOP_LOCK1_APV (vop=0xc0a2aa00, a=0xef7b6874) at vnode_if.c:1618 #9 0xc074646a in _vn_lock (vp=0xc51259b4, flags=8194, td=0xc545aaf0, file=0xc0994187 "../../../kern/vfs_subr.c", line=2061) at vnode_if.h:851 #10 0xc0739b5e in vget (vp=0xc51259b4, flags=8194, td=0xc545aaf0) at ../../../kern/vfs_subr.c:2061 #11 0xc072843b in cache_lookup (dvp=0xc5125bdc, vpp=0xef7b6bb8, cnp=0xef7b6bcc) at ../../../kern/vfs_cache.c:442 #12 0xc0728540 in vfs_cache_lookup (ap=0xef7b69b0) at ../../../kern/vfs_cache.c:667 #13 0xc0931ed1 in VOP_LOOKUP_APV (vop=0xc0a2af20, a=0xef7b69b0) at vnode_if.c:99 #14 0xc072ea95 in lookup (ndp=0xef7b6ba4) at vnode_if.h:57 #15 0xc072f794 in namei (ndp=0xef7b6ba4) at ../../../kern/vfs_lookup.c:219 #16 0xc0719ad9 in unp_connect (so=0xc600b340, nam=) at ../../../kern/uipc_usrreq.c:1140 #17 0xc071c23c in uipc_connect (so=0xc600b340, nam=0xc625fa60, td=0xc545aaf0) at ../../../kern/uipc_usrreq.c:504 #18 0xc070f517 in soconnect (so=0xc600b340, nam=0xc625fa60, td=0xc545aaf0) at ../../../kern/uipc_socket.c:771 #19 0xc0716619 in kern_connect (td=0xc545aaf0, fd=3, sa=0xc625fa60) at ../../../kern/uipc_syscalls.c:570 #20 0xc071679e in connect (td=0xc545aaf0, uap=0xef7b6cfc) at ../../../kern/uipc_syscalls.c:534 #21 0xc091d0a5 in syscall (frame=0xef7b6d38) at ../../../i386/i386/trap.c:1090 #22 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #23 0x00000033 in ?? () (kgdb) [Switching to thread 69 (Thread 100115)] #0 sched_switch (td=0xc5458000, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc5458000, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06eda87 in sleepq_wait (wchan=0xd8d6dd04) at ../../../kern/subr_sleepqueue.c:580 #4 0xc06c5316 in _sleep (ident=0xd8d6dd04, lock=0xc0a68678, priority=68, wmesg=0xc09a519e "vnread", timo=0) at ../../../kern/kern_synch.c:226 #5 0xc071fc31 in bwait (bp=0xd8d6dd04, pri=68 'D', wchan=0xc09a519e "vnread") at ../../../kern/vfs_bio.c:3802 #6 0xc08dba5b in vnode_pager_generic_getpages (vp=0xc56cb9b4, m=0xef7839e8, bytecount=) at ../../../vm/vnode_pager.c:932 #7 0xc08a927a in ffs_getpages (ap=0xef7838b0) at ../../../ufs/ffs/ffs_vnops.c:851 #8 0xc0931083 in VOP_GETPAGES_APV (vop=0xc0a2aa00, a=0xef7838b0) at vnode_if.c:2136 #9 0xc08da14e in vnode_pager_getpages (object=0xc558a000, m=0xef7839e8, count=5, reqpage=0) at vnode_if.h:1129 #10 0xc08c3689 in vm_fault (map=0xc4d37570, vaddr=134565888, fault_type=1 '\001', fault_flags=) at vm_pager.h:130 #11 0xc091cc49 in trap_pfault (frame=0xef783b1c, usermode=0, eva=134567879) at ../../../i386/i386/trap.c:829 #12 0xc091d6eb in trap (frame=0xef783b1c) at ../../../i386/i386/trap.c:530 #13 0xc0904a2b in calltrap () at ../../../i386/i386/exception.s:159 #14 0xc091af8f in copyinstr () at ../../../i386/i386/support.s:1351 #15 0x00000000 in ?? () #16 0x00000000 in ?? () #17 0x00000000 in ?? () #18 0x00000000 in ?? () #19 0x00000000 in ?? () #20 0x00000000 in ?? () #21 0x00000000 in ?? () #22 0x00000000 in ?? () #23 0x00000002 in ?? () #24 0x0500000c in ?? () #25 0xc5458000 in ?? () #26 0xc4d0a100 in ?? () #27 0x00000000 in ?? () #28 0xc551d800 in ?? () #29 0x00000000 in ?? () #30 0x00000000 in ?? () #31 0x00000000 in ?? () #32 0x00000000 in ?? () #33 0x00000000 in ?? () #34 0xc54d22b8 in ?? () #35 0xc5458000 in ?? () #36 0xef783c80 in ?? () #37 0xc073fca9 in unlink (td=0xef783c10, uap=0x0) at ../../../kern/vfs_syscalls.c:1653 (kgdb) [Switching to thread 68 (Thread 100053)] #0 sched_switch (td=0xc50ed230, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc50ed230, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06eda87 in sleepq_wait (wchan=0xd8d6a29c) at ../../../kern/subr_sleepqueue.c:580 #4 0xc06c5316 in _sleep (ident=0xd8d6a29c, lock=0xc0a68678, priority=68, wmesg=0xc09a519e "vnread", timo=0) at ../../../kern/kern_synch.c:226 #5 0xc071fc31 in bwait (bp=0xd8d6a29c, pri=68 'D', wchan=0xc09a519e "vnread") at ../../../kern/vfs_bio.c:3802 #6 0xc08dba5b in vnode_pager_generic_getpages (vp=0xc558e9b4, m=0xef64dc04, bytecount=) at ../../../vm/vnode_pager.c:932 #7 0xc08a927a in ffs_getpages (ap=0xef64dacc) at ../../../ufs/ffs/ffs_vnops.c:851 #8 0xc0931083 in VOP_GETPAGES_APV (vop=0xc0a2aa00, a=0xef64dacc) at vnode_if.c:2136 #9 0xc08da14e in vnode_pager_getpages (object=0xc558aa2c, m=0xef64dc04, count=1, reqpage=0) at vnode_if.h:1129 #10 0xc08c3689 in vm_fault (map=0xc5323d98, vaddr=134520832, fault_type=1 '\001', fault_flags=) at vm_pager.h:130 #11 0xc091cc49 in trap_pfault (frame=0xef64dd38, usermode=1, eva=134521497) at ../../../i386/i386/trap.c:829 #12 0xc091d56f in trap (frame=0xef64dd38) at ../../../i386/i386/trap.c:397 #13 0xc0904a2b in calltrap () at ../../../i386/i386/exception.s:159 #14 0x0804a299 in ?? () (kgdb) [Switching to thread 67 (Thread 100099)] #0 sched_switch (td=0xc5321000, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc5321000, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06eda87 in sleepq_wait (wchan=0xc5125c34) at ../../../kern/subr_sleepqueue.c:580 #4 0xc06c5316 in _sleep (ident=0xc5125c34, lock=0xc0a5bf48, priority=80, wmesg=0xc09896b6 "ufs", timo=0) at ../../../kern/kern_synch.c:226 #5 0xc06a9ab0 in acquire (lkpp=0xef73b7ec, extflags=) at ../../../kern/kern_lock.c:151 #6 0xc06aa33a in _lockmgr (lkp=0xc5125c34, flags=8194, interlkp=0xc5125c64, td=0xc5321000, file=0xc0994187 "../../../kern/vfs_subr.c", line=2061) at ../../../kern/kern_lock.c:384 #7 0xc08a8fec in ffs_lock (ap=0xef73b854) at ../../../ufs/ffs/ffs_vnops.c:377 #8 0xc0931811 in VOP_LOCK1_APV (vop=0xc0a2aa00, a=0xef73b854) at vnode_if.c:1618 #9 0xc074646a in _vn_lock (vp=0xc5125bdc, flags=8194, td=0xc5321000, file=0xc0994187 "../../../kern/vfs_subr.c", line=2061) at vnode_if.h:851 #10 0xc0739b5e in vget (vp=0xc5125bdc, flags=8194, td=0xc5321000) at ../../../kern/vfs_subr.c:2061 #11 0xc072d89d in vfs_hash_get (mp=0xc50b5598, hash=2, flags=) at ../../../kern/vfs_hash.c:81 #12 0xc08a3add in ffs_vget (mp=0xc50b5598, ino=2, flags=2, vpp=0xef73b964) at ../../../ufs/ffs/ffs_vfsops.c:1307 #13 0xc08b39d8 in ufs_root (mp=0xc50b5598, flags=2, vpp=0xef73b9c0, td=0xc5321000) at ../../../ufs/ufs/ufs_vfsops.c:78 #14 0xc072eea0 in lookup (ndp=0xef73bba4) at ../../../kern/vfs_lookup.c:679 #15 0xc072f794 in namei (ndp=0xef73bba4) at ../../../kern/vfs_lookup.c:219 #16 0xc0719ad9 in unp_connect (so=0xc6c1cb60, nam=) at ../../../kern/uipc_usrreq.c:1140 #17 0xc071c23c in uipc_connect (so=0xc6c1cb60, nam=0xcbdc0880, td=0xc5321000) at ../../../kern/uipc_usrreq.c:504 #18 0xc070f517 in soconnect (so=0xc6c1cb60, nam=0xcbdc0880, td=0xc5321000) at ../../../kern/uipc_socket.c:771 #19 0xc0716619 in kern_connect (td=0xc5321000, fd=5, sa=0xcbdc0880) at ../../../kern/uipc_syscalls.c:570 #20 0xc071679e in connect (td=0xc5321000, uap=0xef73bcfc) at ../../../kern/uipc_syscalls.c:534 #21 0xc091d0a5 in syscall (frame=0xef73bd38) at ../../../i386/i386/trap.c:1090 #22 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #23 0x00000033 in ?? () (kgdb) [Switching to thread 66 (Thread 100119)] #0 sched_switch (td=0xc54e1000, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc54e1000, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06f19e5 in turnstile_wait (ts=0xcbd87910, owner=0xc4e61af0, queue=) at ../../../kern/subr_turnstile.c:748 #3 0xc06bbe06 in _rw_wlock_hard (rw=0xcb93df60, tid=3310227456, file=0x0, line=0) at ../../../kern/kern_rwlock.c:685 #4 0xc07f65e5 in tcp_usr_rcvd (so=0xc6804000, flags=128) at ../../../netinet/tcp_usrreq.c:733 #5 0xc0714ab5 in soreceive_generic (so=0xc6804000, psa=0x0, uio=0xef790710, mp0=0xef79070c, controlp=0x0, flagsp=0xef790708) at ../../../kern/uipc_socket.c:1827 #6 0xc070f59d in soreceive (so=0xc6804000, psa=0x0, uio=0xef790710, mp0=0xef79070c, controlp=0x0, flagsp=0xef790708) at ../../../kern/uipc_socket.c:2032 #7 0xc0876b13 in svc_vc_recv (xprt=0xcb920900, msg=0xef790ad4) at ../../../rpc/svc_vc.c:620 #8 0xc087439c in svc_run (pool=0xc5157c80) at ../../../rpc/svc.c:467 #9 0xc08654a1 in nlm_syscall (td=0xc54e1000, uap=0xef790cfc) at ../../../nlm/nlm_prot_impl.c:1548 #10 0xc091d0a5 in syscall (frame=0xef790d38) at ../../../i386/i386/trap.c:1090 #11 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #12 0x00000033 in ?? () (kgdb) [Switching to thread 65 (Thread 100114)] #0 sched_switch (td=0xc5458230, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc5458230, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06ed780 in sleepq_catch_signals (wchan=0xc5558000) at ../../../kern/subr_sleepqueue.c:417 #4 0xc06edf92 in sleepq_wait_sig (wchan=0xc5558000) at ../../../kern/subr_sleepqueue.c:594 #5 0xc06c5307 in _sleep (ident=0xc5558000, lock=0xc0a73b60, priority=344, wmesg=0xc098792e "-", timo=0) at ../../../kern/kern_synch.c:224 #6 0xc085f3aa in nfssvc (td=0xc5458230, uap=0xef77fcfc) at ../../../nfsserver/nfs_syscalls.c:319 #7 0xc091d0a5 in syscall (frame=0xef77fd38) at ../../../i386/i386/trap.c:1090 #8 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #9 0x00000033 in ?? () (kgdb) [Switching to thread 64 (Thread 100049)] #0 sched_switch (td=0xc4e62af0, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc4e62af0, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06ed780 in sleepq_catch_signals (wchan=0xc5558200) at ../../../kern/subr_sleepqueue.c:417 #4 0xc06edf92 in sleepq_wait_sig (wchan=0xc5558200) at ../../../kern/subr_sleepqueue.c:594 #5 0xc06c5307 in _sleep (ident=0xc5558200, lock=0xc0a73b60, priority=344, wmesg=0xc098792e "-", timo=0) at ../../../kern/kern_synch.c:224 #6 0xc085f3aa in nfssvc (td=0xc4e62af0, uap=0xef63dcfc) at ../../../nfsserver/nfs_syscalls.c:319 #7 0xc091d0a5 in syscall (frame=0xef63dd38) at ../../../i386/i386/trap.c:1090 #8 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #9 0x00000033 in ?? () (kgdb) [Switching to thread 63 (Thread 100112)] #0 sched_switch (td=0xc5458690, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc5458690, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06ed780 in sleepq_catch_signals (wchan=0xc507c600) at ../../../kern/subr_sleepqueue.c:417 #4 0xc06edf92 in sleepq_wait_sig (wchan=0xc507c600) at ../../../kern/subr_sleepqueue.c:594 #5 0xc06c5307 in _sleep (ident=0xc507c600, lock=0xc0a73b60, priority=344, wmesg=0xc098792e "-", timo=0) at ../../../kern/kern_synch.c:224 #6 0xc085f3aa in nfssvc (td=0xc5458690, uap=0xef778cfc) at ../../../nfsserver/nfs_syscalls.c:319 #7 0xc091d0a5 in syscall (frame=0xef778d38) at ../../../i386/i386/trap.c:1090 #8 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #9 0x00000033 in ?? () (kgdb) [Switching to thread 62 (Thread 100111)] #0 sched_switch (td=0xc54588c0, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc54588c0, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06ed780 in sleepq_catch_signals (wchan=0xc5175e00) at ../../../kern/subr_sleepqueue.c:417 #4 0xc06edf92 in sleepq_wait_sig (wchan=0xc5175e00) at ../../../kern/subr_sleepqueue.c:594 #5 0xc06c5307 in _sleep (ident=0xc5175e00, lock=0xc0a73b60, priority=344, wmesg=0xc098792e "-", timo=0) at ../../../kern/kern_synch.c:224 #6 0xc085f3aa in nfssvc (td=0xc54588c0, uap=0xef775cfc) at ../../../nfsserver/nfs_syscalls.c:319 #7 0xc091d0a5 in syscall (frame=0xef775d38) at ../../../i386/i386/trap.c:1090 #8 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #9 0x00000033 in ?? () (kgdb) [Switching to thread 61 (Thread 100110)] #0 sched_switch (td=0xc5458af0, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc5458af0, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06ed780 in sleepq_catch_signals (wchan=0xc507c400) at ../../../kern/subr_sleepqueue.c:417 #4 0xc06edf92 in sleepq_wait_sig (wchan=0xc507c400) at ../../../kern/subr_sleepqueue.c:594 #5 0xc06c5307 in _sleep (ident=0xc507c400, lock=0xc0a73b60, priority=344, wmesg=0xc098792e "-", timo=0) at ../../../kern/kern_synch.c:224 #6 0xc085f3aa in nfssvc (td=0xc5458af0, uap=0xef772cfc) at ../../../nfsserver/nfs_syscalls.c:319 #7 0xc091d0a5 in syscall (frame=0xef772d38) at ../../../i386/i386/trap.c:1090 #8 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #9 0x00000033 in ?? () (kgdb) [Switching to thread 60 (Thread 100107)] #0 sched_switch (td=0xc5459000, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc5459000, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06ed780 in sleepq_catch_signals (wchan=0xc5558400) at ../../../kern/subr_sleepqueue.c:417 #4 0xc06edf92 in sleepq_wait_sig (wchan=0xc5558400) at ../../../kern/subr_sleepqueue.c:594 #5 0xc06c5307 in _sleep (ident=0xc5558400, lock=0xc0a73b60, priority=344, wmesg=0xc098792e "-", timo=0) at ../../../kern/kern_synch.c:224 #6 0xc085f3aa in nfssvc (td=0xc5459000, uap=0xef768cfc) at ../../../nfsserver/nfs_syscalls.c:319 #7 0xc091d0a5 in syscall (frame=0xef768d38) at ../../../i386/i386/trap.c:1090 #8 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #9 0x00000033 in ?? () (kgdb) [Switching to thread 59 (Thread 100077)] #0 sched_switch (td=0xc5250460, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc5250460, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06ed780 in sleepq_catch_signals (wchan=0xc5176000) at ../../../kern/subr_sleepqueue.c:417 #4 0xc06edf92 in sleepq_wait_sig (wchan=0xc5176000) at ../../../kern/subr_sleepqueue.c:594 #5 0xc06c5307 in _sleep (ident=0xc5176000, lock=0xc0a73b60, priority=344, wmesg=0xc098792e "-", timo=0) at ../../../kern/kern_synch.c:224 #6 0xc085f3aa in nfssvc (td=0xc5250460, uap=0xef6c9cfc) at ../../../nfsserver/nfs_syscalls.c:319 #7 0xc091d0a5 in syscall (frame=0xef6c9d38) at ../../../i386/i386/trap.c:1090 #8 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #9 0x00000033 in ?? () (kgdb) [Switching to thread 58 (Thread 100105)] #0 sched_switch (td=0xc5459460, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc5459460, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06ed780 in sleepq_catch_signals (wchan=0xc5558600) at ../../../kern/subr_sleepqueue.c:417 #4 0xc06edf92 in sleepq_wait_sig (wchan=0xc5558600) at ../../../kern/subr_sleepqueue.c:594 #5 0xc06c5307 in _sleep (ident=0xc5558600, lock=0xc0a73b60, priority=344, wmesg=0xc098792e "-", timo=0) at ../../../kern/kern_synch.c:224 #6 0xc085f3aa in nfssvc (td=0xc5459460, uap=0xef762cfc) at ../../../nfsserver/nfs_syscalls.c:319 #7 0xc091d0a5 in syscall (frame=0xef762d38) at ../../../i386/i386/trap.c:1090 #8 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #9 0x00000033 in ?? () (kgdb) [Switching to thread 57 (Thread 100057)] #0 sched_switch (td=0xc512cd20, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc512cd20, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06ed780 in sleepq_catch_signals (wchan=0xc0a681b8) at ../../../kern/subr_sleepqueue.c:417 #4 0xc06edf92 in sleepq_wait_sig (wchan=0xc0a681b8) at ../../../kern/subr_sleepqueue.c:594 #5 0xc0682adf in _cv_wait_sig (cvp=0xc0a681b8, lock=0xc0a681a0) at ../../../kern/kern_condvar.c:245 #6 0xc06f4a0a in kern_select (td=0xc512cd20, nd=5, fd_in=0xbfbfed48, fd_ou=0x0, fd_ex=0x0, tvp=0x0) at ../../../kern/sys_generic.c:788 #7 0xc06f4bfe in select (td=0xc512cd20, uap=0xef65dcfc) at ../../../kern/sys_generic.c:663 #8 0xc091d0a5 in syscall (frame=0xef65dd38) at ../../../i386/i386/trap.c:1090 #9 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #10 0x00000033 in ?? () (kgdb) [Switching to thread 56 (Thread 100069)] #0 sched_switch (td=0xc512c000, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc512c000, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06eda87 in sleepq_wait (wchan=0xd8d6b1e8) at ../../../kern/subr_sleepqueue.c:580 #4 0xc06c5316 in _sleep (ident=0xd8d6b1e8, lock=0xc0a68678, priority=68, wmesg=0xc09a519e "vnread", timo=0) at ../../../kern/kern_synch.c:226 #5 0xc071fc31 in bwait (bp=0xd8d6b1e8, pri=68 'D', wchan=0xc09a519e "vnread") at ../../../kern/vfs_bio.c:3802 #6 0xc08dba5b in vnode_pager_generic_getpages (vp=0xc54ce678, m=0xef6b1c04, bytecount=) at ../../../vm/vnode_pager.c:932 #7 0xc08a927a in ffs_getpages (ap=0xef6b1acc) at ../../../ufs/ffs/ffs_vnops.c:851 #8 0xc0931083 in VOP_GETPAGES_APV (vop=0xc0a2aa00, a=0xef6b1acc) at vnode_if.c:2136 #9 0xc08da14e in vnode_pager_getpages (object=0xc104bc1c, m=0xef6b1c04, count=1, reqpage=0) at vnode_if.h:1129 #10 0xc08c3689 in vm_fault (map=0xc5215e80, vaddr=134512640, fault_type=1 '\001', fault_flags=) at vm_pager.h:130 #11 0xc091cc49 in trap_pfault (frame=0xef6b1d38, usermode=1, eva=134514120) at ../../../i386/i386/trap.c:829 #12 0xc091d56f in trap (frame=0xef6b1d38) at ../../../i386/i386/trap.c:397 #13 0xc0904a2b in calltrap () at ../../../i386/i386/exception.s:159 #14 0x28054616 in ?? () (kgdb) [Switching to thread 55 (Thread 100098)] #0 sched_switch (td=0xc51378c0, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc51378c0, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06ed780 in sleepq_catch_signals (wchan=0xc9131380) at ../../../kern/subr_sleepqueue.c:417 #4 0xc06edeb6 in sleepq_timedwait_sig (wchan=0xc9131380) at ../../../kern/subr_sleepqueue.c:631 #5 0xc06c52e1 in _sleep (ident=0xc9131380, lock=0xc9131380, priority=344, wmesg=0xc098b01a "kqread", timo=1251) at ../../../kern/kern_synch.c:220 #6 0xc06934f7 in kern_kevent (td=0xc51378c0, fd=10, nchanges=0, nevents=1, k_ops=0xef736c40, timeout=0xef736c4c) at ../../../kern/kern_event.c:1292 #7 0xc0693dd4 in kevent (td=0xc51378c0, uap=0xef736cfc) at ../../../kern/kern_event.c:646 #8 0xc091d0a5 in syscall (frame=0xef736d38) at ../../../i386/i386/trap.c:1090 #9 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #10 0x00000033 in ?? () (kgdb) [Switching to thread 54 (Thread 100071)] #0 sched_switch (td=0xc512baf0, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc512baf0, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06eda87 in sleepq_wait (wchan=0xd8f4e300) at ../../../kern/subr_sleepqueue.c:580 #4 0xc06c5316 in _sleep (ident=0xd8f4e300, lock=0xc0a68678, priority=76, wmesg=0xc09926ef "biord", timo=0) at ../../../kern/kern_synch.c:226 #5 0xc071fc31 in bwait (bp=0xd8f4e300, pri=76 'L', wchan=0xc09926ef "biord") at ../../../kern/vfs_bio.c:3802 #6 0xc071fca8 in bufwait (bp=0xd8f4e300) at ../../../kern/vfs_bio.c:3057 #7 0xc08aae3c in ufs_bmaparray (vp=0xc5361228, bn=24, bnp=0xef6b7a60, nbp=0x0, runp=0xef6b7bcc, runb=0xef6b7bd0) at ../../../ufs/ufs/ufs_bmap.c:230 #8 0xc08ab3e9 in ufs_bmap (ap=0xef6b7ac0) at ../../../ufs/ufs/ufs_bmap.c:84 #9 0xc0930d03 in VOP_BMAP_APV (vop=0xc0a2aa00, a=0xef6b7ac0) at vnode_if.c:1717 #10 0xc08d9481 in vnode_pager_haspage (object=0xc5310e0c, pindex=97, before=0xef6b7bd0, after=0xef6b7bcc) at vnode_if.h:912 #11 0xc08c32be in vm_fault (map=0xc5323658, vaddr=134909952, fault_type=1 '\001', fault_flags=) at vm_pager.h:171 #12 0xc091cc49 in trap_pfault (frame=0xef6b7d38, usermode=1, eva=134913578) at ../../../i386/i386/trap.c:829 #13 0xc091d56f in trap (frame=0xef6b7d38) at ../../../i386/i386/trap.c:397 #14 0xc0904a2b in calltrap () at ../../../i386/i386/exception.s:159 #15 0x080a9e2a in ?? () (kgdb) [Switching to thread 53 (Thread 100058)] #0 sched_switch (td=0xc5063d20, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc5063d20, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06eda87 in sleepq_wait (wchan=0xc4f7dd48) at ../../../kern/subr_sleepqueue.c:580 #4 0xc06c5316 in _sleep (ident=0xc4f7dd48, lock=0xc0a5c5c0, priority=80, wmesg=0xc09870fd "devfs", timo=0) at ../../../kern/kern_synch.c:226 #5 0xc06a9ab0 in acquire (lkpp=0xef661a00, extflags=) at ../../../kern/kern_lock.c:151 #6 0xc06aa33a in _lockmgr (lkp=0xc4f7dd48, flags=12290, interlkp=0xc4f7dd78, td=0xc5063d20, file=0xc0994682 "../../../kern/vfs_vnops.c", line=288) at ../../../kern/kern_lock.c:384 #7 0xc072a951 in vop_stdlock (ap=0xef661a50) at ../../../kern/vfs_default.c:305 #8 0xc0931811 in VOP_LOCK1_APV (vop=0xc0a19240, a=0xef661a50) at vnode_if.c:1618 #9 0xc074646a in _vn_lock (vp=0xc4f7dcf0, flags=4098, td=0xc5063d20, file=0xc0994682 "../../../kern/vfs_vnops.c", line=288) at vnode_if.h:851 #10 0xc0746f20 in vn_close (vp=0xc4f7dcf0, flags=3, file_cred=0xc4d0a100, td=0xc5063d20) at ../../../kern/vfs_vnops.c:288 #11 0xc0747078 in vn_closefile (fp=0xc5120c78, td=0xc5063d20) at ../../../kern/vfs_vnops.c:867 #12 0xc064cb80 in devfs_close_f (fp=0xc5120c78, td=0xc5063d20) at ../../../fs/devfs/devfs_vnops.c:479 #13 0xc0689e86 in fdrop (fp=0xc5120c78, td=0xc5063d20) at file.h:299 #14 0xc068b388 in closef (fp=0xc5120c78, td=0xc5063d20) at ../../../kern/kern_descrip.c:2033 #15 0xc068c4d1 in fdfree (td=0xc5063d20) at ../../../kern/kern_descrip.c:1743 #16 0xc0698d2c in exit1 (td=0xc5063d20, rv=512) at ../../../kern/kern_exit.c:283 #17 0xc069a14a in sys_exit (td=) at ../../../kern/kern_exit.c:109 #18 0xc091d0a5 in syscall (frame=0xef661d38) at ../../../i386/i386/trap.c:1090 #19 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #20 0x00000033 in ?? () (kgdb) [Switching to thread 52 (Thread 100055)] #0 sched_switch (td=0xc4e628c0, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc4e628c0, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06eda87 in sleepq_wait (wchan=0xd8ebfe8c) at ../../../kern/subr_sleepqueue.c:580 #4 0xc06c5316 in _sleep (ident=0xd8ebfe8c, lock=0xc0a68678, priority=76, wmesg=0xc09926ef "biord", timo=0) at ../../../kern/kern_synch.c:226 #5 0xc071fc31 in bwait (bp=0xd8ebfe8c, pri=76 'L', wchan=0xc09926ef "biord") at ../../../kern/vfs_bio.c:3802 #6 0xc071fca8 in bufwait (bp=0xd8ebfe8c) at ../../../kern/vfs_bio.c:3057 #7 0xc0726f54 in breadn (vp=0xc5230450, blkno=0, size=2048, rablkno=0x0, rabsize=0x0, cnt=0, cred=0x0, bpp=0xef6559e8) at ../../../kern/vfs_bio.c:806 #8 0xc0726fd0 in bread (vp=0xc5230450, blkno=) at ../../../kern/vfs_bio.c:734 #9 0xc08a2c33 in ffs_blkatoff (vp=0xc5230450, offset=0, res=0x0, bpp=0xef655a88) at ../../../ufs/ffs/ffs_subr.c:87 #10 0xc08af380 in ufs_lookup (ap=0xef655ac0) at ../../../ufs/ufs/ufs_lookup.c:269 #11 0xc0930482 in VOP_CACHEDLOOKUP_APV (vop=0xc0a2aa00, a=0xef655ac0) at vnode_if.c:153 #12 0xc0728569 in vfs_cache_lookup (ap=0xef655b40) at vnode_if.h:83 #13 0xc0931ed1 in VOP_LOOKUP_APV (vop=0xc0a2af20, a=0xef655b40) at vnode_if.c:99 #14 0xc072ea95 in lookup (ndp=0xef655c10) at vnode_if.h:57 #15 0xc072f794 in namei (ndp=0xef655c10) at ../../../kern/vfs_lookup.c:219 #16 0xc073fa82 in kern_unlink (td=0xc4e628c0, path=0xbfbfef59
, pathseg=UIO_USERSPACE) at ../../../kern/vfs_syscalls.c:1670 #17 0xc073fca9 in unlink (td=0xc4e628c0, uap=0xef655cfc) at ../../../kern/vfs_syscalls.c:1653 #18 0xc091d0a5 in syscall (frame=0xef655d38) at ../../../i386/i386/trap.c:1090 #19 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #20 0x00000033 in ?? () (kgdb) [Switching to thread 51 (Thread 100070)] #0 sched_switch (td=0xc512bd20, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc512bd20, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06edf4e in sleepq_timedwait (wchan=0xc0a5b060) at ../../../kern/subr_sleepqueue.c:615 #4 0xc06c52f4 in _sleep (ident=0xc0a5b060, lock=0xc0a5b048, priority=0, wmesg=0xc098792e "-", timo=3750) at ../../../kern/kern_synch.c:222 #5 0xc0680cf7 in acct_thread (dummy=0x0) at ../../../kern/kern_acct.c:644 #6 0xc069a351 in fork_exit (callout=0xc0680900 , arg=0x0, frame=0xef6b4d38) at ../../../kern/kern_fork.c:804 #7 0xc0904aa0 in fork_trampoline () at ../../../i386/i386/exception.s:264 (kgdb) [Switching to thread 50 (Thread 100054)] #0 sched_switch (td=0xc50ed000, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc50ed000, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06eda87 in sleepq_wait (wchan=0xc5087800) at ../../../kern/subr_sleepqueue.c:580 #4 0xc06c5316 in _sleep (ident=0xc5087800, lock=0xc5087820, priority=588, wmesg=0xc097a234 "mdwait", timo=0) at ../../../kern/kern_synch.c:226 #5 0xc05c644b in md_kthread (arg=0xc5087800) at ../../../dev/md/md.c:708 #6 0xc069a351 in fork_exit (callout=0xc05c62dc , arg=0xc5087800, frame=0xef651d38) at ../../../kern/kern_fork.c:804 #7 0xc0904aa0 in fork_trampoline () at ../../../i386/i386/exception.s:264 (kgdb) [Switching to thread 49 (Thread 100062)] #0 sched_switch (td=0xc5140000, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc5140000, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06ed780 in sleepq_catch_signals (wchan=0xc0a681b8) at ../../../kern/subr_sleepqueue.c:417 #4 0xc06edf92 in sleepq_wait_sig (wchan=0xc0a681b8) at ../../../kern/subr_sleepqueue.c:594 #5 0xc0682adf in _cv_wait_sig (cvp=0xc0a681b8, lock=0xc0a681a0) at ../../../kern/kern_condvar.c:245 #6 0xc06f4a0a in kern_select (td=0xc5140000, nd=5, fd_in=0xbfbfedf8, fd_ou=0x0, fd_ex=0x0, tvp=0x0) at ../../../kern/sys_generic.c:788 #7 0xc06f4bfe in select (td=0xc5140000, uap=0xef67dcfc) at ../../../kern/sys_generic.c:663 #8 0xc091d0a5 in syscall (frame=0xef67dd38) at ../../../i386/i386/trap.c:1090 #9 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #10 0x00000033 in ?? () (kgdb) [Switching to thread 48 (Thread 100046)] #0 sched_switch (td=0xc4e62d20, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc4e62d20, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06edf4e in sleepq_timedwait (wchan=0xc0a74828) at ../../../kern/subr_sleepqueue.c:615 #4 0xc06c52f4 in _sleep (ident=0xc0a74828, lock=0xc0a747e8, priority=68, wmesg=0xc09a19b5 "sdflush", timo=250) at ../../../kern/kern_synch.c:222 #5 0xc089cf1f in softdep_flush () at ../../../ufs/ffs/ffs_softdep.c:770 #6 0xc069a351 in fork_exit (callout=0xc089cb5e , arg=0x0, frame=0xed446d38) at ../../../kern/kern_fork.c:804 #7 0xc0904aa0 in fork_trampoline () at ../../../i386/i386/exception.s:264 (kgdb) [Switching to thread 47 (Thread 100045)] #0 sched_switch (td=0xc5062000, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc5062000, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06edf4e in sleepq_timedwait (wchan=0xc50a1000) at ../../../kern/subr_sleepqueue.c:615 #4 0xc06c52f4 in _sleep (ident=0xc50a1000, lock=0xc0a688d8, priority=592, wmesg=0xc09942db "vlruwt", timo=250) at ../../../kern/kern_synch.c:222 #5 0xc073b638 in vnlru_proc () at ../../../kern/vfs_subr.c:737 #6 0xc069a351 in fork_exit (callout=0xc073b4e5 , arg=0x0, frame=0xed443d38) at ../../../kern/kern_fork.c:804 #7 0xc0904aa0 in fork_trampoline () at ../../../i386/i386/exception.s:264 (kgdb) [Switching to thread 46 (Thread 100044)] #0 sched_switch (td=0xc5062230, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc5062230, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06eda87 in sleepq_wait (wchan=0xc0a5cd8c) at ../../../kern/subr_sleepqueue.c:580 #4 0xc06c5316 in _sleep (ident=0xc0a5cd8c, lock=0xc0a68904, priority=104, wmesg=0xc0994294 "syncer", timo=0) at ../../../kern/kern_synch.c:226 #5 0xc073ac7c in sched_sync () at ../../../kern/vfs_subr.c:1808 #6 0xc069a351 in fork_exit (callout=0xc073a365 , arg=0x0, frame=0xed440d38) at ../../../kern/kern_fork.c:804 #7 0xc0904aa0 in fork_trampoline () at ../../../i386/i386/exception.s:264 (kgdb) [Switching to thread 45 (Thread 100043)] #0 sched_switch (td=0xc5062460, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc5062460, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06edf4e in sleepq_timedwait (wchan=0xc0a68624) at ../../../kern/subr_sleepqueue.c:615 #4 0xc06c52f4 in _sleep (ident=0xc0a68624, lock=0xc0a68628, priority=68, wmesg=0xc0992acc "psleep", timo=250) at ../../../kern/kern_synch.c:222 #5 0xc0724a01 in buf_daemon () at ../../../kern/vfs_bio.c:2115 #6 0xc069a351 in fork_exit (callout=0xc072470b , arg=0x0, frame=0xed43dd38) at ../../../kern/kern_fork.c:804 #7 0xc0904aa0 in fork_trampoline () at ../../../i386/i386/exception.s:264 (kgdb) [Switching to thread 44 (Thread 100042)] #0 sched_switch (td=0xc5062690, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc5062690, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06edf4e in sleepq_timedwait (wchan=0xc0a75420) at ../../../kern/subr_sleepqueue.c:615 #4 0xc06c52f4 in _sleep (ident=0xc0a75420, lock=0xc0a74fc4, priority=0, wmesg=0xc09a4f8b "pgzero", timo=75000) at ../../../kern/kern_synch.c:222 #5 0xc08d8a06 in vm_pagezero (arg=0x0) at ../../../vm/vm_zeroidle.c:136 #6 0xc069a351 in fork_exit (callout=0xc08d892b , arg=0x0, frame=0xed43ad38) at ../../../kern/kern_fork.c:804 #7 0xc0904aa0 in fork_trampoline () at ../../../i386/i386/exception.s:264 (kgdb) [Switching to thread 43 (Thread 100041)] #0 sched_switch (td=0xc50628c0, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc50628c0, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06eda87 in sleepq_wait (wchan=0xc0a75038) at ../../../kern/subr_sleepqueue.c:580 #4 0xc06c5316 in _sleep (ident=0xc0a75038, lock=0xc0a7503c, priority=104, wmesg=0xc0992acc "psleep", timo=0) at ../../../kern/kern_synch.c:226 #5 0xc08d469b in vm_daemon () at ../../../vm/vm_pageout.c:1536 #6 0xc069a351 in fork_exit (callout=0xc08d4623 , arg=0x0, frame=0xed437d38) at ../../../kern/kern_fork.c:804 #7 0xc0904aa0 in fork_trampoline () at ../../../i386/i386/exception.s:264 (kgdb) [Switching to thread 42 (Thread 100040)] #0 sched_switch (td=0xc5062af0, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc5062af0, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06edf4e in sleepq_timedwait (wchan=0xc0a75000) at ../../../kern/subr_sleepqueue.c:615 #4 0xc06c52f4 in _sleep (ident=0xc0a75000, lock=0xc0a74fc4, priority=68, wmesg=0xc0992acc "psleep", timo=1250) at ../../../kern/kern_synch.c:222 #5 0xc08d5017 in vm_pageout () at ../../../vm/vm_pageout.c:1476 #6 0xc069a351 in fork_exit (callout=0xc08d4d2c , arg=0x0, frame=0xed434d38) at ../../../kern/kern_fork.c:804 #7 0xc0904aa0 in fork_trampoline () at ../../../i386/i386/exception.s:264 (kgdb) [Switching to thread 41 (Thread 100039)] #0 sched_switch (td=0xc5062d20, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc5062d20, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06eda87 in sleepq_wait (wchan=0xc4e97870) at ../../../kern/subr_sleepqueue.c:580 #4 0xc068249f in _cv_wait (cvp=0xc4e97870, lock=0xc4e97858) at ../../../kern/kern_condvar.c:134 #5 0xc08ecd9d in ipmi_dequeue_request (sc=0xc4e97800) at ../../../dev/ipmi/ipmi.c:566 #6 0xc08ef127 in kcs_loop (arg=0xc4e97800) at ../../../dev/ipmi/ipmi_kcs.c:458 #7 0xc069a351 in fork_exit (callout=0xc08eedc8 , arg=0xc4e97800, frame=0xed431d38) at ../../../kern/kern_fork.c:804 #8 0xc0904aa0 in fork_trampoline () at ../../../i386/i386/exception.s:264 (kgdb) [Switching to thread 40 (Thread 100038)] #0 sched_switch (td=0xc5063000, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc5063000, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06eda87 in sleepq_wait (wchan=0xc0a6a6b4) at ../../../kern/subr_sleepqueue.c:580 #4 0xc06c5316 in _sleep (ident=0xc0a6a6b4, lock=0xc0a6a5bc, priority=0, wmesg=0xc0997cbe "waiting_for_work", timo=0) at ../../../kern/kern_synch.c:226 #5 0xc0795e8c in sctp_iterator_thread (v=0x0) at ../../../netinet/sctp_bsd_addr.c:95 #6 0xc069a351 in fork_exit (callout=0xc0795e0d , arg=0x0, frame=0xed42ed38) at ../../../kern/kern_fork.c:804 #7 0xc0904aa0 in fork_trampoline () at ../../../i386/i386/exception.s:264 (kgdb) [Switching to thread 39 (Thread 100037)] #0 fork_trampoline () at ../../../i386/i386/exception.s:261 261 pushl %esp /* trapframe pointer */ Current language: auto; currently asm (kgdb) #0 fork_trampoline () at ../../../i386/i386/exception.s:261 (kgdb) [Switching to thread 38 (Thread 100036)] #0 sched_switch (td=0xc4e61000, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); Current language: auto; currently c (kgdb) #0 sched_switch (td=0xc4e61000, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc069dc33 in ithread_loop (arg=0xc4e9d1a0) at ../../../kern/kern_intr.c:1189 #3 0xc069a351 in fork_exit (callout=0xc069d937 , arg=0xc4e9d1a0, frame=0xed425d38) at ../../../kern/kern_fork.c:804 #4 0xc0904aa0 in fork_trampoline () at ../../../i386/i386/exception.s:264 (kgdb) [Switching to thread 37 (Thread 100035)] #0 sched_switch (td=0xc4e61230, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc4e61230, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc069dc33 in ithread_loop (arg=0xc4e98bb0) at ../../../kern/kern_intr.c:1189 #3 0xc069a351 in fork_exit (callout=0xc069d937 , arg=0xc4e98bb0, frame=0xed422d38) at ../../../kern/kern_fork.c:804 #4 0xc0904aa0 in fork_trampoline () at ../../../i386/i386/exception.s:264 (kgdb) [Switching to thread 36 (Thread 100034)] #0 sched_switch (td=0xc4e61460, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc4e61460, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06edf4e in sleepq_timedwait (wchan=0xc4e0f23c) at ../../../kern/subr_sleepqueue.c:615 #4 0xc06c52f4 in _sleep (ident=0xc4e0f23c, lock=0xc4e0f2f0, priority=76, wmesg=0xc098792e "-", timo=250) at ../../../kern/kern_synch.c:222 #5 0xc08ea2f9 in fdc_thread (arg=0xc4e0f200) at ../../../dev/fdc/fdc.c:807 #6 0xc069a351 in fork_exit (callout=0xc08e9f44 , arg=0xc4e0f200, frame=0xed41fd38) at ../../../kern/kern_fork.c:804 #7 0xc0904aa0 in fork_trampoline () at ../../../i386/i386/exception.s:264 (kgdb) [Switching to thread 35 (Thread 100033)] #0 fork_trampoline () at ../../../i386/i386/exception.s:261 261 pushl %esp /* trapframe pointer */ Current language: auto; currently asm (kgdb) #0 fork_trampoline () at ../../../i386/i386/exception.s:261 (kgdb) [Switching to thread 34 (Thread 100032)] #0 fork_trampoline () at ../../../i386/i386/exception.s:261 261 pushl %esp /* trapframe pointer */ (kgdb) #0 fork_trampoline () at ../../../i386/i386/exception.s:261 (kgdb) [Switching to thread 33 (Thread 100031)] #0 sched_switch (td=0xc4e61af0, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); Current language: auto; currently c (kgdb) #0 sched_switch (td=0xc4e61af0, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06f19e5 in turnstile_wait (ts=0xc53204b0, owner=0xc54e1000, queue=) at ../../../kern/subr_turnstile.c:748 #3 0xc06b04d2 in _mtx_lock_sleep (m=0xcb920900, tid=3303414512, opts=0, file=0x0, line=0) at ../../../kern/kern_mutex.c:420 #4 0xc08764a8 in svc_vc_soupcall (so=0xc6804000, arg=0xcb920900, waitflag=1) at ../../../rpc/svc_vc.c:742 #5 0xc070e0bd in sowakeup (so=0xc6804000, sb=0xc6804050) at ../../../kern/uipc_sockbuf.c:192 #6 0xc07e7b04 in tcp_do_segment (m=0xcab7e200, th=0xc50e1824, so=0xc6804000, tp=0xc76521d0, drop_hdrlen=52, tlen=44) at ../../../netinet/tcp_input.c:1216 #7 0xc07ea0e4 in tcp_input (m=0xcab7e200, off0=20) at ../../../netinet/tcp_input.c:846 #8 0xc078b314 in ip_input (m=0xcab7e200) at ../../../netinet/ip_input.c:665 #9 0xc07690f9 in netisr_dispatch (num=2, m=0xcab7e200) at ../../../net/netisr.c:185 #10 0xc075d629 in ether_demux (ifp=0xc4e67000, m=0xcab7e200) at ../../../net/if_ethersubr.c:834 #11 0xc075d9fd in ether_input (ifp=0xc4e67000, m=0xcab7e200) at ../../../net/if_ethersubr.c:692 #12 0xc055d4b3 in em_rxeof (adapter=0xc4e02000, count=97) at ../../../dev/e1000/if_em.c:4511 #13 0xc055e092 in em_handle_rxtx (context=0xc4e02000, pending=1) at ../../../dev/e1000/if_em.c:1676 #14 0xc06ef030 in taskqueue_run (queue=0xc4e5f880) at ../../../kern/subr_taskqueue.c:282 #15 0xc06ef222 in taskqueue_thread_loop (arg=0xc4e02370) at ../../../kern/subr_taskqueue.c:401 #16 0xc069a351 in fork_exit (callout=0xc06ef16d , arg=0xc4e02370, frame=0xed3c4d38) at ../../../kern/kern_fork.c:804 #17 0xc0904aa0 in fork_trampoline () at ../../../i386/i386/exception.s:264 (kgdb) [Switching to thread 32 (Thread 100030)] #0 sched_switch (td=0xc4e61d20, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc4e61d20, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc069dc33 in ithread_loop (arg=0xc4e631c0) at ../../../kern/kern_intr.c:1189 #3 0xc069a351 in fork_exit (callout=0xc069d937 , arg=0xc4e631c0, frame=0xed38cd38) at ../../../kern/kern_fork.c:804 #4 0xc0904aa0 in fork_trampoline () at ../../../i386/i386/exception.s:264 (kgdb) [Switching to thread 31 (Thread 100029)] #0 sched_switch (td=0xc4e62000, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc4e62000, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06eda87 in sleepq_wait (wchan=0xc0a5a594) at ../../../kern/subr_sleepqueue.c:580 #4 0xc06c5316 in _sleep (ident=0xc0a5a594, lock=0x0, priority=92, wmesg=0xc0986926 "usbtsk", timo=0) at ../../../kern/kern_synch.c:226 #5 0xc06446f3 in usb_task_thread (arg=0xc0a5a594) at ../../../dev/usb/usb.c:475 #6 0xc069a351 in fork_exit (callout=0xc0644676 , arg=0xc0a5a594, frame=0xe5389d38) at ../../../kern/kern_fork.c:804 #7 0xc0904aa0 in fork_trampoline () at ../../../i386/i386/exception.s:264 (kgdb) [Switching to thread 30 (Thread 100028)] #0 sched_switch (td=0xc4e62230, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc4e62230, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06eda87 in sleepq_wait (wchan=0xc0a5a580) at ../../../kern/subr_sleepqueue.c:580 #4 0xc06c5316 in _sleep (ident=0xc0a5a580, lock=0x0, priority=92, wmesg=0xc0986926 "usbtsk", timo=0) at ../../../kern/kern_synch.c:226 #5 0xc06446f3 in usb_task_thread (arg=0xc0a5a580) at ../../../dev/usb/usb.c:475 #6 0xc069a351 in fork_exit (callout=0xc0644676 , arg=0xc0a5a580, frame=0xe5386d38) at ../../../kern/kern_fork.c:804 #7 0xc0904aa0 in fork_trampoline () at ../../../i386/i386/exception.s:264 (kgdb) [Switching to thread 29 (Thread 100027)] #0 sched_switch (td=0xc4e62460, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc4e62460, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06edf4e in sleepq_timedwait (wchan=0xc4e10210) at ../../../kern/subr_sleepqueue.c:615 #4 0xc06c52f4 in _sleep (ident=0xc4e10210, lock=0x0, priority=92, wmesg=0xc0986934 "usbevt", timo=15000) at ../../../kern/kern_synch.c:222 #5 0xc0644835 in usb_event_thread (arg=0xc4e44c00) at ../../../dev/usb/usb.c:445 #6 0xc069a351 in fork_exit (callout=0xc064474d , arg=0xc4e44c00, frame=0xe5383d38) at ../../../kern/kern_fork.c:804 #7 0xc0904aa0 in fork_trampoline () at ../../../i386/i386/exception.s:264 (kgdb) [Switching to thread 28 (Thread 100026)] #0 fork_trampoline () at ../../../i386/i386/exception.s:261 261 pushl %esp /* trapframe pointer */ Current language: auto; currently asm (kgdb) #0 fork_trampoline () at ../../../i386/i386/exception.s:261 (kgdb) [Switching to thread 27 (Thread 100025)] #0 sched_switch (td=0xc4d798c0, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); Current language: auto; currently c (kgdb) #0 sched_switch (td=0xc4d798c0, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc069dc33 in ithread_loop (arg=0xc4e49aa0) at ../../../kern/kern_intr.c:1189 #3 0xc069a351 in fork_exit (callout=0xc069d937 , arg=0xc4e49aa0, frame=0xe537cd38) at ../../../kern/kern_fork.c:804 #4 0xc0904aa0 in fork_trampoline () at ../../../i386/i386/exception.s:264 (kgdb) [Switching to thread 26 (Thread 100024)] #0 fork_trampoline () at ../../../i386/i386/exception.s:261 261 pushl %esp /* trapframe pointer */ Current language: auto; currently asm (kgdb) #0 fork_trampoline () at ../../../i386/i386/exception.s:261 (kgdb) [Switching to thread 25 (Thread 100023)] #0 fork_trampoline () at ../../../i386/i386/exception.s:261 261 pushl %esp /* trapframe pointer */ (kgdb) #0 fork_trampoline () at ../../../i386/i386/exception.s:261 (kgdb) [Switching to thread 24 (Thread 100022)] #0 sched_switch (td=0xc4e0d000, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); Current language: auto; currently c (kgdb) #0 sched_switch (td=0xc4e0d000, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06eda87 in sleepq_wait (wchan=0xc4d77800) at ../../../kern/subr_sleepqueue.c:580 #4 0xc06c5316 in _sleep (ident=0xc4d77800, lock=0xc4d7781c, priority=0, wmesg=0xc098792e "-", timo=0) at ../../../kern/kern_synch.c:226 #5 0xc06ef26a in taskqueue_thread_loop (arg=0xc0a6731c) at ../../../kern/subr_taskqueue.c:95 #6 0xc069a351 in fork_exit (callout=0xc06ef16d , arg=0xc0a6731c, frame=0xe5348d38) at ../../../kern/kern_fork.c:804 #7 0xc0904aa0 in fork_trampoline () at ../../../i386/i386/exception.s:264 (kgdb) [Switching to thread 23 (Thread 100021)] #0 sched_switch (td=0xc4e0d230, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc4e0d230, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc069dc33 in ithread_loop (arg=0xc4df83b0) at ../../../kern/kern_intr.c:1189 #3 0xc069a351 in fork_exit (callout=0xc069d937 , arg=0xc4df83b0, frame=0xe5345d38) at ../../../kern/kern_fork.c:804 #4 0xc0904aa0 in fork_trampoline () at ../../../i386/i386/exception.s:264 (kgdb) [Switching to thread 22 (Thread 100020)] #0 sched_switch (td=0xc4e0d460, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc4e0d460, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06eda87 in sleepq_wait (wchan=0xc4d77a00) at ../../../kern/subr_sleepqueue.c:580 #4 0xc06c5316 in _sleep (ident=0xc4d77a00, lock=0xc4d77a1c, priority=0, wmesg=0xc098792e "-", timo=0) at ../../../kern/kern_synch.c:226 #5 0xc06ef26a in taskqueue_thread_loop (arg=0xc0a5b198) at ../../../kern/subr_taskqueue.c:95 #6 0xc069a351 in fork_exit (callout=0xc06ef16d , arg=0xc0a5b198, frame=0xe5342d38) at ../../../kern/kern_fork.c:804 #7 0xc0904aa0 in fork_trampoline () at ../../../i386/i386/exception.s:264 (kgdb) [Switching to thread 21 (Thread 100019)] #0 sched_switch (td=0xc4e0d690, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc4e0d690, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc069dc33 in ithread_loop (arg=0xc4df83e0) at ../../../kern/kern_intr.c:1189 #3 0xc069a351 in fork_exit (callout=0xc069d937 , arg=0xc4df83e0, frame=0xe533fd38) at ../../../kern/kern_fork.c:804 #4 0xc0904aa0 in fork_trampoline () at ../../../i386/i386/exception.s:264 (kgdb) [Switching to thread 20 (Thread 100018)] #0 sched_switch (td=0xc4e0d8c0, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc4e0d8c0, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06eda87 in sleepq_wait (wchan=0xc0a3c654) at ../../../kern/subr_sleepqueue.c:580 #4 0xc06c5316 in _sleep (ident=0xc0a3c654, lock=0xc0a3c66c, priority=76, wmesg=0xc09537e9 "ccb_scanq", timo=0) at ../../../kern/kern_synch.c:226 #5 0xc0469d2a in xpt_scanner_thread (dummy=0x0) at ../../../cam/cam_xpt.c:1418 #6 0xc069a351 in fork_exit (callout=0xc0469ced , arg=0x0, frame=0xe533cd38) at ../../../kern/kern_fork.c:804 #7 0xc0904aa0 in fork_trampoline () at ../../../i386/i386/exception.s:264 (kgdb) [Switching to thread 19 (Thread 100017)] #0 sched_switch (td=0xc4e0daf0, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc4e0daf0, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06eda87 in sleepq_wait (wchan=0xc4d77c00) at ../../../kern/subr_sleepqueue.c:580 #4 0xc06c5316 in _sleep (ident=0xc4d77c00, lock=0xc4d77c1c, priority=0, wmesg=0xc098792e "-", timo=0) at ../../../kern/kern_synch.c:226 #5 0xc06ef26a in taskqueue_thread_loop (arg=0xc0a3f304) at ../../../kern/subr_taskqueue.c:95 #6 0xc069a351 in fork_exit (callout=0xc06ef16d , arg=0xc0a3f304, frame=0xe5339d38) at ../../../kern/kern_fork.c:804 #7 0xc0904aa0 in fork_trampoline () at ../../../i386/i386/exception.s:264 (kgdb) [Switching to thread 18 (Thread 100016)] #0 sched_switch (td=0xc4d35230, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc4d35230, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06eda87 in sleepq_wait (wchan=0xc4d77c00) at ../../../kern/subr_sleepqueue.c:580 #4 0xc06c5316 in _sleep (ident=0xc4d77c00, lock=0xc4d77c1c, priority=0, wmesg=0xc098792e "-", timo=0) at ../../../kern/kern_synch.c:226 #5 0xc06ef26a in taskqueue_thread_loop (arg=0xc0a3f304) at ../../../kern/subr_taskqueue.c:95 #6 0xc069a351 in fork_exit (callout=0xc06ef16d , arg=0xc0a3f304, frame=0xe5336d38) at ../../../kern/kern_fork.c:804 #7 0xc0904aa0 in fork_trampoline () at ../../../i386/i386/exception.s:264 (kgdb) [Switching to thread 17 (Thread 100015)] #0 sched_switch (td=0xc4d35460, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc4d35460, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06eda87 in sleepq_wait (wchan=0xc4d77c00) at ../../../kern/subr_sleepqueue.c:580 #4 0xc06c5316 in _sleep (ident=0xc4d77c00, lock=0xc4d77c1c, priority=0, wmesg=0xc098792e "-", timo=0) at ../../../kern/kern_synch.c:226 #5 0xc06ef26a in taskqueue_thread_loop (arg=0xc0a3f304) at ../../../kern/subr_taskqueue.c:95 #6 0xc069a351 in fork_exit (callout=0xc06ef16d , arg=0xc0a3f304, frame=0xe5333d38) at ../../../kern/kern_fork.c:804 #7 0xc0904aa0 in fork_trampoline () at ../../../i386/i386/exception.s:264 (kgdb) [Switching to thread 16 (Thread 100014)] #0 sched_switch (td=0xc4d35690, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc4d35690, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc069dc33 in ithread_loop (arg=0xc4df8460) at ../../../kern/kern_intr.c:1189 #3 0xc069a351 in fork_exit (callout=0xc069d937 , arg=0xc4df8460, frame=0xe5330d38) at ../../../kern/kern_fork.c:804 #4 0xc0904aa0 in fork_trampoline () at ../../../i386/i386/exception.s:264 (kgdb) [Switching to thread 15 (Thread 100013)] #0 sched_switch (td=0xc4d358c0, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc4d358c0, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc069dc33 in ithread_loop (arg=0xc4df8470) at ../../../kern/kern_intr.c:1189 #3 0xc069a351 in fork_exit (callout=0xc069d937 , arg=0xc4df8470, frame=0xe532dd38) at ../../../kern/kern_fork.c:804 #4 0xc0904aa0 in fork_trampoline () at ../../../i386/i386/exception.s:264 (kgdb) [Switching to thread 14 (Thread 100012)] #0 sched_switch (td=0xc4d35af0, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc4d35af0, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06edf4e in sleepq_timedwait (wchan=0xc0a5cd94) at ../../../kern/subr_sleepqueue.c:615 #4 0xc06c52f4 in _sleep (ident=0xc0a5cd94, lock=0x0, priority=0, wmesg=0xc098792e "-", timo=25) at ../../../kern/kern_synch.c:222 #5 0xc06c53f8 in pause (wmesg=0xc098792e "-", timo=25) at ../../../kern/kern_synch.c:330 #6 0xc060edae in random_kthread (arg=0x0) at ../../../dev/random/randomdev_soft.c:281 #7 0xc069a351 in fork_exit (callout=0xc060eb97 , arg=0x0, frame=0xe532ad38) at ../../../kern/kern_fork.c:804 #8 0xc0904aa0 in fork_trampoline () at ../../../i386/i386/exception.s:264 (kgdb) [Switching to thread 13 (Thread 100011)] #0 sched_switch (td=0xc4d35d20, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc4d35d20, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06edf4e in sleepq_timedwait (wchan=0xc0a5a94c) at ../../../kern/subr_sleepqueue.c:615 #4 0xc06c52f4 in _sleep (ident=0xc0a5a94c, lock=0xc0a5a868, priority=588, wmesg=0xc098792e "-", timo=25) at ../../../kern/kern_synch.c:222 #5 0xc06674c1 in g_io_schedule_down (tp=0xc4d35d20) at ../../../geom/geom_io.c:487 #6 0xc0667b88 in g_down_procbody () at ../../../geom/geom_kern.c:118 #7 0xc069a351 in fork_exit (callout=0xc0667b1a , arg=0x0, frame=0xe5323d38) at ../../../kern/kern_fork.c:804 #8 0xc0904aa0 in fork_trampoline () at ../../../i386/i386/exception.s:264 (kgdb) [Switching to thread 12 (Thread 100010)] #0 sched_switch (td=0xc4d79000, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc4d79000, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06edf4e in sleepq_timedwait (wchan=0xc0a5a948) at ../../../kern/subr_sleepqueue.c:615 #4 0xc06c52f4 in _sleep (ident=0xc0a5a948, lock=0xc0a5a8a8, priority=588, wmesg=0xc098792e "-", timo=25) at ../../../kern/kern_synch.c:222 #5 0xc06677b7 in g_io_schedule_up (tp=0xc4d79000) at ../../../geom/geom_io.c:592 #6 0xc0667a6a in g_up_procbody () at ../../../geom/geom_kern.c:95 #7 0xc069a351 in fork_exit (callout=0xc06679fc , arg=0x0, frame=0xe5320d38) at ../../../kern/kern_fork.c:804 #8 0xc0904aa0 in fork_trampoline () at ../../../i386/i386/exception.s:264 (kgdb) [Switching to thread 11 (Thread 100009)] #0 sched_switch (td=0xc4d79230, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc4d79230, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06edf4e in sleepq_timedwait (wchan=0xc0a5a940) at ../../../kern/subr_sleepqueue.c:615 #4 0xc06c52f4 in _sleep (ident=0xc0a5a940, lock=0x0, priority=76, wmesg=0xc098792e "-", timo=25) at ../../../kern/kern_synch.c:222 #5 0xc0667b18 in g_event_procbody () at ../../../geom/geom_kern.c:142 #6 0xc069a351 in fork_exit (callout=0xc0667a6c , arg=0x0, frame=0xe531dd38) at ../../../kern/kern_fork.c:804 #7 0xc0904aa0 in fork_trampoline () at ../../../i386/i386/exception.s:264 (kgdb) [Switching to thread 10 (Thread 100008)] #0 fork_trampoline () at ../../../i386/i386/exception.s:261 261 pushl %esp /* trapframe pointer */ Current language: auto; currently asm (kgdb) #0 fork_trampoline () at ../../../i386/i386/exception.s:261 (kgdb) [Switching to thread 9 (Thread 100007)] #0 sched_switch (td=0xc4d33000, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); Current language: auto; currently c (kgdb) #0 sched_switch (td=0xc4d33000, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc069dc33 in ithread_loop (arg=0xc4d30220) at ../../../kern/kern_intr.c:1189 #3 0xc069a351 in fork_exit (callout=0xc069d937 , arg=0xc4d30220, frame=0xe5317d38) at ../../../kern/kern_fork.c:804 #4 0xc0904aa0 in fork_trampoline () at ../../../i386/i386/exception.s:264 (kgdb) [Switching to thread 8 (Thread 100006)] #0 sched_switch (td=0xc4d33230, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc4d33230, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc069dc33 in ithread_loop (arg=0xc4d30230) at ../../../kern/kern_intr.c:1189 #3 0xc069a351 in fork_exit (callout=0xc069d937 , arg=0xc4d30230, frame=0xe5314d38) at ../../../kern/kern_fork.c:804 #4 0xc0904aa0 in fork_trampoline () at ../../../i386/i386/exception.s:264 (kgdb) [Switching to thread 7 (Thread 100005)] #0 sched_switch (td=0xc4d33460, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc4d33460, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc0912dd6 in ipi_bitmap_handler (frame={tf_fs = -477102072, tf_es = -1066729432, tf_ds = 40, tf_edi = 0, tf_esi = 15, tf_ebp = -477041472, tf_isp = -477041492, tf_ebx = 15, tf_edx = -1062867520, tf_ecx = 16, tf_eax = 1, tf_trapno = 0, tf_err = 0, tf_eip = -1064242330, tf_cs = 32, tf_eflags = 514, tf_esp = -477041420, tf_ss = -1066548796}) at ../../../i386/i386/mp_machdep.c:1154 #3 0xc090511e in Xipi_intr_bitmap_handler () at apic_vector.s:284 #4 0x00000202 in ?? () (kgdb) [Switching to thread 6 (Thread 100004)] #0 sched_switch (td=0xc4d33690, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc4d33690, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xe390bca8 in ?? () #2 0xc4d33690 in ?? () #3 0x00000010 in ?? () #4 0x00000010 in ?? () #5 0x00000246 in ?? () #6 0x00000000 in ?? () #7 0x00000000 in ?? () #8 0xc4d33690 in ?? () #9 0x00000001 in ?? () #10 0xe390bcc0 in ?? () #11 0xc090e0c8 in spinlock_enter () at ../../../i386/i386/machdep.c:2420 #12 0xc06dbf38 in sched_idletd (dummy=0x0) at ../../../kern/sched_ule.c:759 #13 0xc069a351 in fork_exit (callout=0xc06dbeed , arg=0x0, frame=0xe390bd38) at ../../../kern/kern_fork.c:804 #14 0xc0904aa0 in fork_trampoline () at ../../../i386/i386/exception.s:264 (kgdb) [Switching to thread 5 (Thread 100003)] #0 sched_switch (td=0xc4d338c0, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc4d338c0, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xe3908ca8 in ?? () #2 0xc4d338c0 in ?? () #3 0x00000010 in ?? () #4 0x00000010 in ?? () #5 0x00000246 in ?? () #6 0x00000000 in ?? () #7 0x00000000 in ?? () #8 0xc4d338c0 in ?? () #9 0x00000002 in ?? () #10 0xe3908cc0 in ?? () #11 0x00000246 in ?? () #12 0xe3908cf4 in ?? () #13 0xc06dbf38 in sched_idletd (dummy=0xc0a65240) at ../../../kern/sched_ule.c:759 (kgdb) [Switching to thread 4 (Thread 100002)] #0 sched_switch (td=0xc4d33bac, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc4d33bac, newtd=) at ../../../kern/sched_ule.c:1944 #1 0x00000046 in ?? () #2 0xc4d33bac in ?? () #3 0xe3905c20 in ?? () #4 0xc0681d50 in statclock (usermode=-992789776) at ../../../kern/kern_clock.c:534 (kgdb) [Switching to thread 3 (Thread 100001)] #0 sched_switch (td=0xc4d33d20, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc4d33d20, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06ed780 in sleepq_catch_signals (wchan=0xc4d31ae0) at ../../../kern/subr_sleepqueue.c:417 #4 0xc06edf92 in sleepq_wait_sig (wchan=0xc4d31ae0) at ../../../kern/subr_sleepqueue.c:594 #5 0xc06c5307 in _sleep (ident=0xc4d31ae0, lock=0xc4d31b70, priority=348, wmesg=0xc09a6e08 "wait", timo=0) at ../../../kern/kern_synch.c:224 #6 0xc0698666 in kern_wait (td=0xc4d33d20, pid=-1, status=0xe3901c2c, options=) at ../../../kern/kern_exit.c:897 #7 0xc0698700 in wait4 (td=0xc4d33d20, uap=0xe3901cfc) at ../../../kern/kern_exit.c:683 #8 0xc091d0a5 in syscall (frame=0xe3901d38) at ../../../i386/i386/trap.c:1090 #9 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #10 0x00000033 in ?? () (kgdb) [Switching to thread 2 (Thread 100000)] #0 sched_switch (td=0xc4d35000, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc4d35000, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06eda87 in sleepq_wait (wchan=0xc0a74264) at ../../../kern/subr_sleepqueue.c:580 #4 0xc068249f in _cv_wait (cvp=0xc0a74264, lock=0xc0a74244) at ../../../kern/kern_condvar.c:134 #5 0xc08830ff in audit_worker (arg=0x0) at ../../../security/audit/audit_worker.c:403 #6 0xc069a351 in fork_exit (callout=0xc0883090 , arg=0x0, frame=0xe38fed38) at ../../../kern/kern_fork.c:804 #7 0xc0904aa0 in fork_trampoline () at ../../../i386/i386/exception.s:264 (kgdb) [Switching to thread 1 (Thread 0)] #0 sched_switch (td=0xc0a5acc0, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc0a5acc0, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06edf4e in sleepq_timedwait (wchan=0xc0a5aa00) at ../../../kern/subr_sleepqueue.c:615 #4 0xc06c52f4 in _sleep (ident=0xc0a5aa00, lock=0x0, priority=68, wmesg=0xc098ee5d "sched", timo=2500) at ../../../kern/kern_synch.c:222 #5 0xc08c64ea in scheduler (dummy=0x0) at ../../../vm/vm_glue.c:733 #6 0xc067f35a in mi_startup () at ../../../kern/init_main.c:251 #7 0xc045c895 in begin () at ../../../i386/i386/locore.s:328 (kgdb) -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-net@FreeBSD.ORG Mon Feb 2 19:44:47 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2AD4910657A3 for ; Mon, 2 Feb 2009 19:44:47 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.30]) by mx1.freebsd.org (Postfix) with ESMTP id DFB1A8FC1C for ; Mon, 2 Feb 2009 19:44:46 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: by yx-out-2324.google.com with SMTP id 8so640142yxb.13 for ; Mon, 02 Feb 2009 11:44:46 -0800 (PST) Received: by 10.64.143.4 with SMTP id q4mr2831354qbd.67.1233603885995; Mon, 02 Feb 2009 11:44:45 -0800 (PST) Received: from ?10.0.1.199? ([72.14.241.159]) by mx.google.com with ESMTPS id p30sm5502569qbp.17.2009.02.02.11.44.43 (version=SSLv3 cipher=RC4-MD5); Mon, 02 Feb 2009 11:44:44 -0800 (PST) Date: Mon, 2 Feb 2009 09:42:57 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: Fabian Keil In-Reply-To: <20090201170550.482bf325@fabiankeil.de> Message-ID: <20090202094226.E983@desktop> References: <20090131125100.N983@desktop> <20090201160544.4f1961b4@fabiankeil.de> <20090201170550.482bf325@fabiankeil.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: mbuf revision, testers/comments wanted. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2009 19:44:48 -0000 On Sun, 1 Feb 2009, Fabian Keil wrote: > Fabian Keil wrote: > >> Jeff Roberson wrote: >> >>> http://people.freebsd.org/~jeff/mbuf_ref2.diff >> >>> I have been experimenting with different revisions to the mbuf api to >>> improve performance and simplify code. This patch is the first of >>> several proposed steps towards those goals. The aim of this patch is >>> two fold; >> >>> I would appreciate testing feedback from varied workloads to make sure >>> there are no bugs before I go forward with this. I have tested only >>> host oriented networking with a few drivers. It is not anticipated >>> that there will be any significant incompatibilities introduced with >>> this round but there is always that possibility. > >> 5) >> Finally, I tested the patch on an IBM ThinPad R51. The kernel >> hangs on boot, the last messages are (hand transcribed): >> >> iwi0: mem 0xc0214000-0xc0214fff irq 11 at device 2.0 on pci2 >> iwi0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xc0214000 >> iwi0: could not allocate rx mbuf >> iwi0: could not allocate Rx ring >> bpfdetach: was not attached > > Never mind, kernel and user land weren't completely in > sync and this might be related to the recent wlan commits. > I'll retry with an up-to-date user land. > I have updated the patch here: http://people.freebsd.org/~jeff/mbuf_ref2.diff This resolves the !INVARIANTS bug and improves the style as you suggested. Thanks, Jeff > Fabian > From owner-freebsd-net@FreeBSD.ORG Mon Feb 2 19:46:22 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 65F0B1065673 for ; Mon, 2 Feb 2009 19:46:22 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.246]) by mx1.freebsd.org (Postfix) with ESMTP id 2757B8FC1A for ; Mon, 2 Feb 2009 19:46:21 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: by an-out-0708.google.com with SMTP id b38so698445ana.13 for ; Mon, 02 Feb 2009 11:46:21 -0800 (PST) Received: by 10.65.212.18 with SMTP id o18mr2832488qbq.21.1233603981147; Mon, 02 Feb 2009 11:46:21 -0800 (PST) Received: from ?10.0.1.199? ([72.14.241.160]) by mx.google.com with ESMTPS id p31sm5834738qbp.18.2009.02.02.11.46.18 (version=SSLv3 cipher=RC4-MD5); Mon, 02 Feb 2009 11:46:20 -0800 (PST) Date: Mon, 2 Feb 2009 09:44:32 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: Julian Elischer In-Reply-To: <4986A6F7.7080402@elischer.org> Message-ID: <20090202094307.O983@desktop> References: <20090131125100.N983@desktop> <4986A6F7.7080402@elischer.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: mbuf revision, testers/comments wanted. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2009 19:46:24 -0000 On Sun, 1 Feb 2009, Julian Elischer wrote: > Jeff Roberson wrote: >> http://people.freebsd.org/~jeff/mbuf_ref2.diff >> >> Hello, >> >> I have been experimenting with different revisions to the mbuf api to >> improve performance and simplify code. This patch is the first of several >> proposed steps towards those goals. The aim of this patch is two fold; >> >> 1) Revising the reference counting system so that we can eliminate >> reference uma zones and the significant uma_find_refcnt() costs in some >> workloads. This is done by making all mbufs reference counted and using >> the owning mbuf's ref for the ext_ref. In this model we never reference >> data, we only reference other mbufs owning the data. >> >> 2) Improve allocation and free performance by reducing the special cases >> in the format and using inlines when appropriate. In particular, the >> simplification of the m_ext structure yields less code and confusion for >> dealing with external storage on free. The ctor/dtor mbuf routines are no >> longer used. A zone pointer and length was added to struct mbuf to >> simplify free and size calculations. >> >> A number of routines were made much, much simpler by the addition of a >> 16bit size field. Previously we dependend on calculating the size by >> figuring out if it was an ext, pkthdr, or standard mbuf. Ultimately, this >> patch moves us closer to having a size agnostic mbuf which we can use to >> experiment with different allocation sizes or even backending to malloc for >> dynamically sized mbufs. >> >> I would appreciate testing feedback from varied workloads to make sure >> there are no bugs before I go forward with this. I have tested only host >> oriented networking with a few drivers. It is not anticipated that there >> will be any significant incompatibilities introduced with this round but >> there is always that possibility. >> > > > generally I like it. > > We discussed someof this before.. > > > It would be nice if you added more comments than you stripped out > I personally think that some descriptions of what you are doing > would be great in teh comments. Yes, I can do that. I hadn't added as much because things are still a bit in flux. > > ascii art too if needed... > > Also some diagrams in any form you want would be nice.. > all that about 1000 words and a picture is true. I'll have to see about that. Any suggestions similar to visio for unix? I guess graphviz can also do datastructure diagrams but I have not used it for this before. I'll check it out but if you have other suggestions it's welcome. Thanks, Jeff > >> Thanks, >> Jeff >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Mon Feb 2 20:29:48 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7ADB81065688; Mon, 2 Feb 2009 20:29:48 +0000 (UTC) (envelope-from prvs=julian=27733b6d4@elischer.org) Received: from smtp-outbound.ironport.com (smtp-outbound.ironport.com [63.251.108.112]) by mx1.freebsd.org (Postfix) with ESMTP id 61D308FC1B; Mon, 2 Feb 2009 20:29:48 +0000 (UTC) (envelope-from prvs=julian=27733b6d4@elischer.org) Received: from jelischer-laptop.sfo.ironport.com (HELO julian-mac.elischer.org) ([10.251.22.38]) by smtp-outbound.ironport.com with ESMTP; 02 Feb 2009 12:16:05 -0800 Message-ID: <4987548A.7000609@elischer.org> Date: Mon, 02 Feb 2009 12:16:10 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: FreeBSD virtualization mailing list , FreeBSD Net References: <498414E5.7020904@elischer.org> <4984241B.5010103@elischer.org> In-Reply-To: <4984241B.5010103@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: Vimage globals vs structures measurements. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2009 20:29:49 -0000 Julian Elischer wrote: > Julian Elischer wrote: >> >> anyone who has commands and args for their favourite >> thing the'd like me to test... send it in.. >> >> >> so far using ttcp I have seem no measureable difference. >> >> but I have more tests to do of course.. >> >> for example throughput with small packets with ttcp (KB/Sec).... >> >> >> x VIMAGE_GLOBALS >> + NO_VIMAGE_GLOBALS >> +-----------------------------------------------------------------+ >> | + xx | >> | + xxx + | >> | + xxx x ++++ | >> | x + x + + xxxxxxx +++++ | >> |x + ++ xx xxx + ++++xxx x x x +++++ ***xxxxx ++++++++| >> | |_____________A______M______| | >> | |________________AM________________| | >> +-----------------------------------------------------------------+ >> N Min Max Median Avg Stddev >> x 40 48016.01 57361.32 56268.06 54915.582 2554.0133 >> + 40 48999.66 59646.59 56261.58 56086.798 3119.1782 >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > as I said before mst of my tests have shown no real change but this one > has the most change I've seen.. it's 160 byte udp packets sent between > two identical machines (both using the same kernel each time). > > > x VIMAGE_GLOBALS > + NO_VIMAGE_GLOBALS > +-----------------------------------------------------------------+ > | + + ++ xx x x | > | + + ++ +x++x +xx x x | > | + + +++ + +*+**x+xxxx x | > | + +++ +++x*++*+**x*x*xx x x x | > | + +*+++++x**+*+**x*x*x*xx x x xx | > | ++++*++++****+*+**x*x****x xxxx xxx | > | + + xx + ++++*++*+****+***********x*xxxxx xxxx x| > |+ +*+++ xx++*+*+*+****+****************x***x*xxx*xx x xx x| > | |__________A__________| | > | |_________A________| | > +-----------------------------------------------------------------+ > N Min Max Median Avg Stddev > x 150 10175.11 11292.11 10763.80 10760.77 200.92124 > + 150 10075.64 11019.12 10591.68 10580.059 172.29227 > Difference at 95.0% confidence > -180.711 +/- 42.3572 > -1.67935% +/- 0.393626% > (Student's t, pooled s = 187.155) > > this one showed a 1.7% slowdown > where the one above showed a half percent speedup > (but not considered significant). > > The first one shown above was TCP with 1500 byte packets on bge 1G > interfaces.. > > more test ideas appreciated... more tests.. this one with iperf... x NO_VIMAGE_GLOBALS + VIMAGE_GLOBALS +-----------------------------------------------------------------+ | + x x x | | + + x x x x | | + + + + x x x x | | + + + + x x x x | | + + + + + x x x x x | | + + + + * x x x x x x | | + + + + * x * x x x x | | + + + + + * * * x x x x | | + + + + + + * * * x x x x | | + + + + + + + * * * x x x x | | + + + + + + + * * * * x x x x x | | + + + + + + * * * * * * x x x x | | + + + + + + * * * * * * x x x x | | + + + + + + * * * * * * * * x * x x | |x + + + + * * * * * * * * * * * * x x x| | |________A_________| | | |________MA_________| | +-----------------------------------------------------------------+ N Min Max Median Avg Stddev x 120 418 441 435 435.025 3.4089908 + 120 423 438 429 429.51667 3.4664862 Difference at 95.0% confidence -5.50833 +/- 0.869898 -1.26621% +/- 0.199965% (Student's t, pooled s = 3.43786) bigger is better... In this case we see that NO_VIMAGE_GLOBALS is better. Over several iterations I have come to the conclusion that other factors are overwhelming this change and that the effect of clustering all the 'global' variables together into a single global structure is negligible. If I can get some confirmation of this by others then the next step would be to simply remove the VIMAGE_GLOBALS option and all the global variables it covers. At least that's what seems next to me.. see: http://wiki.freebsd.org/Image/Notes200808DevSummit > > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Mon Feb 2 20:31:29 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9D9171065691 for ; Mon, 2 Feb 2009 20:31:29 +0000 (UTC) (envelope-from prvs=julian=27733b6d4@elischer.org) Received: from smtp-outbound.ironport.com (smtp-outbound.ironport.com [63.251.108.112]) by mx1.freebsd.org (Postfix) with ESMTP id 79D008FC17 for ; Mon, 2 Feb 2009 20:31:29 +0000 (UTC) (envelope-from prvs=julian=27733b6d4@elischer.org) Received: from jelischer-laptop.sfo.ironport.com (HELO julian-mac.elischer.org) ([10.251.22.38]) by smtp-outbound.ironport.com with ESMTP; 02 Feb 2009 12:22:02 -0800 Message-ID: <498755EF.50805@elischer.org> Date: Mon, 02 Feb 2009 12:22:07 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Jeff Roberson References: <20090131125100.N983@desktop> <4986A6F7.7080402@elischer.org> <20090202094307.O983@desktop> In-Reply-To: <20090202094307.O983@desktop> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: mbuf revision, testers/comments wanted. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2009 20:31:32 -0000 Jeff Roberson wrote: > On Sun, 1 Feb 2009, Julian Elischer wrote: > >> ascii art too if needed... >> >> Also some diagrams in any form you want would be nice.. >> all that about 1000 words and a picture is true. > > I'll have to see about that. Any suggestions similar to visio for unix? > I guess graphviz can also do datastructure diagrams but I have not used > it for this before. I'll check it out but if you have other suggestions > it's welcome. > > Thanks, > Jeff > This is the stuff of religious wars, but for simplicity, I'm partial to TGIF. It's an old X app that is therefore small. It allows you to link objects with line sand then move them around and it compiles and runs on everything on the planet. it can export in lots of formats and I find it pretty intuitive once you've gotten around it's few idiosyncracies. Because it is so small it loads on a modern machine in sub second time. as opposed to some of the bigger apps that take 20 seconds before you even see the window. and "yes, export and print are the same function.. printing is just exporting to the printer" From owner-freebsd-net@FreeBSD.ORG Mon Feb 2 20:47:06 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 37E6D10656C6 for ; Mon, 2 Feb 2009 20:47:06 +0000 (UTC) (envelope-from prvs=julian=27733b6d4@elischer.org) Received: from smtp-outbound.ironport.com (smtp-outbound.ironport.com [63.251.108.112]) by mx1.freebsd.org (Postfix) with ESMTP id 223458FC1E for ; Mon, 2 Feb 2009 20:47:06 +0000 (UTC) (envelope-from prvs=julian=27733b6d4@elischer.org) Received: from jelischer-laptop.sfo.ironport.com (HELO julian-mac.elischer.org) ([10.251.22.38]) by smtp-outbound.ironport.com with ESMTP; 02 Feb 2009 12:47:06 -0800 Message-ID: <49875BCF.5030305@elischer.org> Date: Mon, 02 Feb 2009 12:47:11 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Jeff Roberson References: <20090131125100.N983@desktop> <4986A6F7.7080402@elischer.org> <20090202094307.O983@desktop> In-Reply-To: <20090202094307.O983@desktop> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: mbuf revision, testers/comments wanted. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2009 20:47:06 -0000 > > I'll have to see about that. Any suggestions similar to visio for unix? > I guess graphviz can also do datastructure diagrams but I have not used > it for this before. I'll check it out but if you have other suggestions > it's welcome. > BTW I once satisfied this requirement using a screenshot of the output of 'ddd' (the debugger, not the 'dd' replacement) From owner-freebsd-net@FreeBSD.ORG Mon Feb 2 22:24:18 2009 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 54ED41065672 for ; Mon, 2 Feb 2009 22:24:18 +0000 (UTC) (envelope-from dlt@mebtel.net) Received: from mail959c35.nsolutionszone.com (mail959c35.nsolutionszone.com [209.235.152.149]) by mx1.freebsd.org (Postfix) with ESMTP id 165F28FC1B for ; Mon, 2 Feb 2009 22:24:17 +0000 (UTC) (envelope-from dlt@mebtel.net) X-POP-User: dlt.mebtel.net Received: from localhost (66-79-79-183.dsl.mebtel.net [66.79.79.183]) by mail959c35.nsolutionszone.com (8.13.6.20060614/8.13.1) with ESMTP id n12MOEIg006271; Mon, 2 Feb 2009 22:24:15 GMT Date: Mon, 2 Feb 2009 17:24:14 -0500 From: Derek Tattersall To: Robert Watson Message-ID: <20090202222414.GA59860@oriental.arm.org> References: <20090201183057.GA47405@oriental.arm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@FreeBSD.org Subject: Re: Multicast source address in recvfrom() X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dlt@mebtel.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2009 22:24:18 -0000 * Robert Watson [090202 17:06]: > On Sun, 1 Feb 2009, Derek Tattersall wrote: > > >In order to become familiar with multicast implementation using FreeBSD, I > >found via Google a pair of test programs which multicast sent a simple > >text message and received the text message. I added some code to report > >the source address, because none of the references that I looked at > >specified the source IP address in the frame. > > > >I ran the sender on A -current system, AMD64 vintage last week. The > >receiver was on a -current system I386 vintage last week. TCPDUMP shows > >the source IP address in the frame as (correctly) 192.168.0.15. The > >receiver reports the source IP address as 200.231.191.191. I have also > >run the same test with an OpenBSD 4.4 Release I386 system as the receiver. > >The openBSD system reports the sender as 192.168.0.15. A Fedora 10 system > >reported the source IP address as 0.0.0.0. > > > >Googling the RFCs and other information and referring to Comer's and > >Stevens' books on TCPIP I can't determine what should be reported. Does > >anybody have clue for me? > > Hi Derek: > > It might depend on how you're querying the source address. Could you post > a code excerpt? > > Robert N M Watson > Computer Laboratory > University of Cambridge It's a straightforward test program. /********************************************************************** * * MulticastReceiver.c: Receive a multicast message * * Copyright (C) 2009 Derek Tattersall. * * See the COPYING file for license information. * * Author: Derek Tattersall * * Latest Revision: Sat Jan 31 07:21:04 2009 * **********************************************************************/ /* Includes***********************************************************/ #include /* for printf() and fprintf() */ #include /* for socket(), connect(), sendto(), and recvfrom() */ #include /* for sockaddr_in and inet_addr() */ #include /* for IPPROTO_UDP */ #include /* for atoi() and exit() */ #include /* for memset() */ #include /* for close() */ /* Defines ***********************************************************/ #define MAXRECVSTRING 255 /* Longest string to receive */ /* Type Definitions **************************************************/ /* Function Declarations *********************************************/ void DieWithError(char *errorMessage); /* External error handling function */ /* Global Variables **************************************************/ /* Function Implementations ******************************************/ int main(int argc, char *argv[]) { int sock; /* Socket */ struct sockaddr_in multicastAddr; /* Multicast Address */ char *multicastIP; /* IP Multicast Address */ unsigned short multicastPort; /* Port */ struct sockaddr_in senderAddr; /* Sender Address */ int senderLen; /* length of sender address socket */ char senderAddrBuf[INET_ADDRSTRLEN]; /* conversion buffer */ char recvString[MAXRECVSTRING+1]; /* Buffer for received string */ int recvStringLen; /* Length of received string */ struct ip_mreq multicastRequest; /* Multicast address join structure */ if (argc != 3) /* Test for correct number of arguments */ { fprintf(stderr,"Usage: %s \n", argv[0]); exit(1); } multicastIP = argv[1]; /* First arg: Multicast IP address (dotted quad) */ multicastPort = atoi(argv[2]);/* Second arg: Multicast port */ /* Create a best-effort datagram socket using UDP */ if ((sock = socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP)) < 0) DieWithError("socket() failed"); /* Construct bind structure */ memset(&multicastAddr, 0, sizeof(multicastAddr)); /* Zero out structure */ multicastAddr.sin_family = AF_INET; /* Internet address family */ multicastAddr.sin_addr.s_addr = htonl(INADDR_ANY); /* Any incoming interface */ multicastAddr.sin_port = htons(multicastPort); /* Multicast port */ /* Bind to the multicast port */ if (bind(sock, (struct sockaddr *) &multicastAddr, sizeof(multicastAddr)) < 0) DieWithError("bind() failed"); /* Specify the multicast group */ multicastRequest.imr_multiaddr.s_addr = inet_addr(multicastIP); /* Accept multicast from any interface */ multicastRequest.imr_interface.s_addr = htonl(INADDR_ANY); /* Join the multicast address */ if (setsockopt(sock, IPPROTO_IP, IP_ADD_MEMBERSHIP, (void *) &multicastRequest, sizeof(multicastRequest)) < 0) DieWithError("setsockopt() failed"); /* Receive a single datagram from the server */ if ((recvStringLen = recvfrom(sock, recvString, MAXRECVSTRING, 0, (struct sockaddr *)&senderAddr, (socklen_t *)&senderLen)) < 0) DieWithError("recvfrom() failed"); if ((inet_ntop(AF_INET, &senderAddr.sin_addr.s_addr, senderAddrBuf, INET_ADDRSTRLEN)) == 0) senderAddrBuf[0] = '\0'; recvString[recvStringLen] = '\0'; printf("Received from %s: %s\n", senderAddrBuf, recvString); /* Print the received string */ close(sock); exit(0); } /* vim: set sts=0 sw=8 ts=8: *****************************************/ Note that the sender's address is taken from the recvfrom call per the man page and printed via inet_ntop call. The DieWithError routine is a simple print error message and exit with a 1. I have used similar code with UDP recieving apps before. -- Best regards, Derek Tattersall dlt@mebtel.net dlt666@yahoo.com dtatters@gmail.com From owner-freebsd-net@FreeBSD.ORG Mon Feb 2 23:10:11 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 519B810656E7 for ; Mon, 2 Feb 2009 23:10:11 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 2D3E18FC0A for ; Mon, 2 Feb 2009 23:10:10 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n12NAA0P042849 for ; Mon, 2 Feb 2009 23:10:10 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n12NA9EY042848; Mon, 2 Feb 2009 23:10:09 GMT (envelope-from gnats) Date: Mon, 2 Feb 2009 23:10:09 GMT Message-Id: <200902022310.n12NA9EY042848@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: linimon@lonesome.com (Mark Linimon) Cc: Subject: Re: kern/87758: [ath] [hang] Reboot problem with atheros wireless card (DWL-G520) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Mark Linimon List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2009 23:10:14 -0000 The following reply was made to PR kern/87758; it has been noted by GNATS. From: linimon@lonesome.com (Mark Linimon) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/87758: [ath] [hang] Reboot problem with atheros wireless card (DWL-G520) Date: Mon, 2 Feb 2009 17:08:29 -0600 ----- Forwarded message from Paulo Fragoso ----- From: Paulo Fragoso To: vwe@FreeBSD.org Cc: freebsd-net@FreeBSD.org, freebsd-bugs@FreeBSD.org Subject: Re: kern/87758: [ath] [hang] Reboot problem with atheros wireless card (DWL-G520) We didn't find this problem since 6.2-RELEASE. Paulo. ----- End forwarded message ----- From owner-freebsd-net@FreeBSD.ORG Mon Feb 2 23:25:56 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 97C6B1065672; Mon, 2 Feb 2009 23:25:56 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 6CCA98FC18; Mon, 2 Feb 2009 23:25:56 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n12NPuUD057938; Mon, 2 Feb 2009 23:25:56 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n12NPusm057934; Mon, 2 Feb 2009 23:25:56 GMT (envelope-from linimon) Date: Mon, 2 Feb 2009 23:25:56 GMT Message-Id: <200902022325.n12NPusm057934@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-amd64@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/131310: [panic] 7.1 panics with mpd netgraph interface changes X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2009 23:25:57 -0000 Old Synopsis: 7.1 panics with mpd netgraph interface changes New Synopsis: [panic] 7.1 panics with mpd netgraph interface changes Responsible-Changed-From-To: freebsd-amd64->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Feb 2 23:24:30 UTC 2009 Responsible-Changed-Why: Looks like this might be network-related, but I'm not sure. http://www.freebsd.org/cgi/query-pr.cgi?pr=131310 From owner-freebsd-net@FreeBSD.ORG Mon Feb 2 23:47:34 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 78274106566B; Mon, 2 Feb 2009 23:47:34 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 4C9CD8FC08; Mon, 2 Feb 2009 23:47:34 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n12NlYD5074693; Mon, 2 Feb 2009 23:47:34 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n12NlXeL074689; Mon, 2 Feb 2009 23:47:33 GMT (envelope-from linimon) Date: Mon, 2 Feb 2009 23:47:33 GMT Message-Id: <200902022347.n12NlXeL074689@freefall.freebsd.org> To: paulo@nlink.com.br, linimon@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/87758: [ath] [hang] Reboot problem with atheros wireless card (DWL-G520) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2009 23:47:34 -0000 Synopsis: [ath] [hang] Reboot problem with atheros wireless card (DWL-G520) State-Changed-From-To: feedback->closed State-Changed-By: linimon State-Changed-When: Mon Feb 2 23:47:19 UTC 2009 State-Changed-Why: Submitter notes this problem is resolved. http://www.freebsd.org/cgi/query-pr.cgi?pr=87758 From owner-freebsd-net@FreeBSD.ORG Tue Feb 3 08:40:58 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0E940106566C for ; Tue, 3 Feb 2009 08:40:58 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (agora.rdrop.com [199.26.172.34]) by mx1.freebsd.org (Postfix) with ESMTP id C40648FC12 for ; Tue, 3 Feb 2009 08:40:57 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id n138euWA091411 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 3 Feb 2009 00:40:57 -0800 (PST) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.12.9/Submit) with UUCP id n138euZT091410; Tue, 3 Feb 2009 00:40:56 -0800 (PST) Received: from fbsd61 by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA10561; Tue, 3 Feb 09 00:39:42 PST Date: Tue, 03 Feb 2009 00:41:06 -0800 From: perryh@pluto.rain.com To: jroberson@jroberson.net Message-Id: <49880322.0MwiaosrHBVUXyHQ%perryh@pluto.rain.com> References: <20090131125100.N983@desktop> <4986A6F7.7080402@elischer.org> <20090202094307.O983@desktop> In-Reply-To: <20090202094307.O983@desktop> User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Visio (Re: mbuf revision, testers/comments wanted.) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2009 08:40:58 -0000 > Any suggestions similar to visio for unix? graphics/dia is the closest approximation I know of. It might work to run Visio itself under wine. From owner-freebsd-net@FreeBSD.ORG Tue Feb 3 10:13:55 2009 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 39803106566C for ; Tue, 3 Feb 2009 10:13:55 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id F3CB68FC12 for ; Tue, 3 Feb 2009 10:13:54 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 9C7CB46B03; Tue, 3 Feb 2009 05:13:54 -0500 (EST) Date: Tue, 3 Feb 2009 10:13:54 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Derek Tattersall In-Reply-To: <20090202222414.GA59860@oriental.arm.org> Message-ID: References: <20090201183057.GA47405@oriental.arm.org> <20090202222414.GA59860@oriental.arm.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@FreeBSD.org Subject: Re: Multicast source address in recvfrom() X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2009 10:13:55 -0000 > * Robert Watson [090202 17:06]: >> On Sun, 1 Feb 2009, Derek Tattersall wrote: >> >>> In order to become familiar with multicast implementation using FreeBSD, I >>> found via Google a pair of test programs which multicast sent a simple >>> text message and received the text message. I added some code to report >>> the source address, because none of the references that I looked at >>> specified the source IP address in the frame. >>> >>> I ran the sender on A -current system, AMD64 vintage last week. The >>> receiver was on a -current system I386 vintage last week. TCPDUMP shows >>> the source IP address in the frame as (correctly) 192.168.0.15. The >>> receiver reports the source IP address as 200.231.191.191. I have also >>> run the same test with an OpenBSD 4.4 Release I386 system as the receiver. >>> The openBSD system reports the sender as 192.168.0.15. A Fedora 10 system >>> reported the source IP address as 0.0.0.0. >>> >>> Googling the RFCs and other information and referring to Comer's and >>> Stevens' books on TCPIP I can't determine what should be reported. Does >>> anybody have clue for me? >> >> It might depend on how you're querying the source address. Could you post >> a code excerpt? > > It's a straightforward test program. Your assumption, that the address returned from recvfrom(2) should be correct, seems generally right to me. However, it looks like you may not be initializing senderLen to the size of senderAddr, which means that the size getting passed in may be random stack garbage. In which case what you find in the sockaddr_in might also be random stack garbage, or might be the address, depending on whether the uninitialized length was long enough to fit an IP address in. Could you try adding something like: senderLen = sizeof(senderAddr); before the call to recvfrom(2)? Thanks, Robert N M Watson Computer Laboratory University of Cambridge > > /********************************************************************** > * > * MulticastReceiver.c: Receive a multicast message > * > * Copyright (C) 2009 Derek Tattersall. > * > * See the COPYING file for license information. > * > * Author: Derek Tattersall > * > * Latest Revision: Sat Jan 31 07:21:04 2009 > * > **********************************************************************/ > > /* Includes***********************************************************/ > #include /* for printf() and fprintf() */ > #include /* for socket(), connect(), sendto(), and recvfrom() */ > #include /* for sockaddr_in and inet_addr() */ > #include /* for IPPROTO_UDP */ > #include /* for atoi() and exit() */ > #include /* for memset() */ > #include /* for close() */ > > > /* Defines ***********************************************************/ > #define MAXRECVSTRING 255 /* Longest string to receive */ > > /* Type Definitions **************************************************/ > > /* Function Declarations *********************************************/ > void DieWithError(char *errorMessage); /* External error handling function */ > > /* Global Variables **************************************************/ > > /* Function Implementations ******************************************/ > int main(int argc, char *argv[]) > { > int sock; /* Socket */ > struct sockaddr_in multicastAddr; /* Multicast Address */ > char *multicastIP; /* IP Multicast Address */ > unsigned short multicastPort; /* Port */ > struct sockaddr_in senderAddr; /* Sender Address */ > int senderLen; /* length of sender address socket */ > char senderAddrBuf[INET_ADDRSTRLEN]; /* conversion buffer */ > char recvString[MAXRECVSTRING+1]; /* Buffer for received string */ > int recvStringLen; /* Length of received string */ > struct ip_mreq multicastRequest; /* Multicast address join structure */ > > if (argc != 3) /* Test for correct number of arguments */ > { > fprintf(stderr,"Usage: %s \n", argv[0]); > exit(1); > } > > multicastIP = argv[1]; /* First arg: Multicast IP address (dotted quad) */ > multicastPort = atoi(argv[2]);/* Second arg: Multicast port */ > > /* Create a best-effort datagram socket using UDP */ > if ((sock = socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP)) < 0) > DieWithError("socket() failed"); > > /* Construct bind structure */ > memset(&multicastAddr, 0, sizeof(multicastAddr)); /* Zero out structure */ > multicastAddr.sin_family = AF_INET; /* Internet address family */ > multicastAddr.sin_addr.s_addr = htonl(INADDR_ANY); /* Any incoming interface */ > multicastAddr.sin_port = htons(multicastPort); /* Multicast port */ > > /* Bind to the multicast port */ > if (bind(sock, (struct sockaddr *) &multicastAddr, sizeof(multicastAddr)) < 0) > DieWithError("bind() failed"); > > /* Specify the multicast group */ > multicastRequest.imr_multiaddr.s_addr = inet_addr(multicastIP); > /* Accept multicast from any interface */ > multicastRequest.imr_interface.s_addr = htonl(INADDR_ANY); > /* Join the multicast address */ > if (setsockopt(sock, IPPROTO_IP, IP_ADD_MEMBERSHIP, (void *) &multicastRequest, > sizeof(multicastRequest)) < 0) > DieWithError("setsockopt() failed"); > > /* Receive a single datagram from the server */ > if ((recvStringLen = recvfrom(sock, recvString, MAXRECVSTRING, 0, (struct sockaddr *)&senderAddr, (socklen_t *)&senderLen)) < 0) > DieWithError("recvfrom() failed"); > > if ((inet_ntop(AF_INET, &senderAddr.sin_addr.s_addr, senderAddrBuf, INET_ADDRSTRLEN)) == 0) > senderAddrBuf[0] = '\0'; > recvString[recvStringLen] = '\0'; > printf("Received from %s: %s\n", senderAddrBuf, recvString); /* Print the received string */ > > close(sock); > exit(0); > } > > /* vim: set sts=0 sw=8 ts=8: *****************************************/ > Note that the sender's address is taken from the recvfrom call per the > man page and printed via inet_ntop call. The DieWithError routine is a > simple print error message and exit with a 1. I have used similar code > with UDP recieving apps before. > -- > Best regards, > Derek Tattersall > dlt@mebtel.net dlt666@yahoo.com dtatters@gmail.com > From owner-freebsd-net@FreeBSD.ORG Tue Feb 3 10:30:05 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 054F11065674 for ; Tue, 3 Feb 2009 10:30:05 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id DD9F38FC13 for ; Tue, 3 Feb 2009 10:30:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n13AU4Kt008360 for ; Tue, 3 Feb 2009 10:30:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n13AU4Lx008357; Tue, 3 Feb 2009 10:30:04 GMT (envelope-from gnats) Date: Tue, 3 Feb 2009 10:30:04 GMT Message-Id: <200902031030.n13AU4Lx008357@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Vitaly Dodonov Cc: Subject: Re: kern/131310: [panic] 7.1 panics with mpd netgraph interface changes X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Vitaly Dodonov List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2009 10:30:05 -0000 The following reply was made to PR kern/131310; it has been noted by GNATS. From: Vitaly Dodonov To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/131310: [panic] 7.1 panics with mpd netgraph interface changes Date: Tue, 3 Feb 2009 13:00:12 +0300 --000e0cd2301abeffad046200bc47 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit tried switch to GENERIC, problem still exists without altq and other options FreeBSD d2s.local 7.1-RELEASE-p2 FreeBSD 7.1-RELEASE-p2 #0: Tue Feb 3 09:13:03 MSK 2009 d2@d2s.local:/usr/obj/usr/src/sys/GENERIC amd64 /<4>sys/GENERIC# kgdb kernel.debug /var/crash/vmcore.5 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Unread portion of the kernel message buffer: Fatal trap 9: general protection fault while in kernel mode cpuid = 1; apic id = 01 instruction pointer = 0x8:0xffffffffdbebbb06 stack pointer = 0x10:0xffffffffdbff58a0 frame pointer = 0x10:0xffffffffdbff58f0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 1746 (mpd5) trap number = 9 panic: general protection fault cpuid = 1 Uptime: 3h9m14s Physical memory: 4078 MB Dumping 1267 MB: 1252 1236 1220 1204 1188 1172 1156 1140 1124 1108 1092 1076 1060 1044 1028 1012 996 980 964 948 932 916 900 884 868 852 836 820 804 788 772 756 740 724 708 692 676 660 644 628 612 596 580 564 548 532 516 500 484 468 452 436 420 404 388 372 356 340 324 308 292 276 260 244 228 212 196 180 164 148 132 116 100 84 68 52 36 20 4 Reading symbols from /boot/kernel/zfs.ko...Reading symbols from /boot/kernel/zfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/zfs.ko Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from /boot/kernel/opensolaris.ko.symbols...done. done. Loaded symbols for /boot/kernel/opensolaris.ko Reading symbols from /boot/kernel/ng_pppoe.ko...Reading symbols from /boot/kernel/ng_pppoe.ko.symbols...done. done. Loaded symbols for /boot/kernel/ng_pppoe.ko Reading symbols from /boot/kernel/netgraph.ko...Reading symbols from /boot/kernel/netgraph.ko.symbols...done. done. Loaded symbols for /boot/kernel/netgraph.ko Reading symbols from /boot/kernel/geom_journal.ko...Reading symbols from /boot/kernel/geom_journal.ko.symbols...done. done. Loaded symbols for /boot/kernel/geom_journal.ko Reading symbols from /boot/kernel/if_lagg.ko...Reading symbols from /boot/kernel/if_lagg.ko.symbols...done. done. Loaded symbols for /boot/kernel/if_lagg.ko Reading symbols from /boot/kernel/if_vlan.ko...Reading symbols from /boot/kernel/if_vlan.ko.symbols...done. done. Loaded symbols for /boot/kernel/if_vlan.ko Reading symbols from /boot/kernel/pf.ko...Reading symbols from /boot/kernel/pf.ko.symbols...done. done. Loaded symbols for /boot/kernel/pf.ko Reading symbols from /boot/kernel/ng_socket.ko...Reading symbols from /boot/kernel/ng_socket.ko.symbols...done. done. Loaded symbols for /boot/kernel/ng_socket.ko Reading symbols from /boot/kernel/ng_mppc.ko...Reading symbols from /boot/kernel/ng_mppc.ko.symbols...done. done. Loaded symbols for /boot/kernel/ng_mppc.ko Reading symbols from /boot/kernel/rc4.ko...Reading symbols from /boot/kernel/rc4.ko.symbols...done. done. Loaded symbols for /boot/kernel/rc4.ko Reading symbols from /boot/kernel/ng_iface.ko...Reading symbols from /boot/kernel/ng_iface.ko.symbols...done. done. Loaded symbols for /boot/kernel/ng_iface.ko Reading symbols from /boot/kernel/ng_ppp.ko...Reading symbols from /boot/kernel/ng_ppp.ko.symbols...done. done. Loaded symbols for /boot/kernel/ng_ppp.ko Reading symbols from /boot/kernel/ng_ether.ko...Reading symbols from /boot/kernel/ng_ether.ko.symbols...done. done. Loaded symbols for /boot/kernel/ng_ether.ko Reading symbols from /boot/kernel/ng_tee.ko...Reading symbols from /boot/kernel/ng_tee.ko.symbols...done. done. Loaded symbols for /boot/kernel/ng_tee.ko Reading symbols from /boot/kernel/ng_tcpmss.ko...Reading symbols from /boot/kernel/ng_tcpmss.ko.symbols...done. done. Loaded symbols for /boot/kernel/ng_tcpmss.ko #0 doadump () at pcpu.h:195 195 __asm __volatile("movq %%gs:0,%0" : "=r" (td)); (kgdb) backtrace #0 doadump () at pcpu.h:195 #1 0x0000000000000004 in ?? () #2 0xffffffff804b4ce9 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #3 0xffffffff804b50f2 in panic (fmt=0x104
) at /usr/src/sys/kern/kern_shutdown.c:574 #4 0xffffffff8078a173 in trap_fatal (frame=0xffffff00077ae000, eva=Variable "eva" is not available.) at /usr/src/sys/amd64/amd64/trap.c:764 #5 0xffffffff8078acc5 in trap (frame=0xffffffffdbff57f0) at /usr/src/sys/amd64/amd64/trap.c:565 #6 0xffffffff8077067e in calltrap () at /usr/src/sys/amd64/amd64/exception.S:209 #7 0xffffffffdbebbb06 in pfi_instance_add (ifp=0xffffff000737b800, net=128, flags=0) at /usr/src/sys/modules/pf/../../contrib/pf/net/pf_if.c:578 #8 0xffffffffdbebbdd6 in pfi_table_update (kt=0xffffff000772e510, kif=Variable "kif" is not available.) at /usr/src/sys/modules/pf/../../contrib/pf/net/pf_if.c:561 #9 0xffffffffdbebc06b in pfi_dynaddr_update (dyn=0xffffff0007764d20) at /usr/src/sys/modules/pf/../../contrib/pf/net/pf_if.c:543 #10 0xffffffffdbebc0be in pfi_kif_update (kif=0xffffff000739d500) at /usr/src/sys/modules/pf/../../contrib/pf/net/pf_if.c:520 #11 0xffffffffdbebc0ec in pfi_kif_update (kif=0xffffff0007733000) at /usr/src/sys/modules/pf/../../contrib/pf/net/pf_if.c:525 #12 0xffffffffdbebc15c in pfi_ifaddr_event (arg=Variable "arg" is not available.) at /usr/src/sys/modules/pf/../../contrib/pf/net/pf_if.c:942 #13 0xffffffff8058b54c in in_control (so=Variable "so" is not available.) at /usr/src/sys/netinet/in.c:476 #14 0xffffffff8054ea6f in ifioctl (so=0xffffff002007a5a0, cmd=2149607705, data=0xffffff0005ef3ac0 "ng2", td=0xffffff00077ae000) at /usr/src/sys/net/if.c:1952 #15 0xffffffff804ed9f4 in kern_ioctl (td=0xffffff00077ae000, fd=26, com=2149607705, data=0xffffff0005ef3ac0 "ng2") at file.h:268 #16 0xffffffff804edcfa in ioctl (td=0xffffff00077ae000, uap=0xffffffffdbff5bf0) at /usr/src/sys/kern/sys_generic.c:570 #17 0xffffffff8078a7c7 in syscall (frame=0xffffffffdbff5c80) at /usr/src/sys/amd64/amd64/trap.c:907 #18 0xffffffff8077088b in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:330 #19 0x000000080188137c in ?? () Previous frame inner to this frame (corrupt stack?) --000e0cd2301abeffad046200bc47 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
tried switch to GENERIC, problem still exists without altq and other o= ptions
 
FreeBSD d2s.local 7.1-RELEASE-p2 FreeBSD 7.1-RELEASE-p2 #0: Tue Feb&nb= sp; 3 09:13:03 MSK 2009     d2@d2s.local:/usr/obj/usr/src/sys/GENERIC=   amd64
 
/<4>sys/GENERIC# kgdb kernel.debug /var/crash/vmcore.5
GNU gd= b 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB i= s free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain condition= s.
Type "show copying" to see the conditions.
There is abso= lutely no warranty for GDB.  Type "show warranty" for detail= s.
This GDB was configured as "amd64-marcel-freebsd"...
Unread portion of the kernel message buffer:

Fatal trap 9: general protection fault while in kernel mode
cpu= id =3D 1; apic id =3D 01
instruction pointer     =3D= 0x8:0xffffffffdbebbb06
stack pointer      = ;     =3D 0x10:0xffffffffdbff58a0
frame pointer = ;          =3D 0x10:0xffffffff= dbff58f0
code segment          &nb= sp; =3D base 0x0, limit 0xfffff, type 0x1b
     = ;            &n= bsp;      =3D DPL 0, pres 1, long 1, def32 0, gran= 1
processor eflags        =3D interr= upt enabled, resume, IOPL =3D 0
current process    &= nbsp;    =3D 1746 (mpd5)
trap number          &nbs= p;  =3D 9
panic: general protection fault
cpuid =3D 1
Uptime:= 3h9m14s
Physical memory: 4078 MB
Dumping 1267 MB: 1252 1236 1220 120= 4 1188 1172 1156 1140 1124 1108 1092 1076 1060 1044 1028 1012 996 980 964 9= 48 932 916 900 884 868 852 836 820 804 788 772 756 740 724 708 692 676 660 = 644 628 612 596 580 564 548 532 516 500 484 468 452 436 420 404 388 372 356= 340 324 308 292 276 260 244 228 212 196 180 164 148 132 116 100 84 68 52 3= 6 20 4
Reading symbols from /boot/kernel/zfs.ko...Reading symbols from /boot/= kernel/zfs.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/z= fs.ko
Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols= from /boot/kernel/opensolaris.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/opensolaris.ko
Reading symbols = from /boot/kernel/ng_pppoe.ko...Reading symbols from /boot/kernel/ng_pppoe.= ko.symbols...done.
done.
Loaded symbols for /boot/kernel/ng_pppoe.ko<= br> Reading symbols from /boot/kernel/netgraph.ko...Reading symbols from /boot/= kernel/netgraph.ko.symbols...done.
done.
Loaded symbols for /boot/ker= nel/netgraph.ko
Reading symbols from /boot/kernel/geom_journal.ko...Read= ing symbols from /boot/kernel/geom_journal.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/geom_journal.ko
Reading symbols= from /boot/kernel/if_lagg.ko...Reading symbols from /boot/kernel/if_lagg.k= o.symbols...done.
done.
Loaded symbols for /boot/kernel/if_lagg.ko Reading symbols from /boot/kernel/if_vlan.ko...Reading symbols from /boot/k= ernel/if_vlan.ko.symbols...done.
done.
Loaded symbols for /boot/kerne= l/if_vlan.ko
Reading symbols from /boot/kernel/pf.ko...Reading symbols f= rom /boot/kernel/pf.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/pf.ko
Reading symbols from /boo= t/kernel/ng_socket.ko...Reading symbols from /boot/kernel/ng_socket.ko.symb= ols...done.
done.
Loaded symbols for /boot/kernel/ng_socket.ko
Reading symbols from /boot/kernel/ng_mppc.ko...Reading symbols from /boot/k= ernel/ng_mppc.ko.symbols...done.
done.
Loaded symbols for /boot/kerne= l/ng_mppc.ko
Reading symbols from /boot/kernel/rc4.ko...Reading symbols = from /boot/kernel/rc4.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/rc4.ko
Reading symbols from /bo= ot/kernel/ng_iface.ko...Reading symbols from /boot/kernel/ng_iface.ko.symbo= ls...done.
done.
Loaded symbols for /boot/kernel/ng_iface.ko
Readi= ng symbols from /boot/kernel/ng_ppp.ko...Reading symbols from /boot/kernel/= ng_ppp.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/ng_ppp.ko
Reading symbols from = /boot/kernel/ng_ether.ko...Reading symbols from /boot/kernel/ng_ether.ko.sy= mbols...done.
done.
Loaded symbols for /boot/kernel/ng_ether.ko
Reading symbols from /boot/kernel/ng_tee.ko...Reading symbols from /boot/ke= rnel/ng_tee.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/= ng_tee.ko
Reading symbols from /boot/kernel/ng_tcpmss.ko...Reading symbo= ls from /boot/kernel/ng_tcpmss.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/ng_tcpmss.ko
#0  doadump (= ) at pcpu.h:195
195         = ;    __asm __volatile("movq %%gs:0,%0" : "=3D= r" (td));
(kgdb) backtrace
#0  doadump () at pcpu.h:195
#1  0x0000000000000004 in ?? ()
#2  0xffffffff804b4ce9 in boot= (howto=3D260) at /usr/src/sys/kern/kern_shutdown.c:418
#3  0xfffff= fff804b50f2 in panic (fmt=3D0x104 <Address 0x104 out of bounds>) at /= usr/src/sys/kern/kern_shutdown.c:574
#4  0xffffffff8078a173 in trap_fatal (frame=3D0xffffff00077ae000, eva= =3DVariable "eva" is not available.) at /usr/src/sys/amd64/amd64/= trap.c:764
#5  0xffffffff8078acc5 in trap (frame=3D0xffffffffdbff57= f0) at /usr/src/sys/amd64/amd64/trap.c:565
#6  0xffffffff8077067e in calltrap () at /usr/src/sys/amd64/amd64/exce= ption.S:209
#7  0xffffffffdbebbb06 in pfi_instance_add (ifp=3D0xfff= fff000737b800, net=3D128, flags=3D0) at /usr/src/sys/modules/pf/../../contr= ib/pf/net/pf_if.c:578
#8  0xffffffffdbebbdd6 in pfi_table_update (kt=3D0xffffff000772e510, k= if=3DVariable "kif" is not available.) at /usr/src/sys/modules/pf= /../../contrib/pf/net/pf_if.c:561
#9  0xffffffffdbebc06b in pfi_dyn= addr_update (dyn=3D0xffffff0007764d20) at /usr/src/sys/modules/pf/../../con= trib/pf/net/pf_if.c:543
#10 0xffffffffdbebc0be in pfi_kif_update (kif=3D0xffffff000739d500) at /usr= /src/sys/modules/pf/../../contrib/pf/net/pf_if.c:520
#11 0xffffffffdbebc= 0ec in pfi_kif_update (kif=3D0xffffff0007733000) at /usr/src/sys/modules/pf= /../../contrib/pf/net/pf_if.c:525
#12 0xffffffffdbebc15c in pfi_ifaddr_event (arg=3DVariable "arg" = is not available.) at /usr/src/sys/modules/pf/../../contrib/pf/net/pf_if.c:= 942
#13 0xffffffff8058b54c in in_control (so=3DVariable "so" i= s not available.) at /usr/src/sys/netinet/in.c:476
#14 0xffffffff8054ea6f in ifioctl (so=3D0xffffff002007a5a0, cmd=3D214960770= 5, data=3D0xffffff0005ef3ac0 "ng2", td=3D0xffffff00077ae000) at /= usr/src/sys/net/if.c:1952
#15 0xffffffff804ed9f4 in kern_ioctl (td=3D0xf= fffff00077ae000, fd=3D26, com=3D2149607705, data=3D0xffffff0005ef3ac0 "= ;ng2") at file.h:268
#16 0xffffffff804edcfa in ioctl (td=3D0xffffff00077ae000, uap=3D0xffffffffd= bff5bf0) at /usr/src/sys/kern/sys_generic.c:570
#17 0xffffffff8078a7c7 i= n syscall (frame=3D0xffffffffdbff5c80) at /usr/src/sys/amd64/amd64/trap.c:9= 07
#18 0xffffffff8077088b in Xfast_syscall () at /usr/src/sys/amd64/amd64/exce= ption.S:330
#19 0x000000080188137c in ?? ()
Previous frame inner to t= his frame (corrupt stack?)
--000e0cd2301abeffad046200bc47-- From owner-freebsd-net@FreeBSD.ORG Tue Feb 3 12:20:02 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E0543106567E for ; Tue, 3 Feb 2009 12:20:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id B491E8FC23 for ; Tue, 3 Feb 2009 12:20:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n13CK2rU096457 for ; Tue, 3 Feb 2009 12:20:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n13CK2Kh096456; Tue, 3 Feb 2009 12:20:02 GMT (envelope-from gnats) Date: Tue, 3 Feb 2009 12:20:02 GMT Message-Id: <200902031220.n13CK2Kh096456@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Adam K Kirchhoff Cc: Subject: Re: kern/131153: [iwi] iwi doesn't see a wireless network X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adam K Kirchhoff List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2009 12:20:03 -0000 The following reply was made to PR kern/131153; it has been noted by GNATS. From: Adam K Kirchhoff To: bug-followup@FreeBSD.org, adamk@voicenet.com Cc: Subject: Re: kern/131153: [iwi] iwi doesn't see a wireless network Date: Tue, 3 Feb 2009 07:13:43 -0500 Is there anything further I can do to help identify this problem? Adam -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From owner-freebsd-net@FreeBSD.ORG Tue Feb 3 12:27:40 2009 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CC2F91065670; Tue, 3 Feb 2009 12:27:40 +0000 (UTC) (envelope-from dlt@mebtel.net) Received: from mail961c35.nsolutionszone.com (mail961c35.nsolutionszone.com [209.235.152.151]) by mx1.freebsd.org (Postfix) with ESMTP id 949B58FC1C; Tue, 3 Feb 2009 12:27:40 +0000 (UTC) (envelope-from dlt@mebtel.net) X-POP-User: dlt.mebtel.net Received: from localhost (66-79-79-183.dsl.mebtel.net [66.79.79.183]) by mail961c35.nsolutionszone.com (8.13.6.20060614/8.13.1) with ESMTP id n13CRcAe024813; Tue, 3 Feb 2009 12:27:39 GMT Date: Tue, 3 Feb 2009 07:27:37 -0500 From: Derek Tattersall To: Robert Watson Message-ID: <20090203122737.GA62874@oriental.arm.org> References: <20090201183057.GA47405@oriental.arm.org> <20090202222414.GA59860@oriental.arm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@FreeBSD.org Subject: Re: Multicast source address in recvfrom() X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dlt@mebtel.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2009 12:27:41 -0000 * Robert Watson [090203 06:17]: > > >* Robert Watson [090202 17:06]: > >>On Sun, 1 Feb 2009, Derek Tattersall wrote: > >> > >>>In order to become familiar with multicast implementation using FreeBSD, > >>>I found via Google a pair of test programs which multicast sent a simple > >>>text message and received the text message. I added some code to report > >>>the source address, because none of the references that I looked at > >>>specified the source IP address in the frame. > >>> > >>>I ran the sender on A -current system, AMD64 vintage last week. The > >>>receiver was on a -current system I386 vintage last week. TCPDUMP shows > >>>the source IP address in the frame as (correctly) 192.168.0.15. The > >>>receiver reports the source IP address as 200.231.191.191. I have also > >>>run the same test with an OpenBSD 4.4 Release I386 system as the > >>>receiver. The openBSD system reports the sender as 192.168.0.15. A > >>>Fedora 10 system reported the source IP address as 0.0.0.0. > >>> > >>>Googling the RFCs and other information and referring to Comer's and > >>>Stevens' books on TCPIP I can't determine what should be reported. Does > >>>anybody have clue for me? > >> > >>It might depend on how you're querying the source address. Could you > >>post a code excerpt? > > > >It's a straightforward test program. > > Your assumption, that the address returned from recvfrom(2) should be > correct, seems generally right to me. However, it looks like you may not > be initializing senderLen to the size of senderAddr, which means that the > size getting passed in may be random stack garbage. In which case what you > find in the sockaddr_in might also be random stack garbage, or might be the > address, depending on whether the uninitialized length was long enough to > fit an IP address in. Could you try adding something like: > > senderLen = sizeof(senderAddr); > > before the call to recvfrom(2)? > > Thanks, > > Robert N M Watson > Computer Laboratory > University of Cambridge > -------------------------------- Snip test program --------------- You nailed it! Initializing the length of the sockaddr stucture was the answer. Thanks very much for pointing out the flaw. -- Best regards, Derek Tattersall dlt@mebtel.net dlt666@yahoo.com dtatters@gmail.com From owner-freebsd-net@FreeBSD.ORG Wed Feb 4 01:59:53 2009 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 94C921065672; Wed, 4 Feb 2009 01:59:53 +0000 (UTC) (envelope-from jchambers@ucla.edu) Received: from out-21.smtp.ucla.edu (out-21.smtp.ucla.edu [169.232.47.166]) by mx1.freebsd.org (Postfix) with ESMTP id 5CC228FC08; Wed, 4 Feb 2009 01:59:53 +0000 (UTC) (envelope-from jchambers@ucla.edu) Received: from mail.ucla.edu (mail.ucla.edu [169.232.48.150]) by smtp-4.smtp.ucla.edu (8.14.3/8.14.3) with ESMTP id n141xZpI001283; Tue, 3 Feb 2009 17:59:35 -0800 Received: from computer.local ([149.142.36.207]) (authenticated bits=0) by mail.ucla.edu (8.13.8/8.13.8) with ESMTP id n141xZhf001168 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 3 Feb 2009 17:59:35 -0800 Message-ID: <4988F687.4050105@ucla.edu> Date: Tue, 03 Feb 2009 17:59:35 -0800 From: Jason Chambers Organization: UCLA User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: rwatson@FreeBSD.org, freebsd-net@FreeBSD.org, bug-followup@FreeBSD.org References: <200902021344.n12DieCX021758@freefall.freebsd.org> In-Reply-To: <200902021344.n12DieCX021758@freefall.freebsd.org> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Probable-Spam: no X-Scanned-By: smtp.ucla.edu on 169.232.47.244 Cc: Subject: Re: kern/130605: [tcp] Certain hardware produces "Network is unreachable" errors for scanning tools X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2009 01:59:53 -0000 rwatson@FreeBSD.org wrote: > Thanks for your detailed bug report. It seems like a few things are going > on here, and probably need to be diagnosed individaully. First, the error > reported by Nessus, "BIOCSRTIEOUT: Invalid argument" can, I believe, only > be triggered in the following kernel code: (...) > > This suggests that Nessus is passing an unexpectedly high or low number > of usec's, and is therefore probably an application bug. Thanks for pointing this out. Although unrelated to the issue at hand it possibly impacts nessus results and will help push their support team in the right direction. I see this error on a FreeBSD system that successfully runs scans. > > In general, "Network is unreachable" (ENETUNREACH) is generated by protocol > sockets when the destination host is on a non-local network and the gateway > specified in the route to the host is unreachable -- for example, ARP can't > find the gateway, the device link is down, etc. > > Is there any indication in the system logs of the link state going up and > down? You can use "route -n monitor" to track some of the relevant events. > Given that you've tried multiple cards, I can't help but wondering if > there is a cabling, switch, or router problem, so if you haven't already, > I'd follow those possible lines of diagnosis as well. There's no indication of interface flapping in the logs and I checked that the underlying infrastructure is fine. Route -n monitor shows nothing before and during the NMap or Nessus scanning. I suspect it's hardware related because not all FreeBSD (7.1-p2) systems I'm using have the problem. The commonality in all of it is newer Dell rack server systems ( 8-core PowerEdge 1950 and SC1435's). This "Network is unreachable" error seems to always occur with NMAP's OS discovery phase. ex: nmap -sS -p 22 -O host However, only on the SC1435's does Nessus fail to run successfully. When I say run, I mean the nessus process successfully sends out probe traffic (verified at the remote destination) but ignores the replies. Tcpdump shows that they arrive fine. The only thing different about these SC1435's from other systems is a patch I've applied to have the ServerWorks HT1000 controller work. (ata_ht1000.patch) http://unix.derkeiler.com/Mailing-Lists/FreeBSD/stable/2008-10/msg00039.html I converted two of the servers to Linux and everything works fine with them. Rather than bury the problem I'd like to understand what fails. I can give access to one or both of these machines if it would help the effort. Otherwise, any suggestions on what tests I should run to further isolate this problem to a specific subsystem ? --Jason From owner-freebsd-net@FreeBSD.ORG Wed Feb 4 02:00:13 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C45981065673 for ; Wed, 4 Feb 2009 02:00:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id B0C448FC13 for ; Wed, 4 Feb 2009 02:00:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n14203BG015374 for ; Wed, 4 Feb 2009 02:00:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n14203lg015373; Wed, 4 Feb 2009 02:00:03 GMT (envelope-from gnats) Date: Wed, 4 Feb 2009 02:00:03 GMT Message-Id: <200902040200.n14203lg015373@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Jason Chambers Cc: Subject: Re: kern/130605: [tcp] Certain hardware produces "Network is unreachable" errors for scanning tools X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Jason Chambers List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2009 02:00:14 -0000 The following reply was made to PR kern/130605; it has been noted by GNATS. From: Jason Chambers To: rwatson@FreeBSD.org, freebsd-net@FreeBSD.org, bug-followup@FreeBSD.org Cc: Subject: Re: kern/130605: [tcp] Certain hardware produces "Network is unreachable" errors for scanning tools Date: Tue, 03 Feb 2009 17:59:35 -0800 rwatson@FreeBSD.org wrote: > Thanks for your detailed bug report. It seems like a few things are going > on here, and probably need to be diagnosed individaully. First, the error > reported by Nessus, "BIOCSRTIEOUT: Invalid argument" can, I believe, only > be triggered in the following kernel code: (...) > > This suggests that Nessus is passing an unexpectedly high or low number > of usec's, and is therefore probably an application bug. Thanks for pointing this out. Although unrelated to the issue at hand it possibly impacts nessus results and will help push their support team in the right direction. I see this error on a FreeBSD system that successfully runs scans. > > In general, "Network is unreachable" (ENETUNREACH) is generated by protocol > sockets when the destination host is on a non-local network and the gateway > specified in the route to the host is unreachable -- for example, ARP can't > find the gateway, the device link is down, etc. > > Is there any indication in the system logs of the link state going up and > down? You can use "route -n monitor" to track some of the relevant events. > Given that you've tried multiple cards, I can't help but wondering if > there is a cabling, switch, or router problem, so if you haven't already, > I'd follow those possible lines of diagnosis as well. There's no indication of interface flapping in the logs and I checked that the underlying infrastructure is fine. Route -n monitor shows nothing before and during the NMap or Nessus scanning. I suspect it's hardware related because not all FreeBSD (7.1-p2) systems I'm using have the problem. The commonality in all of it is newer Dell rack server systems ( 8-core PowerEdge 1950 and SC1435's). This "Network is unreachable" error seems to always occur with NMAP's OS discovery phase. ex: nmap -sS -p 22 -O host However, only on the SC1435's does Nessus fail to run successfully. When I say run, I mean the nessus process successfully sends out probe traffic (verified at the remote destination) but ignores the replies. Tcpdump shows that they arrive fine. The only thing different about these SC1435's from other systems is a patch I've applied to have the ServerWorks HT1000 controller work. (ata_ht1000.patch) http://unix.derkeiler.com/Mailing-Lists/FreeBSD/stable/2008-10/msg00039.html I converted two of the servers to Linux and everything works fine with them. Rather than bury the problem I'd like to understand what fails. I can give access to one or both of these machines if it would help the effort. Otherwise, any suggestions on what tests I should run to further isolate this problem to a specific subsystem ? --Jason From owner-freebsd-net@FreeBSD.ORG Wed Feb 4 14:35:27 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 90E051065688; Wed, 4 Feb 2009 14:35:27 +0000 (UTC) (envelope-from mmitar@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by mx1.freebsd.org (Postfix) with ESMTP id E9A098FC2E; Wed, 4 Feb 2009 14:35:26 +0000 (UTC) (envelope-from mmitar@gmail.com) Received: by ey-out-2122.google.com with SMTP id d26so304289eyd.7 for ; Wed, 04 Feb 2009 06:35:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=TyCiW8sWQTnaDd6l0NrkPB86xTH87WhziB5ZY9k4YRM=; b=EeO6GAkRxguuTAdVW4hyUvTivxJLGm1tKe6/sECmYCrebFiDnBCGc/2kQSXesU7f3Q LORtDnnx2ImXhx3cVNSk9PSdIc550i2L9Xs83jmxFE3RUph/sZGJEU9xuTWMeEPp6xt7 yj8Rjwh3pNdfaDtOevKAJ6eya+79Z1C5+j8Tg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=m7MUqzRvFxZKfa13NYtoVvklntYJw95Xwga1eiy4+hzC0TPLYgEN7qOePDC3YvSAei +eLOhUfan9OOY3bMvoJipyp0ZaU8Nh6LvwsMfjGwPLgspd0WMLmHDS+H5pBcwOGOG6sD RPl5DUVacD76+hnRJrhdNcnVh2muBk+n4MLnQ= MIME-Version: 1.0 Received: by 10.210.57.5 with SMTP id f5mr6220786eba.14.1233758125819; Wed, 04 Feb 2009 06:35:25 -0800 (PST) In-Reply-To: References: Date: Wed, 4 Feb 2009 15:35:25 +0100 Message-ID: From: Mitar To: Robert Watson Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: read() returns ETIMEDOUT X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2009 14:35:28 -0000 Hi! > sysctl net.inet.tcp | grep keep net.inet.tcp.keepidle: 7200000 net.inet.tcp.keepintvl: 75000 net.inet.tcp.keepinit: 75000 net.inet.tcp.always_keepalive: 1 I am using FreeBSD 7.0-STABLE on amd64 architecture and bge network interface. Server has around 5 MB/s (megabytes) almost constant rx/tx rate. I use pf firewall and there are a lot of connections opened, for example, some pf states stats: State Table Total Rate current entries 17042 searches 6752096417 14750.6/s inserts 66200602 144.6/s removals 66183560 144.6/s I have been sending a TCP/IP data with netcat listening on the server side and netcat sending from the client. It was not so fast connection (around 50 kB/s (kilobytes) connection on average) but it was a stable steady sending. Server has much more bandwidth available. The connection has lasted only around 12 minutes and only 30 MB of data has been transferred until the time the server closed the connection. The problem is that this is repeatable (I have repeated this test many times) and under such load it happens always. If I disable/cancel all other load on the server the connection is not broken by the server. > (3) TCP retransmit timer reaches its full exponntial backoff without being > ACK'd. (tcp_timer_rexmt) I believe it is because of this. I could not insert kernel printf as I am unable to reboot the server at the moment but I have been checking drop counters with netstat and at the moment the connection broke "connections dropped by rexmit timeout" counter increased. It is true that the counters are increasing almost all the time under the load but I believe that I have timed this correctly. > It would also be useful, if possible, to look at the tcpdump for the last > portion of the connection, perhaps ideally from the second-to-last ACK from > the remote host to the connection reset from the local end. It might be > worth running tcpdump on both sides to see if they see the same thing -- for > example, does one side think it's sending ACKs and the other not receive it? I have put complete logs on the net: http://mitar.tnode.com/Temp/timeout-tcpdump-client.txt.gz http://mitar.tnode.com/Temp/timeout-tcpdump-server.txt.gz Client is NATed behind a router on a different ISP. > In the previous thread, it looked a bit like the outcome was that there was > a memory exhaustion issue under load, and that bumping nmbclusters helped at > least defer that problem. So it would be useful to see the output of > netstat -m before and after (for as small an epsilon as you can make it) the > connection is timed out. I realize capturing the above sorts of data can be > an issue on high-load boxes but if we can, it would be quite helpful. > Regardless of that, knowing if you're seeing allocation errors in the > netstat -m output would be helpful. I doubt that it is a memory issue as I have been monitoring those allocations and they do not come near max values. current netstat -m output is: 10657/8228/18885 mbufs in use (current/cache/total) 8248/7388/15636/25600 mbuf clusters in use (current/cache/total/max) 8248/5994 mbuf+clusters out of packet secondary zone in use (current/cache) 1839/774/2613/12800 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) 26857K/19929K/46786K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/0/0 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 27072 requests for I/O initiated by sendfile 0 calls to protocol drain routines Mitar From owner-freebsd-net@FreeBSD.ORG Wed Feb 4 18:50:07 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 627A81065720 for ; Wed, 4 Feb 2009 18:50:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [62.111.66.27]) by mx1.freebsd.org (Postfix) with ESMTP id 0F8D88FC26 for ; Wed, 4 Feb 2009 18:50:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from localhost (amavis.str.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 375B241C705; Wed, 4 Feb 2009 19:50:06 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([62.111.66.27]) by localhost (amavis.str.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id pDFSOKXsw7iZ; Wed, 4 Feb 2009 19:50:05 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id DE0A141C733; Wed, 4 Feb 2009 19:50:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id AA7AD4448E6; Wed, 4 Feb 2009 18:48:53 +0000 (UTC) Date: Wed, 4 Feb 2009 18:48:53 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Julian Elischer In-Reply-To: <4987548A.7000609@elischer.org> Message-ID: <20090204184526.I93725@maildrop.int.zabbadoz.net> References: <498414E5.7020904@elischer.org> <4984241B.5010103@elischer.org> <4987548A.7000609@elischer.org> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD Net , FreeBSD virtualization mailing list Subject: Re: Vimage globals vs structures measurements. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2009 18:50:10 -0000 On Mon, 2 Feb 2009, Julian Elischer wrote: Hi, > If I can get some confirmation of this by others then > the next step would be to simply remove the VIMAGE_GLOBALS option > and all the global variables it covers. > > At least that's what seems next to me.. no, the next step is to bring in the beaf (last step). I think we had clearly decided (somewhen, somewho) that we want one version with all three options at the same time. Once we are confident, hopefully after a few days at that point, VIMAGE_GLOBALS will go away. So please do not rape that out. In two months there were no real accidents wrt. VIMAGE_GLOBALS even with all the larger changes that went in. I think it's safe to keep them another 4-6 weeks. /bz -- Bjoern A. Zeeb The greatest risk is not taking one. From owner-freebsd-net@FreeBSD.ORG Wed Feb 4 19:15:08 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 62FFF106566B; Wed, 4 Feb 2009 19:15:08 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from mail.cksoft.de (mail.cksoft.de [62.111.66.27]) by mx1.freebsd.org (Postfix) with ESMTP id 150C38FC19; Wed, 4 Feb 2009 19:15:08 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from localhost (amavis.str.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 3BABD41C730; Wed, 4 Feb 2009 20:00:06 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([62.111.66.27]) by localhost (amavis.str.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id tROmd48uLAWT; Wed, 4 Feb 2009 20:00:05 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id DF73A41C711; Wed, 4 Feb 2009 20:00:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 625DF4448E6; Wed, 4 Feb 2009 18:59:07 +0000 (UTC) Date: Wed, 4 Feb 2009 18:59:07 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Julian Elischer In-Reply-To: <20090204184526.I93725@maildrop.int.zabbadoz.net> Message-ID: <20090204185656.B93725@maildrop.int.zabbadoz.net> References: <498414E5.7020904@elischer.org> <4984241B.5010103@elischer.org> <4987548A.7000609@elischer.org> <20090204184526.I93725@maildrop.int.zabbadoz.net> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD Net , FreeBSD virtualization mailing list Subject: Re: Vimage globals vs structures measurements. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2009 19:15:09 -0000 On Wed, 4 Feb 2009, Bjoern A. Zeeb wrote: > On Mon, 2 Feb 2009, Julian Elischer wrote: > > Hi, > >> If I can get some confirmation of this by others then >> the next step would be to simply remove the VIMAGE_GLOBALS option >> and all the global variables it covers. >> >> At least that's what seems next to me.. > > no, the next step is to bring in the beaf (last step). ... beef ... anyway. The indirection, the real virtualization, the multiple images, ... you count my typos;) > I think we had clearly decided (somewhen, somewho) that we want one > version with all three options at the same time. > Once we are confident, hopefully after a few days at that point, > VIMAGE_GLOBALS will go away. > > So please do not rape that out. In two months there were no real > accidents wrt. VIMAGE_GLOBALS even with all the larger changes that > went in. I think it's safe to keep them another 4-6 weeks. > > /bz > > -- Bjoern A. Zeeb The greatest risk is not taking one. From owner-freebsd-net@FreeBSD.ORG Thu Feb 5 17:31:24 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 39351106570B for ; Thu, 5 Feb 2009 17:31:24 +0000 (UTC) (envelope-from feh@fehcom.de) Received: from mail.fehcom.net (hamburg134.server4you.de [217.172.188.134]) by mx1.freebsd.org (Postfix) with ESMTP id 97ABC8FC12 for ; Thu, 5 Feb 2009 17:31:23 +0000 (UTC) (envelope-from feh@fehcom.de) Received: (qmail 31863 invoked from network); 5 Feb 2009 17:04:41 -0000 Received: from static-87-79-92-176.netcologne.de (HELO fehnet.fehcom.de) (feh@fehcom.de@87.79.92.176) by mail.fehcom.net with ESMTPA; 5 Feb 2009 17:04:41 -0000 Received: (qmail 16365 invoked from network); 5 Feb 2009 17:05:10 -0000 Received: from dhcp-108.fehnet.de (HELO ?192.168.192.108?) (192.168.192.108) by artigo.fehnet.de with ESMTP; 5 Feb 2009 17:05:10 -0000 Date: Thu, 05 Feb 2009 18:03:21 +0100 From: Erwin Hoffmann To: freebsd-net@freebsd.org Message-ID: X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: kern/130820: [ndis] wpa_supplicant(8) returns 'no space on device' X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 17:31:28 -0000 Hi, I just saw Paul Mahol's comment: >Yet another invalid bug report. >OP should use -Dndis and not -Dbsd > >-- >Paul Well. If things would be sooo easy. Trying to declare "-D ndis" in the wpa_supplicant call as additional argument yields: artemis# pwd /etc/rc.d artemis# ./wpa_supplicant start ndis0 Starting wpa_supplicant. Unsupported driver 'ndis'. This is my kernel setup: artemis# kldstat -v | grep wlan 300 wlan_ccmp 301 wlan_tkip 302 wlan_wep 303 wlan artemis# kldstat -v | grep ndis 5 3 0xc0c73000 17734 ndis.ko 3 ndisapi 6 2 0xc0c8b000 caa4 if_ndis.ko 4 cardbus/ndis 5 pci/ndis 6 pccard/ndis 7 uhub/ndis What am I missing ? regards. --eh. --- Dr. Erwin Hoffmann | FEHCom | http://www.fehcom.de/ From owner-freebsd-net@FreeBSD.ORG Thu Feb 5 17:56:10 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 209F2106564A for ; Thu, 5 Feb 2009 17:56:10 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.187]) by mx1.freebsd.org (Postfix) with ESMTP id A85E48FC20 for ; Thu, 5 Feb 2009 17:56:09 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by nf-out-0910.google.com with SMTP id h3so72980nfh.33 for ; Thu, 05 Feb 2009 09:56:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=R8DirIkr2rdZp/brW5f+pLTt1/qfkkSjKEhQN2zWN1s=; b=vC60KinlerxSNuT2W9dLTcdXxsVdfu4G+yP9BSANHUbmLgLdjanDzkoNTBhAC4bHIY 0Ias+p/7S3pu4QWuzQ1zm4OUY6dvbVXAUZMebd0wkz6LP6LC1PMvDSNJQTnntFWcxai5 9+1Z4dCapWEsIE9V/8R0PFvTypEX9+EJYwgy0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Hng2cfTQHWv/D8onQUT1SLAoS0rQ49DYVrgxczIMnvgCzxyf6pmfI8LBkU9KcvFA1S psjY0qAesjfe+jFAw6SvRyJY9CUa4jz6E1E9Scr7nieYPatxdjIm3CjORxZon+ASJeOw 4A2vCwMNkDrKUz2yuSD2n4/jo6MnGFlzDy0Xg= MIME-Version: 1.0 Received: by 10.210.76.4 with SMTP id y4mr570537eba.23.1233856566924; Thu, 05 Feb 2009 09:56:06 -0800 (PST) In-Reply-To: References: Date: Thu, 5 Feb 2009 18:56:06 +0100 Message-ID: <3a142e750902050956ldf9a9c4q1ce33f60f36bead2@mail.gmail.com> From: "Paul B. Mahol" To: Erwin Hoffmann Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: kern/130820: [ndis] wpa_supplicant(8) returns 'no space on device' X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 17:56:10 -0000 On 2/5/09, Erwin Hoffmann wrote: > Hi, > > I just saw Paul Mahol's comment: > >>Yet another invalid bug report. >>OP should use -Dndis and not -Dbsd >> >>-- >>Paul > > Well. If things would be sooo easy. > Trying to declare "-D ndis" in the wpa_supplicant call as additional > argument yields: > > artemis# pwd > /etc/rc.d > artemis# ./wpa_supplicant start ndis0 > Starting wpa_supplicant. > Unsupported driver 'ndis'. > > This is my kernel setup: > > artemis# kldstat -v | grep wlan > 300 wlan_ccmp > 301 wlan_tkip > 302 wlan_wep > 303 wlan > > artemis# kldstat -v | grep ndis > 5 3 0xc0c73000 17734 ndis.ko > 3 ndisapi > 6 2 0xc0c8b000 caa4 if_ndis.ko > 4 cardbus/ndis > 5 pci/ndis > 6 pccard/ndis > 7 uhub/ndis > > What am I missing ? > > regards. > --eh. > > > > --- > Dr. Erwin Hoffmann | FEHCom | http://www.fehcom.de/ > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > wpa_supplicant works fine on 8.0 with ndisX vaps. (and on 7 branch it should work too) Your is not configured with support for ndis. Please read carefully wpa_supplicant configuration options. -- Paul From owner-freebsd-net@FreeBSD.ORG Thu Feb 5 19:33:19 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 61D85106564A for ; Thu, 5 Feb 2009 19:33:19 +0000 (UTC) (envelope-from feh@fehcom.de) Received: from mail.fehcom.net (hamburg134.server4you.de [217.172.188.134]) by mx1.freebsd.org (Postfix) with ESMTP id C1FE38FC08 for ; Thu, 5 Feb 2009 19:33:18 +0000 (UTC) (envelope-from feh@fehcom.de) Received: (qmail 607 invoked from network); 5 Feb 2009 19:33:17 -0000 Received: from static-87-79-92-176.netcologne.de (HELO fehnet.fehcom.de) (feh@fehcom.de@87.79.92.176) by mail.fehcom.net with ESMTPA; 5 Feb 2009 19:33:17 -0000 Received: (qmail 21058 invoked from network); 5 Feb 2009 19:33:47 -0000 Received: from nathanw.fehnet.de (HELO ?192.168.192.23?) (192.168.192.23) by artigo.fehnet.de with ESMTP; 5 Feb 2009 19:33:47 -0000 Date: Thu, 05 Feb 2009 20:32:26 +0100 From: Erwin Hoffmann To: "Paul B. Mahol" Message-ID: In-Reply-To: <3a142e750902050956ldf9a9c4q1ce33f60f36bead2@mail.gmail.com> References: <3a142e750902050956ldf9a9c4q1ce33f60f36bead2@mail.gmail.com> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: freebsd-net@freebsd.org Subject: Re: kern/130820: [ndis] wpa_supplicant(8) returns 'no space on device' X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 19:33:19 -0000 Hi Paul, --On 5. Februar 2009 18:56:06 +0100 "Paul B. Mahol" wrote: > On 2/5/09, Erwin Hoffmann wrote: >> Hi, >> >> I just saw Paul Mahol's comment: >> >>> Yet another invalid bug report. >>> OP should use -Dndis and not -Dbsd >>> >>> -- >>> Paul >> >> Well. If things would be sooo easy. >> Trying to declare "-D ndis" in the wpa_supplicant call as additional >> argument yields: >> >> artemis# pwd >> /etc/rc.d >> artemis# ./wpa_supplicant start ndis0 >> Starting wpa_supplicant. >> Unsupported driver 'ndis'. >> >> This is my kernel setup: >> >> artemis# kldstat -v | grep wlan >> 300 wlan_ccmp >> 301 wlan_tkip >> 302 wlan_wep >> 303 wlan >> >> artemis# kldstat -v | grep ndis >> 5 3 0xc0c73000 17734 ndis.ko >> 3 ndisapi >> 6 2 0xc0c8b000 caa4 if_ndis.ko >> 4 cardbus/ndis >> 5 pci/ndis >> 6 pccard/ndis >> 7 uhub/ndis >> >> What am I missing ? >> > > wpa_supplicant works fine on 8.0 with ndisX vaps. (and on 7 branch it > should work too) > > Your is not configured with support for ndis. Please read carefully > wpa_supplicant configuration options. It would help me (and everybody) if you could shed a little light on that subject. Apart from patching wpa_supplicant 0.3.11 and the most current to work under FreeBSD, I'm probably missing an import piece of information. Neither the man pages nor the current FreeBSD docs indicate (at least for me) the necessary adjustments. I'm certainly willing to raise a general web page about those issues (wlan/eap/802.11x) on my technical web site (https://www.fehcom.net). regards. --eh. > > -- > Paul > Dr. Erwin Hoffmann | FEHCom | http://www.fehcom.de From owner-freebsd-net@FreeBSD.ORG Thu Feb 5 22:55:33 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7058D10656BA; Thu, 5 Feb 2009 22:55:33 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 45CAA8FC0C; Thu, 5 Feb 2009 22:55:33 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n15MtXvi051504; Thu, 5 Feb 2009 22:55:33 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n15MtXgZ051500; Thu, 5 Feb 2009 22:55:33 GMT (envelope-from linimon) Date: Thu, 5 Feb 2009 22:55:33 GMT Message-Id: <200902052255.n15MtXgZ051500@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/131414: [sis] [patch] Receive large packets by Vlan that parent if_sis (don't) work X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 22:55:34 -0000 Old Synopsis: Receive large packets by Vlan that parent if_sis (don't) work New Synopsis: [sis] [patch] Receive large packets by Vlan that parent if_sis (don't) work Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Thu Feb 5 22:55:01 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=131414 From owner-freebsd-net@FreeBSD.ORG Fri Feb 6 00:28:48 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 65F4B106566C for ; Fri, 6 Feb 2009 00:28:48 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-ew0-f21.google.com (mail-ew0-f21.google.com [209.85.219.21]) by mx1.freebsd.org (Postfix) with ESMTP id C49418FC17 for ; Fri, 6 Feb 2009 00:28:47 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by ewy14 with SMTP id 14so1192844ewy.19 for ; Thu, 05 Feb 2009 16:28:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Xil8kiqFWYiiKwfXBbcQ6IxAKSrJRakjCnvom+a+TEo=; b=I47m1aia/qQ7C9u5LLLvDrYJqTWyC9T0TGoQArQvUKppNXG+rxgbufcELQIq9rFvy8 RKGatyV1D9E1kwKv6Mz98TUD39Bjhay9RemAZau+LqVdzl56T3oMtw+gd+M0vmgvcX3a BTxHicmhK1wQZ4p6fKinQxApxNWWy+gSqN8Yg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=NZvL1dqH74HUQJcnOlihXkoXZSxE07bp9Kgk8CKM+pwGkVXybIyKfufmwWj03TXRVQ tj7PrsbvwihxVnjGTT3zNzLUNwxg0g8se8Y1gJ54VxaSNNi2+w1gsKM4TiZ/jNaZIob6 3Y6e8lxIO4PTbxRl+fCm7LEKLl2z7/BATaxv8= MIME-Version: 1.0 Received: by 10.210.62.3 with SMTP id k3mr791465eba.182.1233880126811; Thu, 05 Feb 2009 16:28:46 -0800 (PST) In-Reply-To: References: <3a142e750902050956ldf9a9c4q1ce33f60f36bead2@mail.gmail.com> Date: Fri, 6 Feb 2009 01:28:46 +0100 Message-ID: <3a142e750902051628x25eeeddbxf1f9512c46028442@mail.gmail.com> From: "Paul B. Mahol" To: Erwin Hoffmann Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: kern/130820: [ndis] wpa_supplicant(8) returns 'no space on device' X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 00:28:48 -0000 On 2/5/09, Erwin Hoffmann wrote: > Hi Paul, > > > --On 5. Februar 2009 18:56:06 +0100 "Paul B. Mahol" > wrote: > >> On 2/5/09, Erwin Hoffmann wrote: >>> Hi, >>> >>> I just saw Paul Mahol's comment: >>> >>>> Yet another invalid bug report. >>>> OP should use -Dndis and not -Dbsd >>>> >>>> -- >>>> Paul >>> >>> Well. If things would be sooo easy. >>> Trying to declare "-D ndis" in the wpa_supplicant call as additional >>> argument yields: >>> >>> artemis# pwd >>> /etc/rc.d >>> artemis# ./wpa_supplicant start ndis0 >>> Starting wpa_supplicant. >>> Unsupported driver 'ndis'. >>> >>> This is my kernel setup: >>> >>> artemis# kldstat -v | grep wlan >>> 300 wlan_ccmp >>> 301 wlan_tkip >>> 302 wlan_wep >>> 303 wlan >>> >>> artemis# kldstat -v | grep ndis >>> 5 3 0xc0c73000 17734 ndis.ko >>> 3 ndisapi >>> 6 2 0xc0c8b000 caa4 if_ndis.ko >>> 4 cardbus/ndis >>> 5 pci/ndis >>> 6 pccard/ndis >>> 7 uhub/ndis >>> >>> What am I missing ? >>> >> >> wpa_supplicant works fine on 8.0 with ndisX vaps. (and on 7 branch it >> should work too) >> >> Your is not configured with support for ndis. Please read carefully >> wpa_supplicant configuration options. > > It would help me (and everybody) if you could shed a little light on that > subject. > > Apart from patching wpa_supplicant 0.3.11 and the most current to work > under FreeBSD, I'm probably missing an import piece of information. Neither > the man pages nor the current FreeBSD docs indicate (at least for me) the > necessary adjustments. wpa_supplicant is contributed software located in /usr/src/contrib/wpa_supplicant/ Makefiles to build wpa_supplicat for FreeBSD are in /usr/src/usr.sbin/wpa/wpa_supplicant/ -- Paul From owner-freebsd-net@FreeBSD.ORG Fri Feb 6 00:41:28 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0D6BB106566C; Fri, 6 Feb 2009 00:41:28 +0000 (UTC) (envelope-from yongari@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id D5A5D8FC1D; Fri, 6 Feb 2009 00:41:27 +0000 (UTC) (envelope-from yongari@FreeBSD.org) Received: from freefall.freebsd.org (yongari@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n160fRgI034947; Fri, 6 Feb 2009 00:41:27 GMT (envelope-from yongari@freefall.freebsd.org) Received: (from yongari@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n160fRej034943; Fri, 6 Feb 2009 00:41:27 GMT (envelope-from yongari) Date: Fri, 6 Feb 2009 00:41:27 GMT Message-Id: <200902060041.n160fRej034943@freefall.freebsd.org> To: gluk@slan.ru, yongari@FreeBSD.org, freebsd-net@FreeBSD.org, yongari@FreeBSD.org From: yongari@FreeBSD.org Cc: Subject: Re: kern/131414: [sis] [patch] Receive large packets by Vlan that parent if_sis (don't) work X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 00:41:28 -0000 Synopsis: [sis] [patch] Receive large packets by Vlan that parent if_sis (don't) work State-Changed-From-To: open->feedback State-Changed-By: yongari State-Changed-When: Fri Feb 6 00:39:51 UTC 2009 State-Changed-Why: I believe CURRENT already have fix for the issue. Would you try try r185784? Since sis(4) moved to dev directory in HEAD you should use http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/sis to check changes. Responsible-Changed-From-To: freebsd-net->yongari Responsible-Changed-By: yongari Responsible-Changed-When: Fri Feb 6 00:39:51 UTC 2009 Responsible-Changed-Why: Grab. http://www.freebsd.org/cgi/query-pr.cgi?pr=131414 From owner-freebsd-net@FreeBSD.ORG Fri Feb 6 16:52:56 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5A3AD106566B for ; Fri, 6 Feb 2009 16:52:56 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay10.ispgateway.de (smtprelay10.ispgateway.de [80.67.29.24]) by mx1.freebsd.org (Postfix) with ESMTP id DDCF68FC1E for ; Fri, 6 Feb 2009 16:52:55 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from [88.153.16.241] (helo=localhost) by smtprelay10.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1LVTwk-0000wF-BG for freebsd-net@freebsd.org; Fri, 06 Feb 2009 17:52:54 +0100 Date: Fri, 6 Feb 2009 17:52:43 +0100 From: Fabian Keil To: freebsd-net@freebsd.org Message-ID: <20090206175243.70b93f65@fabiankeil.de> In-Reply-To: <20090202094226.E983@desktop> References: <20090131125100.N983@desktop> <20090201160544.4f1961b4@fabiankeil.de> <20090201170550.482bf325@fabiankeil.de> <20090202094226.E983@desktop> X-Mailer: Claws Mail 3.7.0 (GTK+ 2.14.7; i386-portbld-freebsd8.0) X-PGP-KEY-URL: http://www.fabiankeil.de/gpg-keys/freebsd-listen-2008-08-18.asc Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/uEWAKkW2bnM6wwEssf4u9mz"; protocol="application/pgp-signature"; micalg=PGP-SHA1 X-Df-Sender: 775067 Subject: Re: mbuf revision, testers/comments wanted. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 16:52:56 -0000 --Sig_/uEWAKkW2bnM6wwEssf4u9mz Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Jeff Roberson wrote: > On Sun, 1 Feb 2009, Fabian Keil wrote: >=20 > > Fabian Keil wrote: > > > >> Jeff Roberson wrote: > >> > >>> http://people.freebsd.org/~jeff/mbuf_ref2.diff > >> > >>> I have been experimenting with different revisions to the mbuf api to > >>> improve performance and simplify code. This patch is the first of > >>> several proposed steps towards those goals. The aim of this patch is > >>> two fold; > >> > >>> I would appreciate testing feedback from varied workloads to make > >>> sure there are no bugs before I go forward with this. I have tested > >>> only host oriented networking with a few drivers. It is not > >>> anticipated that there will be any significant incompatibilities > >>> introduced with this round but there is always that possibility. > > > >> 5) > >> Finally, I tested the patch on an IBM ThinPad R51. The kernel > >> hangs on boot, the last messages are (hand transcribed): > >> > >> iwi0: mem 0xc0214000-0xc0214fff irq 11 > >> at device 2.0 on pci2 iwi0: Reserved 0x1000 bytes for rid 0x10 type 3 > >> at 0xc0214000 iwi0: could not allocate rx mbuf > >> iwi0: could not allocate Rx ring > >> bpfdetach: was not attached > > > > Never mind, kernel and user land weren't completely in > > sync and this might be related to the recent wlan commits. > > I'll retry with an up-to-date user land. > > >=20 > I have updated the patch here: >=20 > http://people.freebsd.org/~jeff/mbuf_ref2.diff Building world failed for me with: cc -O2 -pipe -Wall -Wmissing-prototypes -Wno-uninitialized -Wstrict-protot= ypes -I/usr/src/sbin/pfctl/../../contrib/pf/pfctl -DE k-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitializ= ed -Wno-pointer-sign -c /usr/src/sbin/pfctl/../../sys f_ruleset.c In file included from /usr/src/sbin/pfctl/../../sys/contrib/pf/net/pf_rules= et.c:48: /usr/obj/usr/src/tmp/usr/include/sys/mbuf.h:131: error: expected specifier-= qualifier-list before 'uma_zone_t' *** Error code 1 Stop in /usr/src/sbin/pfctl. *** Error code 1 Stop in /usr/src/sbin. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. Manually building from /usr/src/sbin worked, though. After resuming with make buildworld NO_CLEAN=3DYES, the next failure was: =3D=3D=3D> usr.bin/netstat (all) cc -O2 -pipe -fno-strict-aliasing -DIPSEC -DSCTP -DINET6 -DNETGRAPH -DIPX = -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-un= used-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wn= o-uninitialized -Wno-pointer-sign -c /usr/src/usr.bin/netstat/if.c cc -O2 -pipe -fno-strict-aliasing -DIPSEC -DSCTP -DINET6 -DNETGRAPH -DIPX = -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-un= used-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wn= o-uninitialized -Wno-pointer-sign -c /usr/src/usr.bin/netstat/inet.c cc -O2 -pipe -fno-strict-aliasing -DIPSEC -DSCTP -DINET6 -DNETGRAPH -DIPX = -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-un= used-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wn= o-uninitialized -Wno-pointer-sign -c /usr/src/usr.bin/netstat/main.c cc -O2 -pipe -fno-strict-aliasing -DIPSEC -DSCTP -DINET6 -DNETGRAPH -DIPX = -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-un= used-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wn= o-uninitialized -Wno-pointer-sign -c /usr/src/usr.bin/netstat/mbuf.c In file included from /usr/src/usr.bin/netstat/mbuf.c:46: /usr/obj/usr/src/tmp/usr/include/sys/mbuf.h:131: error: expected specifier-= qualifier-list before 'uma_zone_t' *** Error code 1 Stop in /usr/src/usr.bin/netstat. *** Error code 1 Stop in /usr/src/usr.bin. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. Again building from /usr/src/usr.bin worked. Resuming stopped with yet another similar error message but afterwards make buildworld NO_CLEAN=3DYES finished successfully. I haven't really investigated the problem yet, but it might have something to do with my make flags: fk@TP51 ~ $grep NO_ /etc/make.conf NO_BLUETOOTH=3D # do not build Bluetooth related stuff NO_FORTRAN=3D # do not build g77 and related libraries NO_I4B=3D # do not build isdn4bsd package NO_INET6=3D # do not build IPv6 related programs and libraries NO_IPFILTER=3D # do not build IP Filter package NO_KERBEROS=3D # do not build and install Kerberos 5 (KTH Heimdal) NO_LPR=3D # do not build lpr and related programs NO_MAILWRAPPER=3D # do not build the mailwrapper(8) MTA selector #NO_NIS=3D # do not build NIS support and related programs. NO_ATM=3Dyes NO_VINUM=3Dyes NO_OBJC=3Dyes NO_SHAREDOCS=3Dyes NO_PROFILE=3Dyes NO_PORTDOCS=3Dyes Commenting out the NO_INET6 line didn't make a difference. I'm using your patch on an IBM ThinPad R51 since three days and didn't notice any problems so far. I also briefly tested it on an AMD64 system but as sound stopped working I reverted to the old kernel after verifying that ssh worked. This is a snd_emu10kx(4) problem, though. Fabian --Sig_/uEWAKkW2bnM6wwEssf4u9mz Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkmMatsACgkQBYqIVf93VJ1fCgCeJNWV79r+F1tWB3a0J2BWQxVR IkIAn1uiaL1FAU0krz/3nNtNdgX+YH4V =O7aP -----END PGP SIGNATURE----- --Sig_/uEWAKkW2bnM6wwEssf4u9mz-- From owner-freebsd-net@FreeBSD.ORG Fri Feb 6 22:52:36 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 357CA1065686; Fri, 6 Feb 2009 22:52:36 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 0A8408FC1A; Fri, 6 Feb 2009 22:52:36 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from freefall.freebsd.org (rwatson@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n16MqZgK072484; Fri, 6 Feb 2009 22:52:35 GMT (envelope-from rwatson@freefall.freebsd.org) Received: (from rwatson@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n16MqZUw072480; Fri, 6 Feb 2009 22:52:35 GMT (envelope-from rwatson) Date: Fri, 6 Feb 2009 22:52:35 GMT Message-Id: <200902062252.n16MqZUw072480@freefall.freebsd.org> To: kent.fox@intermountainmail.org, rwatson@FreeBSD.org, freebsd-net@FreeBSD.org From: rwatson@FreeBSD.org Cc: Subject: Re: kern/112722: [udp] IP v4 udp fragmented packet reject X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 22:52:37 -0000 Synopsis: [udp] IP v4 udp fragmented packet reject State-Changed-From-To: feedback->open State-Changed-By: rwatson State-Changed-When: Fri Feb 6 22:51:58 UTC 2009 State-Changed-Why: Transition to open: the original submitter is no longer using this configuration, so we'll need someone to attempt to reproduce it using a recent FreeBSD version and see where that leads. http://www.freebsd.org/cgi/query-pr.cgi?pr=112722 From owner-freebsd-net@FreeBSD.ORG Fri Feb 6 23:00:19 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 37CE8106568A for ; Fri, 6 Feb 2009 23:00:19 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 0A3728FC0C for ; Fri, 6 Feb 2009 23:00:19 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n16N0HXZ072625 for ; Fri, 6 Feb 2009 23:00:17 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n16N0HiW072624; Fri, 6 Feb 2009 23:00:17 GMT (envelope-from gnats) Date: Fri, 6 Feb 2009 23:00:17 GMT Message-Id: <200902062300.n16N0HiW072624@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Kent Fox Cc: Subject: RE: kern/112722: [udp] IP v4 udp fragmented packet reject X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Kent Fox List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 23:00:21 -0000 The following reply was made to PR kern/112722; it has been noted by GNATS. From: Kent Fox To: "rwatson@FreeBSD.org" , "freebsd-net@FreeBSD.org" Cc: Subject: RE: kern/112722: [udp] IP v4 udp fragmented packet reject Date: Mon, 2 Feb 2009 08:21:56 -0700 Thanks for the thought but we went back to OpenBSD and fixed our performanc= e issue with some kernel parameters. I'm sorry that I cannot help out and d= uplicate the problem as I no longer have that environment. The main issue w= as the forced reassembly of fragmented packets. When the ingress packet siz= e was maxed out, the egress with the tunnel encapsulation was too large and= the packet was discarded. We tried a smaller MTU on the ingress but we sti= ll could never make it work. Doing an IPsec tunnel with RDP was a sure way = of killing the connection. So what you have is C------>FW------->S. From C(= lient) the S(erver) there is an IPSec tunnel (all the way) and from C to FW= (firewall FreeBSD server) is another IPSec tunnel (tunnel on the intranet (= now GRE)). Hope that helps. Kent -----Original Message----- From: rwatson@FreeBSD.org [mailto:rwatson@FreeBSD.org]=20 Sent: Monday, February 02, 2009 4:49 AM To: Kent Fox; rwatson@FreeBSD.org; freebsd-net@FreeBSD.org Subject: Re: kern/112722: [udp] IP v4 udp fragmented packet reject Synopsis: [udp] IP v4 udp fragmented packet reject State-Changed-From-To: open->feedback State-Changed-By: rwatson State-Changed-When: Mon Feb 2 11:31:13 UTC 2009 State-Changed-Why:=20 Dear Kent: I apologize for the delay in response to this problem report. Could I ask you to: (1) Confirm the problem still exists, especially if you've moved forward to a more recent rev of FreeBSD. (2) Let me know a bit more about your firewall/ipsec/etc setup. In particular, if you can easily identify a minimalist setup to reproduce this problem. Do the packets you're describing enter via a tunnel, or do they arrive unencapsulated? (3) Send me tcpdump output that shows the packet ingress and resulting ICMP. Thanks, Robert http://www.freebsd.org/cgi/query-pr.cgi?pr=3D112722