src/sys/vm, branch stable/2.1 FreeBSD source tree https://cgit-dev.freebsd.org/src/atom?h=stable%2F2.1 1999-09-05T08:39:22Z $Id$ -> $FreeBSD$ 1999-09-05T08:39:22Z Peter Wemm peter@FreeBSD.org 1999-09-05T08:39:22Z urn:sha1:c0b6460abc80cd8953e4eda185c4cad96dcb39c8 Fixed bug that could lead to pmap corruption during asynchronous page 1996-11-24T00:19:47Z David Greenman dg@FreeBSD.org 1996-11-24T00:19:47Z urn:sha1:289746cecf092a3cc66a6cb09cc05e8cf39fff57 cleans and then cause a panic or worse. Submitted by: dyson and wcarchive In vm_page_alloc_contig(), round "size" up to the next page boundry. Not 1996-10-24T04:31:51Z David Greenman dg@FreeBSD.org 1996-10-24T04:31:51Z urn:sha1:bb5056e7ae5bc5c28074635e415f98cfd0311197 doing so breaks the looping and bad things will happen. This was exposed when testing some (aha2940) fixes from Justin that didn't work because of this. This fix is relevant only to -stable since -current already has the equivilent in the contigmalloc() routine. Applied changes similar to rev 1.52: treat kmem_map and mb_map equally 1996-07-07T03:29:44Z David Greenman dg@FreeBSD.org 1996-07-07T03:29:44Z urn:sha1:2d26d694c0d89423be1b60f59531d216078f8aaf in special cases. From main branch: Kill a bogus VM_WAIT in vm_fault_wire() that may have 1996-07-02T10:59:04Z David Greenman dg@FreeBSD.org 1996-07-02T10:59:04Z urn:sha1:d41f579b5750f9e5503e0d9035235cb0285489d8 undesired effects. Submitted by: dyson Fixed rather serious bug in the use of pmap_kenter() in kmem_malloc(). 1996-07-01T14:22:22Z David Greenman dg@FreeBSD.org 1996-07-01T14:22:22Z urn:sha1:be094295a6054209939abc776f1d560b2c7d0540 It's important that pmap_enter() be used here because the pages won't be removed from the kernel VM when freed otherwise. This would result in the potential for the wrong page(s) being used if a vm_map_pageable() was done on this same address space (since no fault would occur, the previous page(s) would be bogusly used instead). This is almost certainly yet another cause of wcarchive instabilities. Thanks to John Dyson for helping me track this one down! Make sure we have an object in the map entry before trying to trim pages 1996-06-29T09:17:17Z David Greenman dg@FreeBSD.org 1996-06-29T09:17:17Z urn:sha1:717eb31334651fb0e2403b42873a02d6137fe7bd from it. Add another check to vm_pageout_clean: make sure the page isn't wired. 1996-06-27T10:29:09Z David Greenman dg@FreeBSD.org 1996-06-27T10:29:09Z urn:sha1:5cf25e9cfd30653d8b90c9ffb666511e0bca815e Correct a minor ommision: I left out a vput() when unwinding an exceptional 1996-06-27T10:15:40Z David Greenman dg@FreeBSD.org 1996-06-27T10:15:40Z urn:sha1:6b48c17a15f36fecce5a42d0458af03b7e18d7d3 condition. Also, it's possible that we might not be dealing with the same page if the vget() should block but still succeed (this is possible), so be sure to check to see that the page is still dirty and on the PG_INACTIVE queue. Checks in vm_pageout_clean() will guarantee that the page is still a condidate for pageout (busy, hold, PG_BUSY, etc). Increased slptime threshold for swapout from 4 seconds to 10. The old 1996-06-27T05:48:51Z David Greenman dg@FreeBSD.org 1996-06-27T05:48:51Z urn:sha1:e0959bc037504dbad39e7dbecc2494818e2fb789 value was far too aggressive.