https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=288507
--- Comment #4 from Mark Johnston <[email protected]> --- (In reply to Mark Millard from comment #2) Here it looks like several fields in the vm_page structure are corrupted. The page pointer itself appears to be within the bounds of the vm_page array (which should be about 4GB in size on a system with 198110MB of RAM. kgdb shows us the other page pointers in the batch: 183 ss = {bq = {bq_pa = {0xfffffe0030a1e500, 0xfffffe00a8798110, 184 0xfffffe00e3083e30, 0xfffffe00a47a4228, 0xfffffe002b6d8ef8, 185 0xfffffe0065cf29a0, 0xfffffe007a1b83b8, 0xfffffe008cf7b3c0, 186 0xfffffe005cd565e0, 0xfffffe0048ced5d8, 0xfffffe00c761d488, 187 0xfffffe008a5efe90, 0xfffffe00cf341738, 0xfffffe00413f97b8, 188 0xfffffe005270cc68, 0xfffffe00a5d9d690, 0xfffffe00294329e0, 189 0xfffffe005ef52f00, 0xfffffe0020dff308, 0xfffffe00ce1e9a40, 190 0xfffffe007ec47618, 0xfffffe005d1ba7e8, 0xfffffe0032d73470, 191 0xfffffe0030835e88, 0xfffffe009969c438, 0xfffffe00f151b0c8, 192 0xfffffe0063916fe8, 0xfffffe00dac0b778, 0xfffffe0016267348, 193 0xfffffe00b74a5fe0, 0xfffffe003434ef80, 0xfffffe009e31e840, 194 0xfffffe00530f6408, 0xfffffe00e0649508, 0xfffffe0102e87ad8, 195 0xfffffe0092c52848, 0xfffffe00ba829618, 0xfffffe008bf0fd10, 196 0xfffffe00550708c0, 0xfffffe00eedc67b8, 0xfffffe00d45f8210, 197 0xfffffe00b89a8698, 0xfffffe0082ffb310, 0xfffffe00accd53c0, 198 0xfffffe0091c8f5d8, 0xfffffe004e20f180, 0xfffffe004dfb4f90, 199 0xfffffe00a437fbb0, 0xfffffe00218cb698, 0xfffffe004ee5d278, 200 0xfffffe00a9e845a0, 0xfffffe0025d4a7c8, 0xfffffe0037612ac8, 201 0xfffffe005c7d3da8, 0xfffffe00d307c1b8, 0xfffffe00ee416538, 202 0xfffffe0043747508, 0xfffffe00ef30b508, 0xfffffe00c04de600, 203 0xfffffe008c0e3040, 0xfffffe0071a97b40, 0xfffffe005b644ad8, 204 0xfffffe00dd5da3b0}, bq_cnt = 39}, It might be nice to see the dumps of other page structures in the batch, e.g., with (kgdb) p/x *(vm_page_t)0xfffffe0030a1e500 and so on for the other values in that bq_pa array. In particular, m->plinks.q.tqe_next looks sane, but the prev pointer is bogus. If you haven't tried a GENERIC-DEBUG kernel yet, that would be the next thing to test. (In reply to Mark Millard from comment #3) atomic_load_ptr(&m->object) tends to denote access without the corresponding object lock held, which is a minority of accesses. Even without synchronization, the pointer value ought to be valid (i.e., somewhere in the direct map or kernel map) or 0. In any case, given the fact that other fields are corrupted, this observation is almost certainly unrelated. -- You are receiving this mail because: You are the assignee for the bug.
