on 24/01/2013 22:33 Jung-uk Kim said the following:
> On 2013-01-24 13:49:07 -0500, Andriy Gapon wrote:
>> on 24/01/2013 20:29 Jung-uk Kim said the following:
>>> 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.
> 
> Hmm...  I am not really sure local cache is to blame here.  If you
> really want to prove your theory, I think a simple modification to
> utcache.c should do:
> 
>      Cache->LinkOffset = 8;
>      Cache->ListName   = CacheName;
>      Cache->ObjectSize = ObjectSize;
> -    Cache->MaxDepth   = MaxDepth;
> +    Cache->MaxDepth   = 0;
> 
>      *ReturnCache = Cache;
>      return (AE_OK);
> 
> This should effectively kill object caching.

That's a very simple trick, I wonder why I didn't think about it :-)
Now I need to wait until one of the reporters resurfaces.

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