public inbox for linux-acpi@vger.kernel.org
 help / color / mirror / Atom feed
From: bperkins-ooduxAEi7gVg9hUCZPvPmw@public.gmane.org
To: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: Question about space handling
Date: Wed, 02 Apr 2003 22:58:23 -0500	[thread overview]
Message-ID: <200304030358.h333wNj02932@throb.netspace.org> (raw)
In-Reply-To: Your message of "Wed, 02 Apr 2003 21:39:56 EST." <20030403023956.GA4679-r3+FECOBLOPAaqN1iTbosg@public.gmane.org>

Lu Tong <ltong-r3+FECOBLOPAaqN1iTbosg@public.gmane.org> writes:



> c01b75b0(ec_space_handler). that is WRONG! it seems that the
> addrhandler e7df4da8 was released back to the obj cache even though
> it was being used. the same handler was then reused as the
> addrhandler for EC.

OK now I see.  

In that case I've been on the wrong track for the last few hours, and
explains a lot to me. I had assumed those handlers were AML code, and
wanted to know what was getting called.  Unfortunately for me, the
debug info seems to have meant exactly what it said. :)

I understand your theory on what's happening, but wouldn't we have the
same problem if acpi_ec_add is being mistakenly called on
address_space_handler?  Or some other reason the same structure is being
assigned for both handlers (like a forgotten increment)?

I guess the place to start is to see where/when the "makeshift" ec
handler is being installed, where/when the SystemMemory handler is
being installed.  If they are being installed on top of each other,
then it must be some kind of race condition or incrementation problem.

Or am I totally insane?



--
Pack my box with five dozen liquor jugs.
Brian Perkins                                bperkins-ooduxAEi7gVg9hUCZPvPmw@public.gmane.org


-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb: 
Dedicated Hosting for just $79/mo with 500 GB of bandwidth! 
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/

  parent reply	other threads:[~2003-04-03  3:58 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-04-02 23:14 Question about space handling bperkins-ooduxAEi7gVg9hUCZPvPmw
     [not found] ` <200304022314.h32NEWi28650-7GtV0IYKK74tA4QZiFxQkx2eb7JE58TQ@public.gmane.org>
2003-04-03  2:39   ` Lu Tong
     [not found]     ` <20030403023956.GA4679-r3+FECOBLOPAaqN1iTbosg@public.gmane.org>
2003-04-03  3:58       ` bperkins-ooduxAEi7gVg9hUCZPvPmw [this message]
     [not found]         ` <200304030358.h333wNj02932-7GtV0IYKK74tA4QZiFxQkx2eb7JE58TQ@public.gmane.org>
2003-04-03 18:05           ` Lu Tong

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200304030358.h333wNj02932@throb.netspace.org \
    --to=bperkins-ooduxaei7gvg9huczpvpmw@public.gmane.org \
    --cc=acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox