Date: Sat, 23 Nov 2002 14:57:56 +0200 From: Vallo Kallaste <kalts@estpak.ee> To: Terry Lambert <tlambert2@mindspring.com> Cc: kalts@estpak.ee, John Baldwin <jhb@FreeBSD.org>, current@FreeBSD.org, Scott Sipe <cscotts@mindspring.com> Subject: Re: DP2 Fatal Trap Message-ID: <20021123125756.GA1676@tiiu.internal> In-Reply-To: <3DDF5D7C.AF8E8E76@mindspring.com> References: <3DDD7C44.84C0D242@mindspring.com> <XFMail.20021122105742.jhb@FreeBSD.org> <20021122162443.GA3154@tiiu.internal> <3DDEBCDB.4A363410@mindspring.com> <20021123104524.GA1264@tiiu.internal> <3DDF5D7C.AF8E8E76@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Nov 23, 2002 at 02:50:36AM -0800, Terry Lambert <tlambert2@mindspring.com> wrote: > > Either CPU hardware or software bug, fine. You're claiming to know > > the bug and possible fix, but don't want to publish it, fine. > > I do not object to publication of code that embodies a workaroun > to the poblem, so long as that workaround doesn;t specifically > disclose the root cause problem itself. Yes I know it from your previous posts. For some reason you don't want that description and analysis of (possible) hardware bug comes public (at this time). Whatever your reasons are, you certainly have your rights for it, no problem from my viewpoint. > > I don't want to think about it because with my knowledge this is going > > to nowhere and only wasting my time. Things you see above are my > > results using consistent testing environment, take it or leave it. > > I'll stick with DISABLE_PSE enabled and DISABLE_PG_G disabled for > > the time being. > > I'll make the same offer of a fixed kernel binary, for testing > purposes, if you are willing to test two: one to be sure that > there is no serendipity involved, and one with the patch. We > can skip the first one if you can give me a CVS date or tag to > checkout to get code identical to code you have locally, which > has the problem. E.g. if you have a local copy of the CVS tree, > and you check out with a date tag of, say, last Wednesday, and > the kernel you build from that coe ha he problem, then I can check > out identical code, patch it, and give you a binary to try. I'll take this route, at least it can prove something objective (for me). Of course I have to trust you to not send me kernel binary with simply those damned options enabled... or with "something interesting" in it... The sources the kernel is built are checked out from freebsd.dk.freebsd.org at: *default date=2002.11.21.13.56.00 -- Vallo Kallaste kalts@estpak.ee To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021123125756.GA1676>