From owner-freebsd-current@freebsd.org Thu Mar 9 07:11:20 2017 Return-Path: Delivered-To: freebsd-current@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 628E5D0478A for ; Thu, 9 Mar 2017 07:11:20 +0000 (UTC) (envelope-from tsoome@me.com) Received: from st13p35im-asmtp002.me.com (st13p35im-asmtp002.me.com [17.164.199.65]) (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 33DD71B9 for ; Thu, 9 Mar 2017 07:11:20 +0000 (UTC) (envelope-from tsoome@me.com) Received: from process-dkim-sign-daemon.st13p35im-asmtp002.me.com by st13p35im-asmtp002.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) id <0OMJ00C00CYNVH00@st13p35im-asmtp002.me.com> for freebsd-current@freebsd.org; Thu, 09 Mar 2017 07:11:13 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=4d515a; t=1489043473; bh=ZE3HDG1ltgfPJkxdsezNv0GWw96vvBMDnNR6FVsDqMk=; h=From:Content-type:MIME-version:Subject:Date:To:Message-id; b=rIK+TW95Jvo729FcUNTnbypDdUQT3nmY7r2fyxgvUoS6fX8jEXyy1dT6K3vZ4CC+7 LzgQY4eVrxfVah4RCMSd87+N7X0RGi9Aib6vuQQs6BxQZ5FX7g++MCQ7RMjCuVSifm pk0Al7L0vkztFMyoFa3NYQX5/A4IlAEUi8W2KRSX68fY1Tbxa8i0eklpnl/o9XCZxC amXEx4+p38OSW//927R/dM+tpb+ml8h3B4HJ/STJ3/VAQbLh4smwxbbah7lC4cbdR+ hDOM299AsfbnivMmGW821ICmqpYeMNazixJkGvXcusgSlGOAmyvcGdSDt/U2VDdSho DB5LpkJExmwhA== Received: from icloud.com ([127.0.0.1]) by st13p35im-asmtp002.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) with ESMTPSA id <0OMJ009NZDAMDW00@st13p35im-asmtp002.me.com> for freebsd-current@freebsd.org; Thu, 09 Mar 2017 07:11:12 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-03-09_06:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1034 suspectscore=10 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1701120000 definitions=main-1703090056 From: Toomas Soome MIME-version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: input/output error @boot Date: Thu, 09 Mar 2017 09:11:09 +0200 References: <6779d31b-a285-3002-8ecc-5738ac88df27@madpilot.net> <441BF371-53C4-4FE8-A39C-BFA8B25DE760@freebsd.org> To: FreeBSD Current In-reply-to: Message-id: <63EAF6F6-D5E4-46F9-9AA1-C721DAC64C11@me.com> X-Mailer: Apple Mail (2.3259) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 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, 09 Mar 2017 07:11:20 -0000 > On 9. m=C3=A4rts 2017, at 8:00, Dexuan Cui = wrote: >=20 > Hi Roberto,=20 > Thanks for sending me your memmap and this is a temporary workaround > patch for you: > = https://github.com/dcui/freebsd/commit/0edd1db55fbbb56352d6024250e4ae7dd8a= d31e3.patch >=20 > I put the memmap info here for people who're interested: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D211746#c26 >=20 > We can notice there is a 4MB BootServicesCode range at [12MB, 16MB) . > loader.efi just writes into this range by force -- this is unsafe = anyway! >=20 > To fix this correctly & thoroughly, IMO we need a relocatable kernel, = but > that would require a lot of complicated long term work: > https://reviews.freebsd.org/D9686?id=3D25414#inline-56969 >=20 > For now, I suggest we should only apply the idea "reduce the size of = the > staging area if necessary" to VM running on Hyper-V, we should restore = the > old behavior on physical machines since that has been working for = people > for a long period of time, though it's potentially unsafe. >=20 > I think in the loader we can use CPUID to tell if we're running on = Hyper-V or not. IMO there are multiple issues around this problem and workaround. First of all, to control UEFI memory allocation, the AllocatePages() has = options: AllocateAnyPages, AllocateMaxAddress, AllocateAddress On x86, we use: staging =3D 1024*1024*1024; status =3D BS->AllocatePages(AllocateMaxAddress, EfiLoaderData, nr_pages, &staging); Which means: "Allocation requests of Type AllocateMaxAddress allocate any available = range of pages whose uppermost address is less than or equal to the = address pointed to by Memory on input.=E2=80=9D So, we are asking for an amount of memory (64MB), with condition that = all the pages should be below 1GB. And we get it. If hyper-v is in fact returning us memory from already = occupied area - there can be exactly one conclusion - it is bug in = hyper-v. Note, this allocation method does *not* set the starting point for = allocation, it can return us *any* chunk of memory of given size, below = 1GB. So the attempt to control such allocation by size, is unfortunately = flawed - it really does not control the allocation. Note that I have also seen AllocateAddress failures - there was nicely = available chunk of memory, but the firmware just did not allocate with = given address (it did happen with OVMF + qemu). The secondary flaw there is also about firmware. Sure, with UEFI you can = have =E2=80=9Crandom=E2=80=9D allocations and the actual control over = memory is actually problem, but to plant an =E2=80=9Cegg=E2=80=9D in = 1MB-1GB range, where you have most chances any OS will live - IMO this = is just stupid. The only real solution here is to either rise the MaxAddress limit or = use AllocateAnyPages, get kernel loaded into the memory, and after = switching off the boot services and before jumping to kernel, relocate = the kernel to available location below 1GB=E2=80=A6=20 rgds, toomas >=20 > Thanks, > -- Dexuan >=20 >> -----Original Message----- >> From: owner-freebsd-current@freebsd.org [mailto:owner-freebsd- >> current@freebsd.org] On Behalf Of Dexuan Cui >> Sent: Thursday, March 9, 2017 10:44 >> To: Roberto Rodriguez Jr >> Cc: FreeBSD Current >> Subject: RE: input/output error @boot >>=20 >> [This sender failed our fraud detection checks and may not be who = they appear >> to be. Learn about spoofing at http://aka.ms/LearnAboutSpoofing] >>=20 >> Hmm, Alex did report 314891 worked. >>=20 >> Can you please post the full boot log of the loader? >> Especially, when you see the =E2=80=9COK=E2=80=9D prompt, can you = please run the =E2=80=9Cmemmap=E2=80=9D >> command like this link ... >>=20 >> You can take a photo of the screen and send it to me, if it=E2=80=99s = too big. >>=20 >> Thanks, >> -- Dexuan >=20 > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to = "freebsd-current-unsubscribe@freebsd.org"