From owner-freebsd-alpha Wed Oct 14 19:00:26 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA10565 for freebsd-alpha-outgoing; Wed, 14 Oct 1998 19:00:26 -0700 (PDT) (envelope-from owner-freebsd-alpha@FreeBSD.ORG) Received: from mail.netbsd.org (homeworld.cygnus.com [205.180.83.70]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id TAA10540 for ; Wed, 14 Oct 1998 19:00:16 -0700 (PDT) (envelope-from cgd@netbsd.org) Received: (qmail 26925 invoked by uid 1000); 15 Oct 1998 01:59:18 -0000 To: dg@root.com Cc: Jason Thorpe , Andrew Gallatin , Chris Csanady , freebsd-alpha@FreeBSD.ORG Subject: Re: kernel traps on boot.. References: <199810150054.RAA05491@implode.root.com> From: cgd@netbsd.org (Chris G. Demetriou) Date: 14 Oct 1998 18:59:18 -0700 In-Reply-To: David Greenman's message of Wed, 14 Oct 1998 17:54:45 -0700 Message-ID: <8767dmoaa1.fsf@netbsd1.cygnus.com> Lines: 34 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org David Greenman writes: > >Just doing printfs for broken kernel code only encourages laziness. > > Well, that might be fine for a developer, but it sure doesn't help end > users. We *are* trying to provide a production system after all. :-) If code is sufficiently untested that it randomly runs into unaligned accesses, then by definition, it isn't a production-quality system and you don't need to worry about panic()ing. However, if it _is_ well tested, "production quality," and still runs into that unaligned access, then that unaligned access is probably indicative of a somewhat-serious bug. It means either that code is getting a bogus value because of specification/implementation "issue," or that something, somewhere got corrupted, and therefore the system lost. To have such bugs fixed properly, in many cases, a developer will need to know more about the context in which it occurred than just the fact that it occurred, the PC, and a few registers. That means panic, followed by kernel core dump (or invocation of kernel debugger, or whatever), which then gets handed by the user of the production system to a developer, who debugs it. In my opinion, it's not only bad, but _irresponsible_ to let the system bumble on in the face of such a bug. High uptime is nice, but if it comes at the cost of ignoring serious system errors or corrupting data, it's worthless. cgd -- Chris Demetriou - cgd@netbsd.org - http://www.netbsd.org/People/Pages/cgd.html Disclaimer: Not speaking for NetBSD, just expressing my own opinion. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message