Re: kldunload DIAGNOSTIC idea...
From: Brian Fundakowski Feldman (green_at_freebsd.org)
Date: 07/20/04
- Previous message: Poul-Henning Kamp: "Re: kldunload DIAGNOSTIC idea..."
- In reply to: Poul-Henning Kamp: "Re: kldunload DIAGNOSTIC idea..."
- Next in thread: Willem Jan Withagen: "Re: kldunload DIAGNOSTIC idea..."
- Reply: Willem Jan Withagen: "Re: kldunload DIAGNOSTIC idea..."
- Reply: Scott Long: "Re: kldunload DIAGNOSTIC idea..."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Tue, 20 Jul 2004 14:52:36 -0400 To: Poul-Henning Kamp <phk@phk.freebsd.dk>
On Tue, Jul 20, 2004 at 08:39:57PM +0200, Poul-Henning Kamp wrote:
> In message <20040720183213.GC1009@green.homeunix.org>, Brian Fundakowski Feldma
> n writes:
> >On Tue, Jul 20, 2004 at 08:20:23PM +0200, Poul-Henning Kamp wrote:
> >>
> >> I'm pulling hair out trying to make it guaranteed safe to unload device
> >> driver modules, and the major pain here is to make sure there is no
> >> thread stuck somewhere inside the code.
> >>
> >> That gave me the idea for a simple little DIAGNOSTIC check for kldunload:
> >> run through the proc/thread table and look for any thread with an
> >> instruction counter inside the range of pages we are going to unload.
> >>
> >> Any takers ?
> >
> >You mean any thread with a stack trace that includes an instruction
> >counter inside those pages, don't you?
>
> That would require us to unwind the stack which I think is overkill
> for the purpose.
>
> The most likely case is that the thread is sleeping on something
> inside the kld so just checking the instruction pointer would be
> fine.
>
> Looking for sleep addresses inside the module might make sense too.
It's probably not overkill -- at least in my experience most of the
time a driver is "doing something" it is sleeping, so the address
will be in mi_switch() or somewhere way out there. Sleep addresses
on dynamic data addresses are also a lot more common than sleep
addresses on static/code addresses. If someone is interested in
doign this, it would be very informative, especially if it could
catch sleeps, pending timeouts, pending callouts, etc.
-- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\ _______________________________________________ freebsd-arch@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-arch To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
- Previous message: Poul-Henning Kamp: "Re: kldunload DIAGNOSTIC idea..."
- In reply to: Poul-Henning Kamp: "Re: kldunload DIAGNOSTIC idea..."
- Next in thread: Willem Jan Withagen: "Re: kldunload DIAGNOSTIC idea..."
- Reply: Willem Jan Withagen: "Re: kldunload DIAGNOSTIC idea..."
- Reply: Scott Long: "Re: kldunload DIAGNOSTIC idea..."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
- Re: kldunload DIAGNOSTIC idea...
... >>You mean any thread with a stack trace that includes an instruction
... fails to allocate memory, the best course of action we have right ... worthwhile
to see if some of those panics could be converted into ... (freebsd-arch) - Re: AS performance with reiser4 on 2.6.3
... fsync indeed accounts for a significant fraction of the time. ... Each stack
trace is preceded by three ... of sleep for this path, ... send the line "unsubscribe
linux-kernel" in ... (Linux-Kernel) - Re: PIC12C508A : WDT Reset during sleep problem
... The PCM16XA0 has a limitation with emulation of wake up from sleep on ... The
12C508 always does a reset when it wakes up from sleep. ... > There is no option for
continuing execution with the instruction after ... (comp.arch.embedded) - Be Gentle With the Moment
... Give it freedom and instruction ... Consider as you sleep - how
you were awake through it ... (rec.arts.poems) - Re: Be Gentle With the Moment
... Give it freedom and instruction ... Consider as you sleep - how you were
awake through it ... Consider as you're awake how you slept through it ...
(rec.arts.poems)