<!doctype html public "-//w3c//dtd html 4.0 transitional//en"> <html> Dave Anderson wrote: <blockquote TYPE=CITE>Hi Sharyathi, I'm getting a lot of these on a live x86_64 system: if (avail > vt->kmem_max_limit) { error(INFO, "\"%s\" cache: shared array_cache.avail %d greater than limit %ld\n", si->curname, avail, vt->kmem_max_limit); si->errors++; FREEBUF(start_address); return; } I believe that the kmem_max_limit should be be multiplied by the number of nodes in this function, but since I have only one node, it appears that the the "max" calculation is significantly different at init-time vs. when the kmem command is run later? At a minimum, I would argue for noting somewhere that vt->kmem_max_limit should be bumped up the next time the kmem command is run. Or perhaps it should be recalculated prior to each kmem command run? Did you ever see this occurrance on a live ppc64 machine? Dave</blockquote> <tt>OK -- I found the bug here in your patch to max_cpudata_limit():</tt><tt></tt> <tt>+ if(readmem(start_address[i] + OFFSET(kmem_list3_shared), KVADDR, &shared, sizeof(void *),</tt> <tt>+ "kmem_list3 shared", RETURN_ON_ERROR|QUIET) ||</tt> <tt>+ readmem(shared + OFFSET(array_cache_limit),</tt> <tt>+ KVADDR, &limit, sizeof(int), "shared array_cache avail",</tt> <tt>+ RETURN_ON_ERROR|QUIET))</tt> <tt>+ if (limit > max_limit)</tt> <tt>+ max_limit = limit;</tt><tt></tt> <tt>The "limit" value was not even being read because the patch is using</tt> <tt>an "||" instead of an "&&" between the two readmem()'s. So it never</tt> <tt>does the second readmem(), and ends up using a leftover value of "limit".</tt><tt></tt> <tt>Don't bother filing another patch -- I'll keep working with this one.</tt><tt></tt> <tt>Thanks,</tt> <tt> Dave</tt> <tt></tt> <tt></tt> </html>