From owner-freebsd-hackers Thu Nov 14 23:56:29 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id XAA23987 for hackers-outgoing; Thu, 14 Nov 1996 23:56:29 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id XAA23951; Thu, 14 Nov 1996 23:56:20 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.2/8.7.3) id SAA06861; Fri, 15 Nov 1996 18:26:02 +1030 (CST) From: Michael Smith Message-Id: <199611150756.SAA06861@genesis.atrad.adelaide.edu.au> Subject: Re: userland PPP giving weird load numbers In-Reply-To: from Hellmuth Michaelis at "Nov 15, 96 07:31:50 am" To: hm@kts.org Date: Fri, 15 Nov 1996 18:26:01 +1030 (CST) Cc: kelly@fsl.noaa.gov, mark@quickweb.com, hackers@FreeBSD.org, current@FreeBSD.org X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Hellmuth Michaelis stands accused of saying: > > > > I see this too all the time, from 2.0.5 all the way to 2.1.5. While > > /usr/sbin/ppp is running, the load average hangs around 1.0. Sometimes, > > it'll drop. It's odd ... it's usually when ppp is idle that it hangs > > around 1.0. > > I had this phenomenon too - but NOT with ppp. An isdn userland daemon i am > working on showed this exact behaviour; when it was running, the system load > was constantly 1.0 or very nearby. This all is under 2.1.5 (and 2.1 too). > The process wasn't doing anything (or very little). But what _was_ it supposed to be doing? > My impression is that there is something wrong in the kernel, not in the > applications. I'd be inclined to say that there's something wrong in the applications, not in the kernel, actually. There's a chance that you have a driver problem (perhaps a broken select() handler), but the major causes of this sort of thing are applications failing to realise that a 0 return from a read() indicates EOF. Another possible is not checking all the bits enabled for a select(). Why not be a bit intelligent; attach a debugger to the offending process and wait for it to go gaga, then look at it to see what it's doing? > Hellmuth Michaelis -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[