From owner-freebsd-current@freebsd.org Thu Mar 29 06:15:43 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 91292F50F8D for ; Thu, 29 Mar 2018 06:15:43 +0000 (UTC) (envelope-from tsoome@me.com) Received: from st13p35im-asmtp001.me.com (st13p35im-asmtp001.me.com [17.164.199.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2F8897CC26; Thu, 29 Mar 2018 06:15:43 +0000 (UTC) (envelope-from tsoome@me.com) Received: from process-dkim-sign-daemon.st13p35im-asmtp001.me.com by st13p35im-asmtp001.me.com (Oracle Communications Messaging Server 8.0.1.2.20170607 64bit (built Jun 7 2017)) id <0P6C00N006JZA600@st13p35im-asmtp001.me.com>; Thu, 29 Mar 2018 05:15:06 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=04042017; t=1522300506; bh=s1RbX8Vv5XtwQcZPt8iMib+HbBD8lLYKepq+aJMBQXc=; h=Content-type:MIME-version:Subject:From:Date:Message-id:To; b=P1B+ooPyG4aKDj/NfGyUxCihnvtcdzyiiEzbalE4MSsHW59G6Y8IMWkEBNz36CZs7 Q9mydqWz/mPxDm6oSNH3LvLiwp5xKuz9cQJ0PSDFUHPO2xjah0gJcL/nSyv6Q6egqq 4ZCHYLv9v1ABg8oqoqtO15FoCGNlHbjdXDrEUPnLqG2qymFFVRA1Wdocl7+vTUYL16 LhLEMDRy2RmhuBFh89qpUIxLzw+EpmHiI+ODPXBPC7eJy0X/VanvqJKEgRvJUEBYrQ ElRMvyorAZG0YE8Or1vcTozqo843/shxnS+gpu37LYqHW8UqUkoyk9+l0/51rdZfsr zZlMctG0sBdmg== Received: from icloud.com ([127.0.0.1]) by st13p35im-asmtp001.me.com (Oracle Communications Messaging Server 8.0.1.2.20170607 64bit (built Jun 7 2017)) with ESMTPSA id <0P6C001ES6L3CD40@st13p35im-asmtp001.me.com>; Thu, 29 Mar 2018 05:15:06 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2018-03-29_03:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1011 suspectscore=2 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1803290059 Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: Boot failure: panic: No heap setup From: Toomas Soome In-reply-to: Date: Thu, 29 Mar 2018 08:15:02 +0300 Cc: Warner Losh , Kyle Evans , FreeBSD Current Content-transfer-encoding: quoted-printable Message-id: References: <79d2bd72-f8b2-6476-9589-ebad9716698f@freebsd.org> To: Stefan Esser X-Mailer: Apple Mail (2.3445.5.20) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2018 06:15:43 -0000 > On 29 Mar 2018, at 01:06, Stefan Esser wrote: >=20 > Am 28.03.18 um 22:28 schrieb Warner Losh: >>> Hmmm, the code references point into the boot loader code - I had >>> expected that there is a problem in the kernel, not the boot loader. >>>=20 >>>> [1] >>>> = https://svnweb.freebsd.org/base/head/stand/libsa/sbrk.c?view=3Dmarkup#l56 >> = >>>=20 >>>=20 >>> Seems that setbase has either not been called or has been called = with >>> base=3D0. >>=20 >> Right, which is odd... >>=20 >>>> [2] >>>> = https://svnweb.freebsd.org/base/head/stand/i386/zfsboot/zfsboot.c?view=3Dm= arkup#l688 >> = >>>=20 >>>=20 >>> I had thought, that the zfs boot code has been initialized before = the >>> menu is displayed? >>=20 >> Right, all of this should be done looooong before we get to the >> interpreter. Can you break into the loader prompt and try the = `heap` >> command, see what that outputs? CC'ing imp@ because he actually = knows >> things. >>=20 >> Totally weird. I'd add a printf to the sethead() function to display = its args >> and see if you get this panic before/after that printf... >=20 > I'm currently using a Forth-enabled boot loader again, since this is a > "production" machine (my home server, which also receives and keeps = all > my work email, for example). >=20 > I'll build a clean world with the LUA loader and test it on one of the > next days. Tests will include the "heap" loader command and I'll add = the > printf (though, if sbrk() has really not been called, I guess that = will > not go too well ...). >=20 > Is it possible, that the setheap function is called a second time, = just > before jumping into the kernel? (In that case adding the printf might > crash the loader in the first setheap call ...) >=20 > Since the loader menu (and escaping from the menu) works, there must = be > a valid heap, at that time. >=20 indeed. and assuming the message really is from loader, it means, there = must be memory corruption - if so, you can check which variables are = located close to heap related ones=E2=80=A6 Also, since you have the = working menu, it has to be related to actual loading. Since the loading = itself has been working so far, it should be related to lua specific = bits which are preparing towards to call load functions. rgds, toomas