panic on vm_page_cache_transfer: object 0xfffffff0035508000's type is not compatible with cache pages

[Willem Jan Withagen]

On 18-3-2011 16:38, Alan Cox wrote:
> On 03/08/2011 08:15, John Baldwin wrote:
>> On Tuesday, March 08, 2011 5:54:36 am Willem Jan Withagen wrote:
>>> System:
>>>
>>> FreeBSD zfs.digiware.nl 8.2-STABLE FreeBSD 8.2-STABLE #1: Sat Feb 26
>>> 06:28:43 CET 2011
>>> root at zfs.digiware.nl:/usr/obj/usr/src/src8/src/sys/ZFS  amd64
>>>
>>> Don't have a serial console, so I wrote down the traceback.
>>> But my guess is that that is not enough, however I needed the system so
>>> I rebooted.
>>>
>>> tb:
>>> vm_object_split        at .... +0x125
>>> vm_space_fork        at .... +0x3f7
>>> fork1            at .... +0x6a9
>>> fork            at .... +0xee
>>> syscall_entr        at ....    +1c
>>> syscall            at ....    +4c
>>>
>>> rip = 0x8006bc39c
>>> rsp = 0x7fffffffe9d8
>>> rbp = 0x800a04470
>>>
>>> It looks a lot like what I find on
>>> http://people.freebsd.org/~pho/stress/log/kostik079.html
>>>
>>> But my system is amd64, with 8Gb RAM and is fully ZFS based
>>> with swap on 2 gpt freebsd-swap partitions.
>>>
>>> System crashed last night around 1:30, which is when a few large rsync
>>> backups are coming in.
>>>
>>> Would I be able to call doadump to obtain something usefull afterward
>>> (provided I have savecore set?)
>> Hmm, judging from the info at the URL above, I'm not sure what to make
>> of this
>> assertion.  In vm_object_split(), the 'new_object' is always
>> OBJT_DEFAULT, so
>> it will always fail that half of the assertion.  In fact, this is the
>> only
>> place that vm_page_cache_transfer() is called, so 'new_object->type ==
>> OBJT_SWAP' is pretty much guaranteed to almost never be true.
>>
>> I guess it is assuming that swap_pager_copy() would have always converted
>> 'new_object' to OBJT_SWAP if it had any cache pages?  Perhaps that is
>> a bogus
>> assumption if 'orig_object' only has cache pages and no
>> currently-swapped out
>> pages (or if the swapped out pages are not in the range of the new
>> object)?
>>
>> I've cc'd Alan to see if he has any ideas.
>>
> 
> Yes, it is assuming that the object is converted to OBJT_SWAP.  As a
> rule, for a page to be PG_CACHE, it should exist somewhere on secondary
> storage.

The panic has only occured twice thusfar, since I upgraded to FreeBSD
8.2-STABLE (ZFS) #1: Sat Feb 26 06:28:43 CET 2011.

But I have the feeling that in due course, it'll return again.
So if there are any suggestions on how to proceed, I would be happy to
have a go at them.

--WjW