on 24/01/2013 20:29 Jung-uk Kim said the following:
> On 2013-01-24 04:41:08 -0500, Andriy Gapon wrote:
>> on 24/01/2013 02:54 Jung-uk Kim said the following:
>> I think that I have a much better patch for all potential ACPI
>> object cache problems :-) 
>> http://people.freebsd.org/~avg/acpi-uma-cache.diff
> 
>> What do you think?
> 
> We have to fix this bug because local cache is always used for
> userland applications, e.g., iasl.

Could you please clarify what problem/bug is fixed by that patch?
I looked hard but couldn't spot any difference besides moving the link pointer
from offset 8 to offset 0.

> BTW, I tried something like that long ago.  In fact, the first attempt
> goes all the way back to this patch (warning: it's naive, broken, and
> overly complicated):
> 
> http://people.freebsd.org/~jkim/acpica/OsdCache.diff
> 
> I have more up-to-date and correct patch to use UMA but I'm still not
> 100% convinced whether we want to do it or not.

Hmm, your patch looks a bit more complicated than mine.
What is all that extra stuff that you have there?

> When utcache.c works,
> it works fairly well, actually. :-)

Well, my primary motivation for the patch is all the reports about mysterious
panics that seem to involve the cache:
http://thread.gmane.org/gmane.os.freebsd.devel.acpi/7562
http://thread.gmane.org/gmane.os.freebsd.devel.acpi/7613
http://thread.gmane.org/gmane.os.freebsd.devel.acpi/7077

There were a few more reports with the same theme.
I hoped that using uma(9) instead of hand-rolled code would lead to better
diagnostic and debugging cabilities.

-- 
Andriy Gapon
_______________________________________________
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Reply via email to