panic on vm_page_cache_transfer: object 0xfffffff0035508000's
type is not compatible with cache pages
John Baldwin
jhb at freebsd.org
Tue Mar 8 21:24:16 UTC 2011
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.
--
John Baldwin
More information about the freebsd-stable
mailing list