Date: Wed, 27 Jul 2005 15:54:58 -0400 From: Jung-uk Kim <jkim@niksun.com> To: Brooks Davis <brooks@one-eyed-alien.net> Cc: Wilko Bulte <wb@freebie.xs4all.nl>, freebsd-current@FreeBSD.org, Mike Jakubik <mikej@rogers.com> Subject: Re: dhclient taking all cpu Message-ID: <200507271555.00945.jkim@niksun.com> In-Reply-To: <20050727191043.GA17885@odin.ac.hmc.edu> References: <42E58007.9030202@rogers.com> <20050726233933.GA13679@odin.ac.hmc.edu> <20050727191043.GA17885@odin.ac.hmc.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday 27 July 2005 03:10 pm, Brooks Davis wrote: > I think I've found it. There was a really odd typo (= instead of > +) in the code that handles undersized captures on the bpf socket. > Please try the following patch and see if it solves the problem. > I'm testing here, but I don't have a reliable way to trigger the > bug. The fix is fairly obvious so I'll commit it to head shortly. Good catch! It seems to fix my 'infinite loop' problem. One more problem to solve... I have to do the following to make bge(4) working correctly at boot time: ifconfig_bge0="up DHCP" Without `up', dhclient fails like this: bge0: link state changed to DOWN bge0: no link .............. giving up bge0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> mtu 1500 options=1a<TXCSUM,VLAN_MTU,VLAN_HWTAGGING> ether xx:xx:xx:xx:xx:xx media: Ethernet autoselect (none) status: no carrier because bge(4) does not change link state while the interface is down. This problem is more serious with wireless driver because link doesn't go up until it is associated with some AP. I was always wondering which is correct. Do we have to update link state while interface is down or not? Thanks! Jung-uk Kim
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200507271555.00945.jkim>