Date: Sat, 16 Sep 2017 21:01:56 +0200 From: Andreas Tobler <andreast@FreeBSD.org> To: Mark Johnston <markj@FreeBSD.org> Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r323290 - head/sys/vm Message-ID: <67bb96f2-da01-8bce-65ba-bf811f51e56d@FreeBSD.org> In-Reply-To: <20170914203232.GA72190@bish> References: <201709072143.v87Lhdsg060310@repo.freebsd.org> <c25a9965-b665-51ad-abe6-71beb2ae0440@FreeBSD.org> <20170914203232.GA72190@bish>
next in thread | previous in thread | raw e-mail | index | archive | help
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. > 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?67bb96f2-da01-8bce-65ba-bf811f51e56d>