On Sun, Jul 21, 2013 at 11:31:34AM +0200, Gustau P?rez i Querol wrote: > > > The issue happened somewhere before the process exit. Try the patch > > below, the idea is that your overflow count is really big, so the > > wrong-doer could cause underflow when acting. > > > > diff --git a/sys/amd64/amd64/pmap.c b/sys/amd64/amd64/pmap.c > > index 19be4e0..fcdc6af 100644 > > --- a/sys/amd64/amd64/pmap.c > > +++ b/sys/amd64/amd64/pmap.c > > _at__at_ -465,6 +465,9 _at__at_ pmap_resident_count_dec(pmap_t pmap, int count) > > { > > > > PMAP_LOCK_ASSERT(pmap, MA_OWNED); > > + KASSERT(pmap->pm_stats.resident_count >= count, > > + ("pmap %p resident count underflow %ld %d", pmap, > > + pmap->pm_stats.resident_count, count)); > > pmap->pm_stats.resident_count -= count; > > } > > > Hi, > > the assert doesn't happen (that's resident_count is not bigger than > count). You can find the complete core at: > > https://dl.dropboxusercontent.com/u/2094962/core.txt.5 I do not understand what do you mean, it seems that core.txt.5 has exactly the assertion fired which I added. Show me the verbose dmesg, including the i915 driver attach. Did the issue started at some moment, or it is a new install which exhibit the problem from the beginning ? As a blind shot, try to revert r252653. I am sure that the serial console would be useful, but I did not decided yet on where to start looking.
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:39 UTC