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:
>=20
> On Thursday, June 08, 2017 05:07:40 PM Alan Cox wrote:
>>=20
>>> On Jun 8, 2017, at 2:37 PM, John Baldwin <jhb@freebsd.org> wrote:
>>>=20
>>> 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
>>>>>=20
>>>>> Log:
>>>>> Fix an off-by-one error in the VM page array on some systems.
>>>>>=20
>>>>> r31386 changed how the size of the VM page array was calculated to =
be
>>>>> less wasteful.=20
>>>>=20
>>>> r313186
>>>=20
>>> 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.
>>>=20
>>=20
>> Any architecture on which we don=E2=80=99t 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.=20
>=20
> 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.
>=20

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>