Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 8 Jun 2017 18:10:05 -0500
From:      Alan Cox <alc@rice.edu>
To:        John Baldwin <jhb@freebsd.org>
Cc:        Bryan Drewery <bdrewery@freebsd.org>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org
Subject:   Re: svn commit: r319702 - head/sys/vm
Message-ID:  <E22C2D48-A27D-4B16-8785-101BEF8BFAD5@rice.edu>
In-Reply-To: <1987063.fEClCI1ZXD@ralph.baldwin.cx>
References:  <201706081618.v58GIfZi066106@repo.freebsd.org> <6910627.IXO0pzjk4q@ralph.baldwin.cx> <207FB492-94EE-47FD-BFB8-18F76C5858A5@rice.edu> <1987063.fEClCI1ZXD@ralph.baldwin.cx>

next in thread | previous in thread | raw e-mail | index | archive | help


> On Jun 8, 2017, at 5:28 PM, John Baldwin <jhb@freebsd.org> wrote:
> 
> On Thursday, June 08, 2017 05:07:40 PM Alan Cox wrote:
>> 
>>> On Jun 8, 2017, at 2:37 PM, John Baldwin <jhb@freebsd.org> wrote:
>>> 
>>> On Thursday, June 08, 2017 12:55:45 PM Bryan Drewery wrote:
>>>> On 6/8/17 12:18 PM, John Baldwin wrote:
>>>>> Author: jhb
>>>>> Date: Thu Jun  8 16:18:41 2017
>>>>> New Revision: 319702
>>>>> URL: https://svnweb.freebsd.org/changeset/base/319702
>>>>> 
>>>>> Log:
>>>>> Fix an off-by-one error in the VM page array on some systems.
>>>>> 
>>>>> r31386 changed how the size of the VM page array was calculated to be
>>>>> less wasteful. 
>>>> 
>>>> r313186
>>> 
>>> Oops.  FWIW, this commit fixes a reliable panic booting mips and mips64
>>> kernels under qemu.  Adrian also reported the same panic on real mips
>>> hardware.
>>> 
>> 
>> Any architecture on which we don’t have superpage reservations enabled could experience the panic at boot time.  Amd64, arm, arm64, i386, and sparc64 would never panic because of the memory allocated for the reservation array. 
> 
> Even then it seems to not be guaranteed.  The original change has
> been in CheriBSD for a while, and we have not seen any panics on boot under
> qemu as I saw with plain FreeBSD probably due to slightly different early
> memory allocations.
> 

That makes sense.  Only a small subset of all possible memory sizes would trigger the panic, and that subset amounted to only 2.5% of all possible memory sizes.





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E22C2D48-A27D-4B16-8785-101BEF8BFAD5>