From owner-freebsd-current Tue Jan 19 23:02:28 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA14485 for freebsd-current-outgoing; Tue, 19 Jan 1999 23:02:28 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA14480 for ; Tue, 19 Jan 1999 23:02:26 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.2/8.9.1) id XAA76802; Tue, 19 Jan 1999 23:00:55 -0800 (PST) (envelope-from dillon) Date: Tue, 19 Jan 1999 23:00:55 -0800 (PST) From: Matthew Dillon Message-Id: <199901200700.XAA76802@apollo.backplane.com> To: Andreas Klemm Cc: current@FreeBSD.ORG Subject: Re: panic: vinvalbuf: dirty bufs (during reboot, several times) References: <19990120073445.A402@titan.klemm.gtn.com> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Hi ! : :Since one or two weeks my system panics shortly before completely :going down. Services like squid and inn take a little longer than :usual to finish, I hear much disk activity. : :This happens usually if the system ran a day or so. : :What can I do to help ? Compile Kernel with debug infos ? : :BTW, yes I run an ELF kernel. Can't say exactly, if it's behaving :like this after completely migrating to ELF. : :innd: server SHUTDOWN received :boot() called on cpu#1 :syncing disks 8 7 1 done :panic: vinvalbuf: dirty bufs :mp_lock = 00000001, cpuid = 0 lapic.id = 01000000 :Debugger ("panic") : :trace: :Debugger :panic :vinvalbuf :... Hmm. Interesting, it's dying trying to fsync an FFS vnode. Are you by any chance running NFS ( client *or* server ) on this box? Bjoern had a comment relating to the same sort of problem, which I include below: ::But there's still something wrong: When shutting down the server ::it still sometimes panics in vinvalbuf() complaining 'bout dirty ::pages. On the client side vi dies of SEGV (edited file and ::/var/tmp/vi.recover on nfs fs) generating a wrong sized recover ::file. After that the server panics on shutdown. Without triggering ::the bug it shuts down gracefully. :: ::I'll try to receipe a situation for easily reproducing this. :: :: Bjoern We have a couple of possibilities. First, if either of you are compiling up your own kernels, please remember that if you are using SOFTUPDATES, the SOFTUPDATES code does *NOT* reside in /usr/src/sys but instead resides in /usr/src/contrib/sys ... when you update your kernel, also make sure that /usr/src/contrib/sys is updated. With that out of the way, if the vinvalbuf() problem still occurs our best bet is if Bjoern can give us a repeatable vi SEGV / shutdown sequence that results in the panic. If I can reproduce it on one of my machines, I can probably figure out what is going on. If both of you are running NFS, it could possibly be the NFS server forgetting to unbusy a page somewhere. If you aren't running NFS, it could be an actual bug in FFS somewhere(!). -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message