Date: Tue, 20 Jan 2004 14:09:48 -0800 (PST) From: Nate Lawson <nate@root.org> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/alpha/alpha support.s src/sys/i386/i386 swtch.s src/sys/kern kern_shutdown.c src/sys/sys systm.h Message-ID: <20040120140012.N97860@root.org> In-Reply-To: <9202.1074631158@critter.freebsd.dk> References: <9202.1074631158@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 20 Jan 2004, Poul-Henning Kamp wrote: > In message <200401201445.24897.jhb@FreeBSD.org>, John Baldwin writes: > >On Tuesday 20 January 2004 01:23 pm, Poul-Henning Kamp wrote: > >> In message <200401201234.45472.jhb@FreeBSD.org>, John Baldwin writes: > >> >On Monday 19 January 2004 04:27 pm, Poul-Henning Kamp wrote: > >> >> Log: > >> >> Add linenumber and source filename to panic(9) output. > > This thread already represents a prime example of the worst of the > FreeBSD projects social dimension: The Gratuituos Bike Shed. > > On a generic kernel, this change adds 32088 non-executed bytes of > text-segment to i386/GENERIC. > > For reference this 0.5% of the kernel and 12% of the size of the > ACPI module. I'm not against this because of its size, I think it's the wrong way to go. > And yes, we can do much better, tracebacks would be a great start, > better panics also a great thing. We already have tracebacks if options DDB is enabled. (It probably should be for the GENERIC installed by sysinstall). > And no, this does not solve the mid-east crisis, but it is still > an improvement, even for me: If I save 1 minute because I do not > have to hunt for the panic in the first place, then that is one > minute more I can spend on the code. > > So if this makes your eyes water, I suggest you comment it out in > your local source tree and pop in on the next meeting in your > local user-group for some much needed perspective. The 10 seconds of grep time (guess I'm faster on this) is far outweighed by the one to INF email roundtrips necessary to get a user to enable options DDB, recompile, set up a serial console, etc. Most panics are page faults so you have to go to the traceback anyway as knowing the file/line of the page fault handler is not useful. I appreciate your desire to improve debugging and hope you'll be interested in tackling some of the outstanding issues (like the ones I listed). -Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040120140012.N97860>