From owner-freebsd-hackers Tue Sep 10 9:27:14 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8417F37B400; Tue, 10 Sep 2002 09:27:06 -0700 (PDT) Received: from Millions.Ca (h24-79-52-254.sbm.shawcable.net [24.79.52.254]) by mx1.FreeBSD.org (Postfix) with ESMTP id 93A7543E42; Tue, 10 Sep 2002 09:27:05 -0700 (PDT) (envelope-from stacy@Millions.Ca) Received: (from uucp@localhost) by Millions.Ca (8.11.1/8.9.3) id g8AGR4I69165; Tue, 10 Sep 2002 10:27:04 -0600 (MDT) (envelope-from stacy@Millions.Ca) Received: from Cedar.Millions.Ca(192.168.64.8) via SMTP by mail-gw-0.millions.ca, id smtpdA69163; Tue Sep 10 10:26:56 2002 Received: from millions.ca (Bonsai.Millions.Ca [192.168.64.4]) by cedar.millions.ca (8.12.2/8.12.3) with ESMTP id g8AGQucM097678; Tue, 10 Sep 2002 10:26:56 -0600 (MDT) (envelope-from stacy@millions.ca) Message-ID: <3D7E1D50.6030807@millions.ca> Date: Tue, 10 Sep 2002 10:26:56 -0600 From: Stacy Millions Organization: Millions Consulting Limited User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0.0) Gecko/20020612 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Greg 'groggy' Lehey" , hackers@FreeBSD.org Subject: Re: I climb the mountain seeking wisdom References: <3D78F291.8010005@millions.ca> <20020908064449.GG46846@wantadilla.lemis.com> <3D7D212E.6030601@millions.ca> <20020910021732.GB20691@wantadilla.lemis.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Greg 'groggy' Lehey wrote: > There will always be situations where the debugger can't catch the > problem in time. Then it's up to you to guess and put a breakpoint > just before it freezes; this can be an interative process. The method > requiring the least thought is to single step over function calls > until the system freezes. Then you know which function it happened > in. Reboot, set a breakpoint in that function, and repeat. What is being a real bear on this one, is the fact that it is not my code that is generating the panic. I assume I'm doing something bad that some other part of the kernel finds objectionable. Makes it hard to know where to set the break point... >>>Debugging hasn't changed much since 4.3BSD. >> >>True enough, but *what* I am debugging sure has changed. KLD for >>example did not exist the last time I did kernel programming. > > > Debugging klds is a little more difficult. You need to use gdb's > add-symbol-file command to get the symbols. There are some functions > which help, but the good one hasn't been committed yet. Take a look > at http://people.freebsd.org/~gallatin/gdbmods. I had found a refrence to the add-symbol-file, but had not tried it, mostly because I can't get a core file... guess I will have to look into the remote debugger. >>Now I want to do a kldunload and have the driver dettach, >>the MOD_UNLOAD is called, but the detach() is never called. What >>do I need to do to get the detach() to be called? Is there an >>opposite to BUS_ADD_CHILD()? I tried device_delete_child()... gave >>me a panic and no core and devclass_delete_driver()... returned >>an error (ENOENT, I think) > > > Hmm, haven't had that particular problem, but my klds don't handle > hardware. Have you looked at similar code in other drivers? Well, it turned out that this was a problem caused by the same root problem that was causing my panics in strange places. Once I tracked down my rogue pointer, things became much better behaved. OK, I admit it, I have been programming in Java for the last two years and it is taking my brain a while to adjust to pointers again :-) Moral of the story, don't stomp your device_t, not that I was doing it intentionaly... Now, for a more "meaning of life, the universe and device drivers" type set of question: For a static driver, we have the config flags that can be used to modify the drivers behaviour, is sysctl the equivalent for KLD modules? If so, should a person support both or are the config flags considered depricated? Is there any naming convention for the MIB or is _driver_._option_ acceptable? -stacy -- If they keep lowering education standards and raising the price of gasoline, there are going to be a lot of stupid people walking around. Stacy Millions stacy@millions.ca Millions Consulting Limited To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message