Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 11 Feb 2013 19:18:44 +0100
From:      David Demelier <demelier.david@gmail.com>
To:        freebsd-acpi@freebsd.org
Subject:   Re: uma for acpi object cache
Message-ID:  <51193604.6060504@gmail.com>
In-Reply-To: <51018223.4030702@FreeBSD.org>
References:  <20130122175629.GA1714@garage.freebsd.pl> <51008661.4060006@FreeBSD.org> <510101B4.4030409@FreeBSD.org> <51017D79.6060202@FreeBSD.org> <51018223.4030702@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On 24/01/2013 19:49, Andriy Gapon wrote:
> 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.
> 

Hello,

I don't know if it's related, I tried your patch and sometime my dmesg
is filled with that :

Feb 11 19:06:16 Melon kernel: ACPI Warning: Large Reference Count
(0x5F3E) in object 0xfffffe0003820990Large Reference Count (0x5F47) in
object 0xfffffe00017f7798 (20110527/utdelete-481)
Feb 11 19:06:16 Melon kernel: ACPI Warning: Large Reference Count
(0x5F47) in object 0xfffffe0003820990 (20110527/utdelete-481)
Feb 11 19:06:16 Melon kernel: ACPI Warning: Large Reference Count
(0x5F47) in object 0xfffffe00018dcc18 (20110527/utdelete-481)
Feb 11 19:06:16 Melon kernel: ACPI Warning: Large Reference Count
(0x5F47) in object 0xfffffe00038207e0 (20110527/utdelete-481)
Feb 11 19:06:16 Melon kernel: ACPI Warning: Large Reference Count
(0x5F45) in object 0xfffffe00018076c0 (20110527/utdelete-481)
Feb 11 19:06:16 Melon kernel: ACPI Warning: Large Reference Count
(0x5F48) in object 0xfffffe00017f7798 (20110527/utdelete-481)
Feb 11 19:06:16 Melon kernel: ACPI Warning: Large Reference Count
(0x5F48) in object 0xfffffe0003820990 (20110527/utdelete-481)

And my computer get just unusable, I must shutdown by force because that
messages does not stop at all.

I have more and more ACPI problems since I've updated to 9.1...



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?51193604.6060504>