freebsd stable - Mar 2011 - panic on vm_page_cache_transfer: object 0xfffffff0035508000's type is not compatible with cache pages

System:

FreeBSD zfs.digiware.nl 8.2-STABLE FreeBSD 8.2-STABLE #1: Sat Feb 26 
06:28:43 CET 2011 
root@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?)

--WjW

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

-- 
John Baldwin