Date: Tue, 10 Sep 2002 10:26:56 -0600 From: Stacy Millions <stacy@millions.ca> To: "Greg 'groggy' Lehey" <grog@FreeBSD.org>, hackers@FreeBSD.org Subject: Re: I climb the mountain seeking wisdom Message-ID: <3D7E1D50.6030807@millions.ca> References: <XFMail.20020906135858.jhb@FreeBSD.org> <3D78F291.8010005@millions.ca> <20020908064449.GG46846@wantadilla.lemis.com> <3D7D212E.6030601@millions.ca> <20020910021732.GB20691@wantadilla.lemis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3D7E1D50.6030807>