From owner-freebsd-current@FreeBSD.ORG Sat Jul 10 20:34:24 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C896116A4CE; Sat, 10 Jul 2004 20:34:24 +0000 (GMT) Received: from pengo.systems.pipex.net (pengo.systems.pipex.net [62.241.160.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id B98B743D1F; Sat, 10 Jul 2004 20:34:23 +0000 (GMT) (envelope-from mark.cullen@dsl.pipex.com) Received: from laptop (81-178-100-243.dsl.pipex.com [81.178.100.243]) by pengo.systems.pipex.net (Postfix) with SMTP id 52B974C0009D; Sat, 10 Jul 2004 21:34:21 +0100 (BST) Message-ID: <005101c466bd$454972b0$f800000a@laptop> From: "Markie" To: "Brian Fundakowski Feldman" , References: <000b01c46617$1f3ba4e0$f800000a@laptop><20040710143658.GH1626@green.homeunix.org><001201c4669d$bfa13bd0$f800000a@laptop> <20040710192842.GK1626@green.homeunix.org> Date: Sat, 10 Jul 2004 21:34:15 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: Re: quick interactivity? question regarding -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jul 2004 20:34:25 -0000 ----- Original Message ----- From: "Brian Fundakowski Feldman" To: "Markie" Cc: Sent: Saturday, July 10, 2004 8:28 PM Subject: Re: quick interactivity? question regarding -current | On Sat, Jul 10, 2004 at 05:48:35PM +0100, Markie wrote: | > ----- Original Message ----- | > From: "Brian Fundakowski Feldman" | > To: "Markie" | > Cc: | > Sent: Saturday, July 10, 2004 3:36 PM | > Subject: Re: quick interactivity? question regarding -current | > | > | > | On Sat, Jul 10, 2004 at 01:44:51AM +0100, Markie wrote: | > | > Hello, | > | > | > | > I updated my 'do-it-all' home server box from 5.2.1-R to -CURRENT the | > other | > | > day, as suggested by someone a month ago because I was having panics | > along | > | > the lines of "kmem_malloc(4096): kmem_map too small". Now, I can't | > | > immediately tell if this upgrade has solved my problem as the first one | > | > appeared after 50 days of uptime (ish) and the one that happened the | > other | > | > day (same panic) occured after only around 20 days, this is when I | > decided | > | > to go for the installkernel/world. | > | | > | Did you try seeing where all the memory went? I reimplemented KVM | > support | > | in vmstat -m for -CURRENT, so it should be more useful for that if you | > get | > | a core dump (admittedly, a rare thing ...). | > | > I didn't know about vmstat -m until the other day, I read something about | > `vmstat -m | grep cred` should be really low, under 100k or something | > (which mine is) | > | > I have no idea what KVM is in terms of kernel stuff :-) What should I be | > looking for, just any entry with a high mem usage? Should I setup a cron | > job to dump the results to a file each day so incase I do still get the | > panic i'll be able to look at the results atleast from the day before, | > maybe that would help me determine what was up if it's due to a memory | > leak? At the moment the most memory seems to be in 'routetbl' - 6456k in | > the HighUse and 1793k MemUse. All the rest are pretty much below 100k. | | That's an excellent plan. I would suggest doing it more like hourly, and :-D I'll go set that up for hourly then, just incase it does still panic with CURRENT. | logging to separate files each time -- the individual file unit is not the | most resilient to a kernel panic, but a directory of separate files will | probably stand no chance of being wiped out. If you used one file, it | could be truncated, put in lost+found, or maybe just lost, although I | haven't specifically had any files that were not "recently created" lost | during crashes. Well, my plan was to do it so it'd save the output to, say, vmstat.10.07.04. So it'd be a seperate file for each day, but hourly probably is alot better anyway! Also I did find that when I first started messing about with -CURRENT (not long before 5.1 I think) when I crashed due to the (nasty) nvidia module I ended up with alot of data loss until I turned off write caching. I read that some hard disks lie about when the data is written out and this isn't a softupdate issue, is this right? | | If you're doing it live, please do vmstat -z also (vmstat -mz works); it | should be easy to see where the problem is using both of those over time, | but only if it's a gradual leak (which most I've seen are). How do you mean 'live'? I will use -mz anyway, just wondering what you meant :-) Oh and say it does panic again, should I send the list all of these logs from say the past... say... week in a tar or what? I could also compile a debug kernel and start using that if it still does it, if it'd help any? | | Thanks! Thank _you_ :-) | | -- | Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ | <> green@FreeBSD.org \ The Power to Serve! \ | Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\ | _______________________________________________ | freebsd-current@freebsd.org mailing list | http://lists.freebsd.org/mailman/listinfo/freebsd-current | To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"