From owner-freebsd-hackers Tue Apr 23 17:03:22 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id RAA20940 for hackers-outgoing; Tue, 23 Apr 1996 17:03:22 -0700 (PDT) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id RAA20924 Tue, 23 Apr 1996 17:03:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.7.5/8.6.9) with SMTP id RAA06541; Tue, 23 Apr 1996 17:02:34 -0700 (PDT) To: "Marc G. Fournier" cc: current@freebsd.org, hackers@freebsd.org Subject: Re: Intelligent Debugging Tools... In-reply-to: Your message of "Tue, 23 Apr 1996 16:02:04 EDT." Date: Tue, 23 Apr 1996 17:02:34 -0700 Message-ID: <6539.830304154@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > What would it take to either create software for debugging > hardware, and/or add appropriate debugging to the kernel that would > improve debugging of hardware problems? A lot. The best you can hope for right now is "CheckIt" from TouchStone software, it runs under DOS and no I haven't even the faintest idea whether or not it will detect your particular problem. Probably not, but it's the best attempt at a software hardware checker that I know of. > As far as the kernel is concerned, I'm getting panics in VM > and keep getting told its hardware problems...fine, but there *has* > to be a better way of isolating the problem then replacing bits and > pieces until the problem seems to go away. For instance, when I get Not really. This is, in fact, how the "big boys" do it. If you're in doubt, swap it out. One component at a time, if necessary, until you find the bad one. I would first target my cache, memory and motherboard, in that order, for replacement if I were in your shoes (and I have been - this is how I fixed it :-). Jordan