Hi,
I was debugging the issue by viewing the free ques "sysctl vm.phys_free" and
also using "show page" in ddb.
The inactive memory is never being released back into the free que.
I thought that when inactive memory reaches a certain threshold that the kernel
will start reclaiming and move it t
On Tue, Oct 30, 2018 at 09:46:59AM +, Bennett, Ciunas wrote:
> Hi,
>
> I was debugging the issue by viewing the free ques "sysctl
> vm.phys_free" and also using "show page" in ddb. The inactive memory
> is never being released back into the free que. I thought that when
> inactive memory reach
Hi,
The only other activity that is running is the csh script that is inserting
and removing the kernel module.
I am not using the VM for any other purpose but to run this test.
In my tests the correlation between memory allocation and moving to inactive
list can be seen.
I don't think any other
On Tue, Oct 30, 2018 at 11:15:47AM +, Bennett, Ciunas wrote:
> Hi,
> The only other activity that is running is the csh script that is inserting
> and removing the kernel module.
> I am not using the VM for any other purpose but to run this test.
> In my tests the correlation between memory a
I have disk with GPT scheme and three partitions:
p1 - freebsd-boot
p2 - freebsd-ufs
p3 - freebsd-ufs
pmbr is installed on this disk, and gptboot is installed on p1. Both p2
and p3 contains valid FreeBSD installation, with /boot/loader, kernel,
and everything.
I have attribute "bootme" set o
Lev Serebryakov lev at FreeBSD.org wrote on
Tue Oct 30 18:37:14 UTC 2018 :
> I have disk with GPT scheme and three partitions:
>
> p1 - freebsd-boot
> p2 - freebsd-ufs
> p3 - freebsd-ufs
>
> pmbr is installed on this disk, and gptboot is installed on p1. Both p2
> and p3 contains valid FreeBSD
On Tue, 2018-10-30 at 21:37 +0300, Lev Serebryakov wrote:
> I have disk with GPT scheme and three partitions:
>
> p1 - freebsd-boot
> p2 - freebsd-ufs
> p3 - freebsd-ufs
>
> pmbr is installed on this disk, and gptboot is installed on p1. Both
> p2
> and p3 contains valid FreeBSD installation, w
Hello Mark,
Wednesday, October 31, 2018, 12:38:07 AM, you wrote:
>> After that loader, loaded from p2, loads kernel from p3 and boots
>> system from p3!
> Are the kernel's on p2 and p3 distinct in an identifiable way?
> Can you be sure it was not a mix of the p2 kernel and p3 world
> that boote
Hello Ian,
Wednesday, October 31, 2018, 1:58:49 AM, you wrote:
> While loader(8) is loading the kernel, interrupt it to get the console
> prompt (or ask the menu to give the prompt if you use menus) and do:
> unload
> set currdev=disk0p2
> boot
Thnx!
Is it possible to pass this informatio
