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>