Question about space handling

Question about space handling

[bperkins-ooduxAEi7gVg9hUCZPvPmw]

I'm investigating the space handling issues on my Thinkpad R32 (and
others).  The problem is that some AML seems to fail with
AE_BAD_PARAMETER, as I reported on this list a week or two ago.  Lu
Tong came up with a hack that fixes it, but I'm trying to get a "real"
fix.

Anyway, I've tracked things down a bit and gotten the following
(heavily digested) info from debug traces:

evregion-0422 [26] ev_detach_region      : Removing Region cfec63a8 from address handler c135a128
evregion-0422 [26] ev_detach_region      : Removing Region cfeccfa8 from address handler c135a128
evregion-0535 [27] ev_attach_region      : Adding Region cfeccfa8 to address handler c135bda8 [EmbeddedControl]
evregion-0535 [27] ev_attach_region      : Adding Region cfec63a8 to address handler c135bda8 [EmbeddedControl]
evregion-0320 [43] ev_address_space_dispa: Addrhandler c135bda8 (c024cf8e), Address 000000000FF7BFC0

The AE_BAD_PARAMETER comes shortly after these messages.  

The first two lines seem to detach the "makeshift" handlers. The second
two are the handlers that are getting installed that are causing the
problem.  My question is how to I determine what  c135bda8 refers to(*)?


FWIW the new BIOS update that was mentioned on this list doesn't seem
to do very much of anything.  There's a one line change on the DSDT
and ECDT is still broken.  To add to the insult, it appears that
things have changed enough that you can't use the old corrected ecdt
table, you have to go through the rebuild process again.



(*)I suspect that if I could look at _all_ the tracing info, I'd be able to
find out, but I don't currently have a serial port, and there's more
information than can fit in the kmsg buffer (CONFIG_LOG_BUF_SHIFT of
greater than 21 prevents my machine from booting).  I was only able
to get this info by targeting areas I was interested in.  If someone
could give me a hint on where I should turn on tracing to get this
info I'd appreciated it.


--
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/

Re: Question about space handling

[Lu Tong]

you may want to take a look at this message (http://sourceforge.net/mailarchive/forum.php?thread_id=1828659&forum_id=6102). 

"Addrhandler c135bda8 (c024cf8e)" means an address handler struct at c135bda8 with a handler function at c024cf8e. from my trace, you can see that the handler function of addrhandler e7df4da8 was changed from c019be90(system_memory_space_handler) to 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.

hope the above explaination helps.

--ltong

On Wed, Apr 02, 2003 at 06:14:32PM -0500, bperkins-ooduxAEi7gVg9hUCZPvPmw@public.gmane.org wrote:
> I'm investigating the space handling issues on my Thinkpad R32 (and
> others).  The problem is that some AML seems to fail with
> AE_BAD_PARAMETER, as I reported on this list a week or two ago.  Lu
> Tong came up with a hack that fixes it, but I'm trying to get a "real"
> fix.
> 
> Anyway, I've tracked things down a bit and gotten the following
> (heavily digested) info from debug traces:
> 
> evregion-0422 [26] ev_detach_region      : Removing Region cfec63a8 from address handler c135a128
> evregion-0422 [26] ev_detach_region      : Removing Region cfeccfa8 from address handler c135a128
> evregion-0535 [27] ev_attach_region      : Adding Region cfeccfa8 to address handler c135bda8 [EmbeddedControl]
> evregion-0535 [27] ev_attach_region      : Adding Region cfec63a8 to address handler c135bda8 [EmbeddedControl]
> evregion-0320 [43] ev_address_space_dispa: Addrhandler c135bda8 (c024cf8e), Address 000000000FF7BFC0
> 
> The AE_BAD_PARAMETER comes shortly after these messages.  
> 
> The first two lines seem to detach the "makeshift" handlers. The second
> two are the handlers that are getting installed that are causing the
> problem.  My question is how to I determine what  c135bda8 refers to(*)?
> 
> 
> FWIW the new BIOS update that was mentioned on this list doesn't seem
> to do very much of anything.  There's a one line change on the DSDT
> and ECDT is still broken.  To add to the insult, it appears that
> things have changed enough that you can't use the old corrected ecdt
> table, you have to go through the rebuild process again.
> 
> 
> 
> (*)I suspect that if I could look at _all_ the tracing info, I'd be able to
> find out, but I don't currently have a serial port, and there's more
> information than can fit in the kmsg buffer (CONFIG_LOG_BUF_SHIFT of
> greater than 21 prevents my machine from booting).  I was only able
> to get this info by targeting areas I was interested in.  If someone
> could give me a hint on where I should turn on tracing to get this
> info I'd appreciated it.
> 
> 
> --
> 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/
> _______________________________________________
> Acpi-devel mailing list
> Acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/acpi-devel


-------------------------------------------------------
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/

Re: Question about space handling

[bperkins-ooduxAEi7gVg9hUCZPvPmw]

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/

Re: Question about space handling

[Lu Tong]

On Wed, Apr 02, 2003 at 10:58:23PM -0500, bperkins-ooduxAEi7gVg9hUCZPvPmw@public.gmane.org wrote:
> 
> 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? 

acpi_ec_add was called at the right time. look at my trace.

> Or some other reason the same structure is being
> assigned for both handlers (like a forgotten increment)?

it seems not the case according to my trace.
 
> 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.

totally agree. wish i could have some time this weekend to work on this problem.good luck. 

--ltong


-------------------------------------------------------
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/