Date: Sat, 16 Sep 2017 15:32:33 -0500 From: Justin Hibbits <chmeeedalf@gmail.com> To: Andreas Tobler <andreast@freebsd.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Mark Johnston <markj@freebsd.org> Subject: Re: svn commit: r323290 - head/sys/vm Message-ID: <CAHSQbTC18YM2MNrwJKgQW8ShUnQaa%2B5BiaJS7nYemqmTX8KFBA@mail.gmail.com> In-Reply-To: <67bb96f2-da01-8bce-65ba-bf811f51e56d@FreeBSD.org> References: <201709072143.v87Lhdsg060310@repo.freebsd.org> <c25a9965-b665-51ad-abe6-71beb2ae0440@FreeBSD.org> <20170914203232.GA72190@bish> <67bb96f2-da01-8bce-65ba-bf811f51e56d@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sep 16, 2017 14:02, "Andreas Tobler" <andreast@freebsd.org> wrote: On 14.09.17 22:32, Mark Johnston wrote: > On Thu, Sep 14, 2017 at 09:51:17PM +0200, Andreas Tobler wrote: > >> Hi Mark, >> >> On 07.09.17 23:43, Mark Johnston wrote: >> >>> Author: markj >>> Date: Thu Sep 7 21:43:39 2017 >>> New Revision: 323290 >>> URL: https://svnweb.freebsd.org/changeset/base/323290 >>> >>> Log: >>> Speed up vm_page_array initialization. >>> We currently initialize the vm_page array in three passes: one >>> to zero >>> the array, one to initialize the "order" field of each page >>> (necessary >>> when inserting them into the vm_phys buddy allocator one-by-one), and >>> one to initialize the remaining non-zero fields and individually >>> insert >>> each page into the allocator. >>> Merge the three passes into one following a suggestion from alc: >>> initialize vm_page fields in a single pass, and use >>> vm_phys_free_contig() >>> to efficiently insert physical memory segments into the buddy >>> allocator. >>> This reduces the initialization time to a third or a quarter of what >>> it >>> was before on most systems that I tested. >>> Reviewed by: alc, kib >>> MFC after: 3 weeks >>> Differential Revision: https://reviews.freebsd.org/D12248 >>> >>> Modified: >>> head/sys/vm/vm_page.c >>> head/sys/vm/vm_phys.c >>> head/sys/vm/vm_phys.h >>> >> >> I just found out that this commit breaks booting my powerpc64 Quad G5. >> It hangs, pressing ctrl-t shows: cmd: sh [*vm active pagequeue]. >> >> Sometimes it hangs earlier when the kbd is not there yet (usb), then I >> can't get the process/task where it hangs. >> >> Note, this kernel is compiled with the default gcc (4.2.1-FreeBSD) >> >> Any ideas how to find out what's wrong? >> > > Are you able to break into DDB when the hang occurs? If so, the output > of "show page" would be helpful. > Unfortunately not from the beginning. The keyboard is usb and it gets installed late. Once it survives the loading of the kbd and co, I can enter into ddb. But it is a trial and error. So far I didn't succeed to come that far. What about using dcons? That's saved me many times when I couldn't break into ddb from the console. Are you running with INVARIANTS configured? If not, please try that. > The above was w/o INVARIANTS. With invariants the kernel panics immediately after boot, see pic. The previous revision, r323289 seems stable, at least it survived >> several kernel builds. >> > > Could you apply the patch below and capture the first page or so of > output from after the kernel starts booting? > I applied this diff and you see its output on the pic: https://people.freebsd.org/~andreast/r323290_generic64_with_dbg_patch.jpg I try now to get that far that I have a kbd and capture a 'show page'. Thanks, Andreas
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAHSQbTC18YM2MNrwJKgQW8ShUnQaa%2B5BiaJS7nYemqmTX8KFBA>