svn commit: r266850 - in head/sys/arm/xscale: i80321 i8134x ixp425 pxa

[Alan Cox]

On 06/01/2014 03:11, John-Mark Gurney wrote:
> Alan Cox wrote this message on Fri, May 30, 2014 at 11:04 -0500:
>> On 05/30/2014 01:32, John-Mark Gurney wrote:
>>> Olivier Houchard wrote this message on Thu, May 29, 2014 at 19:38 +0200:
>>>> On Thu, May 29, 2014 at 10:19:18AM -0700, Adrian Chadd wrote:
>>>>> On 29 May 2014 10:16, Olivier Houchard <cognet at ci0.org> wrote:
>>>>>> On Thu, May 29, 2014 at 10:14:53AM -0700, Adrian Chadd wrote:
>>>>>>> Have you tested this on xscale hardware?
>>>>>> Yeah, my two last commits were an attempt to get the AVILA kernel to boot
>>>>>> again.
>>>>> Woo! What can I provide to help you do this? :-)
>>>>>
>>>>> (Drinks? Food? Donations?)
>>>>>
>>>>>
>>>> Drinks and food are always appreciated ;)
>>>> It almost boots for me now, except a few userland programs gets SIGSEGV or
>>>> SIGILL along the way, trying to figure out why.
>>> Thanks for fixing ddb... I'm getting panic messages again...  bad
>>> news is that my panic is still around:
>>> panic: vm_page_alloc: page 0xc07e73b0 is wired
>>>
>>> Though, interestingly, it looks like sparc64 has a similar panic:
>>> https://www.freebsd.org/cgi/query-pr.cgi?pr=187080
>>>
>>> kib, Alan, any clue to why this is happening?  Any suggestions as to
>>> help track it down?
>> I'm afraid not.  The dump below shows a perfectly normal, in-use page. 
>> If this page had actually been free prior to the vm_page_alloc() call,
>> then other fields, like dirty, would have been different.  In other
>> words, this isn't just a problem with the wire count.
>>
>> What object is vm_page_alloc() being performed on?
> Is this enough?  Or do you need more?
>
> panic: vm_page_alloc: page 0xc07e73b0 is wired, obj: 0xc1500b40
> KDB: enter: panic
> [ thread pid 781 tid 100051 ]
> Stopped at      kdb_enter+0x40: ldrb    r15, [r15, r15, ror r15]!
> db> show object/f 0xc1500b40
> Object 0xc1500b40: type=2, size=0xa, res=9, ref=0, flags=0x0 ruid -1 charge 0
>  sref=0, backing_object(0)=(0)+0x0
>   memory:=(off=0x0,page=0x8f0000),(off=0x1,page=0x8f1000),(off=0x2,page=0x8ee000),(off=0x3,page=0x8ef000),(off=0x4,page=0x8f3000),(off=0x5,page=0x8f4000)
>    ...(off=0x6,page=0x8fa000),(off=0x7,page=0x8fb000),(off=0x8,page=0x8fc000)
>
> If you need more, let me know what/how to get it, and I will...
>


Anyone who has seen the "wired page" panic, please try the attached
patch.  It introduces some new KASSERT()s that may help me to narrow
down the problem.  I haven't been able to trigger these KASSERT()s on
amd64, but the symptoms that you guys are reporting are consistent with
a bug that would trigger these KASSERT()s.


>>> Lastest dump of the vm_page from a tree from today is:
>>> {'act_count': '\x00',
>>>  'aflags': '\x00',
>>>  'busy_lock': 1,
>>>  'dirty': '\xff',
>>>  'flags': 0,
>>>  'hold_count': 0,
>>>  'listq': {'tqe_next': 0xc07e7400, 'tqe_prev': 0xc06e63a0},
>>>  'md': {'pv_kva': 3235893248,
>>>         'pv_list': {'tqh_first': 0x0, 'tqh_last': 0xc07e73e0},
>>>         'pv_memattr': '\x00',
>>>         'pvh_attrs': 0},
>>>  'object': 0xc06e6378,
>>>  'oflags': '\x04',
>>>  'order': '\t',
>>>  'phys_addr': 9424896,
>>>  'pindex': 3581,
>>>  'plinks': {'memguard': {'p': 0, 'v': 3228461644},
>>>             'q': {'tqe_next': 0x0, 'tqe_prev': 0xc06e6a4c},
>>>             's': {'pv': 0xc06e6a4c, 'ss': {'sle_next': 0x0}}},
>>>  'pool': '\x00',
>>>  'queue': '\xff',
>>>  'segind': '\x02',
>>>  'valid': '\xff',
>>>  'wire_count': 1}
>>>
>>> This appears to be on the kmem_object list as:
>>> c06e62d8 B kernel_object_store
>>> c06e6378 B kmem_object_store
>>> c06e6418 b old_msync
>>>
>>> and you can see the tqh_last would be part of kmem_object_store...
>>>
>>> Could this be something bad happening w/ when memory is low?  The
>>> board I'm testing on has only 64MB (54MB avail), so it hits that
>>> pretty quickly...

-------------- next part --------------
Index: vm/vm_phys.c
===================================================================
--- vm/vm_phys.c	(revision 267209)
+++ vm/vm_phys.c	(working copy)
@@ -693,6 +693,7 @@ vm_phys_free_pages(vm_page_t m, int order)
 void
 vm_phys_free_contig(vm_page_t m, u_long npages)
 {
+	vm_page_t m_tmp;
 	u_int n;
 	int order;
 
@@ -714,6 +715,10 @@ vm_phys_free_contig(vm_page_t m, u_long npages)
 		n = 1 << order;
 		if (npages < n)
 			break;
+		for (m_tmp = m; m_tmp < &m[n]; m_tmp++)
+			KASSERT(m_tmp->object == NULL ||
+			    (m_tmp->flags & PG_CACHED) != 0,
+			    ("vm_phys_free_contig: xxx"));
 		vm_phys_free_pages(m, order);
 		m += n;
 	}
@@ -721,6 +726,10 @@ vm_phys_free_contig(vm_page_t m, u_long npages)
 	for (; npages > 0; npages -= n) {
 		order = flsl(npages) - 1;
 		n = 1 << order;
+		for (m_tmp = m; m_tmp < &m[n]; m_tmp++)
+			KASSERT(m_tmp->object == NULL ||
+			    (m_tmp->flags & PG_CACHED) != 0,
+			    ("vm_phys_free_contig: yyy"));
 		vm_phys_free_pages(m, order);
 		m += n;
 	}