From owner-freebsd-stable@FreeBSD.ORG Sat May 6 18:55:46 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 989F416A40E for ; Sat, 6 May 2006 18:55:46 +0000 (UTC) (envelope-from lvoege@gmail.com) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.198]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3606743D58 for ; Sat, 6 May 2006 18:55:38 +0000 (GMT) (envelope-from lvoege@gmail.com) Received: by nz-out-0102.google.com with SMTP id l1so883650nzf for ; Sat, 06 May 2006 11:55:36 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:mime-version:content-transfer-encoding:message-id:content-type:to:from:subject:date:x-mailer; b=k1j13ByHKaMRBaC1Ky8WOxLCJvMVIvzNizZDAS5NTj1FQFJcUJuZxH4HT53kb7r9TfIwrAE3343iSghy6RqTQyMJwxz4o9ForGm6AOgwggrLk7yOM+B4ggmVJevho24f/lo0y4ZRCOiW8adF7BHrxKK2cksJnFLAcW1dWnxHuBc= Received: by 10.64.88.11 with SMTP id l11mr275318qbb; Sat, 06 May 2006 11:55:36 -0700 (PDT) Received: from ?192.168.123.9? ( [66.31.41.7]) by mx.gmail.com with ESMTP id f12sm632278qba.2006.05.06.11.55.34; Sat, 06 May 2006 11:55:35 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v749.3) Content-Transfer-Encoding: quoted-printable Message-Id: <82912730-AD0E-4AE0-AA7C-FDD321F00B57@gmail.com> Content-Type: text/plain; charset=UTF-8; delsp=yes; format=flowed To: freebsd-stable@freebsd.org From: =?ISO-8859-1?Q?Lodewijk_V=F6ge?= Date: Sat, 6 May 2006 14:55:30 -0400 X-Mailer: Apple Mail (2.749.3) Subject: dhclient taking up all CPU X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 May 2006 18:55:49 -0000 hello, a while ago someone reported the same problem I had been seeing, that =20= dhclient starts taking up 100% CPU. it's probably something comcast =20 is doing. I couldn't get the requested coredump then, if I set kern.corefile =20 to /tmp/%N.core and kill -QUIT it, it doesn't seem to produce a =20 coredump. but it happened again just now, and I was able to attach =20 gdb. this is where it's spinning, in receive_packet() in bpf.c: (gdb) 285 if (interface->rbuf_offset =3D=3D interface-=20 >rbuf_len) { (gdb) 299 if (interface->rbuf_len - interface-=20 >rbuf_offset < (gdb) 306 memcpy(&hdr, &interface->rbuf[interface-=20 >rbuf_offset], (gdb) 313 if (interface->rbuf_offset + hdr.bh_hdrlen + =20 hdr.bh_caplen > (gdb) 320 interface->rbuf_offset +=3D hdr.bh_hdrlen; (gdb) 327 if (hdr.bh_caplen !=3D hdr.bh_datalen) { (gdb) 328 interface->rbuf_offset =3D (gdb) 331 continue; (gdb) 385 } while (!length); and then it goes back to line 285. interesting variables are: (gdb) p *interface $1 =3D {next =3D 0x0, hw_address =3D {htype =3D 1 '\001', hlen =3D 6 = '\006', haddr =3D "\000\021=D8=A0\223?\000\000\000\000\000\000\000\000\000"},= =20 primary_address =3D {s_addr =3D 0}, name =3D "vr0", '\0' , rfdesc =3D 7, wfdesc =3D 7, =20= rbuf =3D 0x807d000 "\022?\\Dk\214", rbuf_max =3D 4096, rbuf_offset =3D 416, rbuf_len =3D 415, ifp =3D 0x806f160, client =3D =20= 0x8075000, noifmedia =3D 0, errors =3D 0, dead =3D 0, index =3D 2} (gdb) p length $2 =3D 0 (gdb) p hdr $3 =3D {bh_tstamp =3D {tv_sec =3D 0, tv_usec =3D 0}, bh_caplen =3D = 4294901760, =20 bh_datalen =3D 4294901778, bh_hdrlen =3D 65535} this is FreeBSD/i386 6.1-RC as of about two weeks ago. Lodewijk