Date: Mon, 03 Oct 2005 13:31:27 -0700 From: Nate Lawson <nate@root.org> To: Robert Watson <rwatson@FreeBSD.org> Cc: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org, Poul-Henning Kamp <phk@phk.freebsd.dk>, Mark Linimon <linimon@lonesome.com>, Olivier Houchard <cognet@FreeBSD.org> Subject: Re: cvs commit: src/sys/ddb db_command.c db_output.c Message-ID: <4341951F.90006@root.org> In-Reply-To: <20051003183854.Q92333@fledge.watson.org> References: <43416038.6020701@root.org> <93558.1128359003@critter.freebsd.dk> <20051003171854.GA18710@soaustin.net> <20051003183854.Q92333@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Robert Watson wrote: > > On Mon, 3 Oct 2005, Mark Linimon wrote: > >> On Mon, Oct 03, 2005 at 07:03:23PM +0200, Poul-Henning Kamp wrote: >> >>> There are pro etc con for both methods. Once a dump has been sitting >>> in a PR for a year, very few people tend to have compatible info >>> tools available. >> >> The counterpoint would be that after a dump has been sitting in a PR >> for a year, the source base will often have drifted so much that any >> prior investigative work needs to be re-run. >> >> I'm hardly arguing against either solution here -- anything that we >> can do to cut out one email round-trip on e.g. the i386/kern PRs can >> only help us. > > After the PR has been sitting there for a year or two, trying to decide > if it's the same bug can be quite difficult if the submitter didn't know > which of a dozen DDB commands to type, or know how to try to extract > kernel debug information using gdb. I'm not saying this is a substitute > for a full dump, but that in many situations, I would get more rather > than less information as a result of what we're talking about. You get the best of both worlds if you have sparse dumps and an addition to rc.d/savecore that does an info dump from the core to a text file. I agree that the text stuff is the most useful for (auto) PR submission. I'd just rather go the path of saving full info and then generating an extract than skipping the intermediate step and generating the abstract directly. That way you always have the option of going back and getting more info. Sparse dumps mean that it's quick when the panic happens and that you can keep more around. With multi-gigabyte RAM being common now but common drive speed being stuck at 7200 RPM, we're losing every day that we don't have sparse dumps. -- Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4341951F.90006>