On Sep 16, 2017 14:02, "Andreas Tobler" <andre...@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 _______________________________________________ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
