From owner-freebsd-bugs Fri Jan 11 2:41: 1 2002 Delivered-To: freebsd-bugs@freebsd.org Received: from mail.freebsd-corp-net-guide.com (mail.freebsd-corp-net-guide.com [206.29.169.15]) by hub.freebsd.org (Postfix) with ESMTP id 2B1DC37B402 for ; Fri, 11 Jan 2002 02:40:56 -0800 (PST) Received: from tedm.placo.com (nat-rtr.freebsd-corp-net-guide.com [206.29.168.154]) by mail.freebsd-corp-net-guide.com (8.11.1/8.11.1) with SMTP id g0BAekR62870; Fri, 11 Jan 2002 02:40:46 -0800 (PST) (envelope-from tedm@toybox.placo.com) From: "Ted Mittelstaedt" To: "Bill Fumerola" , "Karsten Thygesen" Cc: Subject: RE: kern/33637: Panic: vm_page_unwire: invalid wire count: 0 Date: Fri, 11 Jan 2002 02:40:45 -0800 Message-ID: <001001c19a8c$6c93a980$1401a8c0@tedm.placo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <20020111010233.A402@elvis.mu.org> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Importance: Normal Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >-----Original Message----- >From: Bill Fumerola [mailto:billf@mu.org] >Sent: Friday, January 11, 2002 1:03 AM >To: Ted Mittelstaedt; Karsten Thygesen >Cc: freebsd-bugs@FreeBSD.ORG >Subject: Re: kern/33637: Panic: vm_page_unwire: invalid wire count: 0 > > >it is a bug that a userland program can cause the kernel to crash with >a vm panic. panics are the safety belts of the kernel and triggering one >of them means that you've found a case that the programmer(s) know >shouldn't happen. > This is a vast simplification of the issue. To illustrate I'll refer to 3 other PR's of the same error, all closed: kern/1018 - VM kernel bug triggered by heavy load by an application program kern/5839 - ditto kern/6089 - triggered by hardware and this was just that vm_page_unwire thing. Now, the first 2 were purely kernel bugs but what about the last one? OK, it's not a userland program, I'll grant you that, but it's also not a kernel bug like your claiming. Without further investigation of Karsten's system there is no way to tell what is going on. Your going out on just as fragile a limb as I am when you assume it's a kernel bug. >a panic means the situation has been considered before and it is something >that is known to cause problems. There are many examples of panics that happen on specific systems and that FreeBSD developers have stated are caused by flaky hardware. Read the newsgroups and mailing list archives. >finding real life cases of the panic >with reproducable scenarios is _HELPFUL_ to the programmer(s) in finding >bugs in the subsystem. > You will get no argument from me on this. I will submit that if this was easily reproducable then it's likely the Diablo people would know about it already as they would have reproduced it. What if we are both right and what is really happening is that there's a bug in the virtual memory system somewhere, and the reason that Karsten's system is crashing is because there's also something in Diablo that is passing unexpected or unchecked data to a library call? Well, if we do it your way and fix the VM bug then the bug still exists in Diablo. Sure, the FreeBSD system stops panicing - but all that happens is that Diablo starts crashing every 4 days instead of the operating system. If we do it my way and fix or write around the problem in Diablo then guess what - now Karsten's news server stops crashing altogether and goes back to being as reliable as it was under INN. Problem solved for him. Who cares if the library still has a bug in it - all the user cares about is that the application runs. Of course that sort of talk just pisses off some people no end because this is how Microsoft does things, (ie: bandaid the application program until the OS stops crashing) so I'm sure I'll be shot on sight for saying it. >please stop spreading FUD to users who are trying to report an actual >bug He is reporting a problem, it is yet to be determined if it is a bug. >and are providing meaningful data. he did not as the kernel troubleshooting manual that sheldon referred him to clearly shows. >your emails on this PR are not >only unhelpful, they're detrimental to getting the real problem fixed. > You view the real problem as a potential VM bug in FreeBSD. I view the real problem as "Karsten's crashing newsserver" And yes, I'll agree that solving the problem that I define could be detrimental and unhelpful - but not to the user, to FreeBSD. Sorry, but given a choice between using FreeBSD to help a user or using a user to help FreeBSD I'll choose the former. > >ps. don't even think of sending me some stupid flame, either. this is > for the encouragement of the original submitter. > Bill your posts are always fun to read but your a crabby bugger, and I'd have been disappointed if you hadn't flung that last little bit out. Hopefully someone who has more interest in fixing the problem and less in flaming will fix it, then we can see who was right and one of us will have the fun of saying "I told you so asshole" But more seriously, which is more important to you - the philosophy or fixing kern/33637? I'll point out that your entire post didn't mention his problem once in any specific way. Compare that to my posts and tell me - who of us is more interested in his problem? Ted Mittelstaedt tedm@toybox.placo.com Author of: The FreeBSD Corporate Networker's Guide Book website: http://www.freebsd-corp-net-guide.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message