Re: dhclient taking all cpu

From: Eric Anderson <anderson_at_centtech.com>
Date: Wed, 27 Jul 2005 08:37:32 -0500
Brooks Davis wrote:
> On Tue, Jul 26, 2005 at 06:53:17PM -0400, Jung-uk Kim wrote:
> 
>>On Tuesday 26 July 2005 04:00 pm, Wilko Bulte wrote:
>>
>>>On Tue, Jul 26, 2005 at 12:33:24PM -0700, Brooks Davis wrote..
>>>
>>>
>>>>On Mon, Jul 25, 2005 at 10:39:09PM -0400, Mike Jakubik wrote:
>>>>
>>>>>On Mon, July 25, 2005 9:54 pm, Brooks Davis said:
>>>>>
>>>>>>>>Probably something wrong with your interface, but you
>>>>>>>>havent't provided any useful information so who knows.  At
>>>>>>>>the very least, I need to know what interface you are
>>>>>>>>running on, something about it's status, and if both
>>>>>>>>dhclient processes are running.
>>>>>>>
>>>>>>>The interface is xl0 (3Com 3c905C-TX Fast Etherlink XL), and
>>>>>>>it worked in this machine fine for as long as i remember.
>>>>>>>This seems to have happened since a recent cvsup and
>>>>>>>buildworld from ~6-BETA to 7-CURRENT. I rebooted three
>>>>>>>times, and the problem occured rougly a minute after bootup.
>>>>>>>On the fourth time however, it seems to be ok so far.
>>>>>>
>>>>>>That sounds like a problem with the code that handles the
>>>>>>link state notifications in the interface driver.  The
>>>>>>notifications are a reletivly new feature that we're only now
>>>>>>starting to use heavily so there are going to be bumps in the
>>>>>>road.  It would be intresting to know if you see link state
>>>>>>messages promptly if you plug and unplug the network cable.
>>>>>
>>>>>It seems to be back at it again, this time it took longer to
>>>>>kick in. Here is a "ps auxw|grep dhclient" :
>>>>>
>>>>>_dhcp      219 93.5  0.2  1484  1136  ??  Rs    8:49PM  
>>>>>5:06.00 dhclient: xl0 (dhclient)
>>>>>root       193  0.0  0.2  1484  1088  d0- S     8:49PM  
>>>>>0:00.02 dhclient: xl0 [priv] (dhclient)
>>>>>
>>>>>top:
>>>>>
>>>>>  PID USERNAME      THR PRI NICE   SIZE    RES STATE    TIME  
>>>>>WCPU COMMAND 219 _dhcp           1 129    0  1484K  1136K RUN  
>>>>>   9:33 94.24% dhclient
>>>>>
>>>>>Nothing in dmesg about link state changes on xl0. Unplugging
>>>>>and replugging the network cable results in link state
>>>>>notification within a couple seconds.
>>>>
>>>>Could you see what happens if you run dhclient in the foreground?
>>>> Just running "dhclient -d xl0" should do it.  I'd like to know
>>>>what sort of output it's generating.
>>>
>>>In my case it is not displaying anything:
>>>
>>>
>>>chuck#dhclient -d ath0
>>>DHCPREQUEST on ath0 to 255.255.255.255 port 67
>>>DHCPACK from 192.168.5.254
>>>bound to 192.168.5.20 -- renewal in 21600 seconds.
>>>
>>><nothing>
>>>
>>>I can tell the phenomenon occurs when my laptop fan springs to
>>>life:
>>>
>>>CPU states: 96.5% user,  0.0% nice,  2.7% system,  0.8% interrupt, 
>>>0.0% idle
>>>Mem: 48M Active, 28M Inact, 50M Wired, 680K Cache, 34M Buf, 115M
>>>Free Swap: 257M Total, 257M Free
>>>
>>>  PID USERNAME  THR PRI NICE   SIZE    RES STATE    TIME   WCPU
>>>COMMAND 719 _dhcp       1 129    0  1384K  1092K RUN      2:14
>>>93.55% dhclient 607 root        1  98    0 34584K 21212K select  
>>>0:09  1.81% Xorg 663 wb          4  20    0 46712K 40224K kserel  
>>>0:27  0.00% mozilla-bin 503 root        1   8    0  1184K   796K
>>>nanslp   0:07  0.00% powerd
>>>
>>>Took (best guess) approx 5-10 minutes for the effect to kick in.
>>
>>FYI, I have the same issues with bge(4) and ndis(4).
> 
> 
> I've seen it on ath and em interfaces now, but am not sure what's going
> on. and have no idea how to reproduce the problem.  As also reported by
> Bakul Shah, we seem to be getting into a state where receive_packet() is
> spinning.  I'm not seeing an obvious way for this to be possible.

It's the latest change to tables.c that breaks it.  Reverting that 
single line back, fixes it.

Revision 1.2, Mon Jul 25 22:19:09 2005 UTC (39 hours, 18 minutes ago) by 
brooks
Branch: MAIN
CVS Tags: HEAD
Changes since 1.1: +2 -1 lines

Change host-name from type "X" to type "t".  This allows the client to
accept NUL-terminated strings as required by RFC 2132.

This solution is not perfect as it removes the ability to send
NUL-terminated host-name options which may be required by some broken
servers.  Given the current lack of an existance proof of such servers
and the fact that servers that send NUL-terminated domain names do
exist, this seems like an acceptable compromise.  A discussion of these
issues can be found at:

http://marc.theaimsgroup.com/?l=dhcp-client&m=96837107208382&w=2

PR:		bin/83468
Reported by:	Sean Winn <sean at gothic dot net dot au>
MFC-after:	3 days



-- 
------------------------------------------------------------------------
Eric Anderson        Sr. Systems Administrator        Centaur Technology
Anything that works is better than anything that doesn't.
------------------------------------------------------------------------
Received on Wed Jul 27 2005 - 11:37:43 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:39 UTC