From owner-freebsd-stable@freebsd.org Tue Sep 1 15:43:27 2015 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3B8809C6472 for ; Tue, 1 Sep 2015 15:43:27 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CEDCDF0C for ; Tue, 1 Sep 2015 15:43:26 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: by wicjd9 with SMTP id jd9so37783866wic.1 for ; Tue, 01 Sep 2015 08:43:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:message-id:to:subject:cc:reply-to :in-reply-to; bh=XrXDIWDC5hITGQBeikBPBjVj0hbAht6iwPeNWRS/RcY=; b=VlCy20hRmqeoN7Ombe5/0p5c1QP7wLFMa1+7k4nfsv5HRzanDYjHDX/X+yJ91taiit u2VLhQ4kkJBijmbRsFUZNl4Qs1wP1/XLDVOW+D7yy4PJlXXvloRMcmvIbTy18w7WRRZt w5YlAqla+MgLCphb7PSr6aB4sjH0mci3SXnFdJb8DI66XBXIEgjtUs9Kz4UvhkrBCSXN owC+LXaJ2UkdaUpjNt7KBh70OS57aM1qwlb0brlJ2EPoKEGPcdBEQlBOkq5gBvsKBBW9 tCQug+fJLhIafMtQpappGqObWk3uZrCbGEmt6ndvwldChg0grTHbpxFulQtOOf0vTS49 4Vvg== X-Gm-Message-State: ALoCoQlO0JzsBki7gt9D5zYlFGjHpjmwXf+nwgQYxxGot8iBSi6ZQy+azcWu/XvEOxPUvDgntlOJ X-Received: by 10.180.92.201 with SMTP id co9mr4231085wib.35.1441122199595; Tue, 01 Sep 2015 08:43:19 -0700 (PDT) Received: from mech-as222.men.bris.ac.uk (mech-as222.men.bris.ac.uk. [137.222.170.4]) by smtp.gmail.com with ESMTPSA id v9sm27773616wjq.41.2015.09.01.08.43.18 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 01 Sep 2015 08:43:18 -0700 (PDT) Received: from mech-as222.men.bris.ac.uk (localhost [127.0.0.1]) by mech-as222.men.bris.ac.uk (8.15.2/8.15.2) with ESMTP id t81FhHu9044662; Tue, 1 Sep 2015 16:43:17 +0100 (BST) (envelope-from mexas@mech-as222.men.bris.ac.uk) Received: (from mexas@localhost) by mech-as222.men.bris.ac.uk (8.15.2/8.15.2/Submit) id t81FhHhc044661; Tue, 1 Sep 2015 16:43:17 +0100 (BST) (envelope-from mexas) Date: Tue, 1 Sep 2015 16:43:17 +0100 (BST) From: Anton Shterenlikht Message-Id: <201509011543.t81FhHhc044661@mech-as222.men.bris.ac.uk> To: marcel@xcllnt.net, mexas@bris.ac.uk Subject: Re: ia64 stable/10 r286316: hang at Entering /boot/kernel/kernel Cc: freebsd-stable@freebsd.org, kostikbel@gmail.com Reply-To: mexas@bris.ac.uk In-Reply-To: X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2015 15:43:27 -0000 >From marcel@xcllnt.net Fri Aug 28 23:15:06 2015 > > >> On Aug 28, 2015, at 3:35 AM, Konstantin Belousov = >wrote: >>=20 >> Might be, try the latest stable/10 kernel with the problematic = >revision >> r286316 reversed ? This might add more points to the Marcel' note = >about >> some static relocation table processed early. > >I built a kernel off of revision 286315 and got this: > > eris% objdump -R kernel | grep FPTR64LSB | wc -l > 5377 > >We only reserve room for 4096 relocations, so we=E2=80=99re over >as it is. > >A kernel off of revision 286316 gave me this: > eris% objdump -R kernel | grep FPTR64LSB | wc -l > 5377 > >Same. Odd, but ok. It=E2=80=99s possible that the memory layout >changed such that we now scribble over something that=E2=80=99s >important. > >To be sure: Anton can you apply the following patch and >tell me if it makes a difference. It doubles the space >we set aside for relocations. > >Index: sys/ia64/ia64/locore.S >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >--- sys/ia64/ia64/locore.S (revision 286316) >+++ sys/ia64/ia64/locore.S (working copy) >@@ -357,5 +357,5 @@ > .align 16 > .global fptr_storage > fptr_storage: >- .space 4096*16 // XXX >+ .space 8192*16 // XXX > fptr_storage_end: So, 286316 boots ok without the patch if I remove everything from /boot/loader.conf. With the patch, and with kern.dfldsiz=536748032 # default soft limit for process data kern.dflssiz=536748032 # default soft limit for stack # hard limits kern.maxdsiz=536748032 # hard limit for process data kern.maxssiz=536748032 # hard limit for stack kern.maxtsiz=536748032 # hard limit for text size First time round I got: da1: Command Queueing enabled da1: 17366MB (35566478 512 byte sectors: 255H 63S/T 2213C) Loader variables: Manual root filesystem specification: : [options] Mount using filesystem and with the specified (optional) option list. eg. ufs:/dev/da0s1a zfs:tank cd9660:/dev/acd0 ro (which is equivalent to: mount -t cd9660 -o ro /dev/acd0 /) ? List valid disk boot devices . Yield 1 second (for background tasks) Abort manual input mountroot> And following an auto-reboot: OK boot -s ?[37m?[44mBooting...?[m Entering /boot/kernel/kernel at 0x9ffc000000010500... I'll do a few more tries now. Anton