Re: kldunload DIAGNOSTIC idea...

From: Brian Fundakowski Feldman (green_at_freebsd.org)
Date: 07/20/04

  • Next message: Willem Jan Withagen: "Re: kldunload DIAGNOSTIC idea..." 
    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"
  • Next message: Willem Jan Withagen: "Re: kldunload DIAGNOSTIC idea..."

    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)