Date: Thu, 9 Mar 2017 18:37:18 -0800 From: Pete Wright <pete@nomadlogic.org> To: freebsd-current@freebsd.org Subject: Re: input/output error @boot Message-ID: <b1d88a71-675f-67d4-e08f-e7356a0cd6f5@nomadlogic.org> In-Reply-To: <32d229ef-370c-de44-0405-640459514924@nomadlogic.org> References: <CACnPvjLv_QhhxYvcbU44x=n0pk61xyFgUGWcTYh%2B6HaGUGJMFg@mail.gmail.com> <441BF371-53C4-4FE8-A39C-BFA8B25DE760@freebsd.org> <CACnPvjK%2Bb6x3SAD7Gu7uFTkx=iCm2afgt4boVquTT5BC_sF4Tg@mail.gmail.com> <MWHPR03MB2669AB5FFC455EE6BBAAE765BF2F0@MWHPR03MB2669.namprd03.prod.outlook.com> <CACnPvj%2BvrkYGR3b_CoDkORksB6ENZ5HLdzD6=ebJm1329LcfJQ@mail.gmail.com> <CACnPvj%2BQDZZjHzwU7VcsNFN784R4=gYe6qzhQb0NG0AQpov=5g@mail.gmail.com> <MWHPR03MB26699DF5E658361614D71A5EBF2E0@MWHPR03MB2669.namprd03.prod.outlook.com> <CACnPvjKW8di44raA=MxEbqfNPkYaoQ5uOCkgcT3tf1i733i1KA@mail.gmail.com> <CACnPvjJnTyxQu-4-MYB3rPWGZ4TJa%2B=niLkKdtaNTiO%2Bbw=hug@mail.gmail.com> <MWHPR03MB2669510547F2244091F676BCBF210@MWHPR03MB2669.namprd03.prod.outlook.com> <MWHPR03MB26696FB5963990FE4455609CBF210@MWHPR03MB2669.namprd03.prod.outlook.com> <77119d47-3c14-68ce-a0cc-ba7cc8f61598@nomadlogic.org> <MWHPR03MB266983F3C3FF3C6EF99BB70DBF210@MWHPR03MB2669.namprd03.prod.outlook.com> <32d229ef-370c-de44-0405-640459514924@nomadlogic.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 3/9/17 8:10 AM, Pete Wright wrote: > > > On 3/9/17 4:42 AM, Dexuan Cui wrote: >>> From: owner-freebsd-current@freebsd.org [mailto:owner-freebsd- >>> current@freebsd.org] On Behalf Of Pete Wright >>> Sent: Thursday, March 9, 2017 14:04 >>> To: freebsd-current@freebsd.org >>> Subject: Re: input/output error @boot >>> On 3/8/17 10:00 PM, Dexuan Cui wrote: >>>> 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. >>>> >>> +1 >>> >>> i'd like to see the old behaviour for physical machines to be restored >>> as well since this has rendered my drm-next test rig broken :( >>> >>> -pete >> >> Eventually I committed 314956 for the issue: >> https://svnweb.freebsd.org/base?view=revision&revision=314956 >> The old behaviour for physical machines are restored. >> >> PS, I understand usually I should put the patch on phabricator for >> review, >> before it's committed, but since the issue here is critical, I >> committed it >> directly to unblock people first. Sorry. >> Please comment on the patch if you think it needs rework -- I hope >> not. :-) >> > > Thank you Dexuan - I will do a build today and reboot when I am home > from work tonight. FWIW I verified that if I boot my system with in > "classic" BIOS mode I am able to load the kernel and go multi-user, so > this is probably the fix for me. > Happy to report that 314956 addresses the issue I was having with UEFI not booting. Thanks for the fix! -pete -- Pete Wright pete@nomadlogic.org @nomadlogicLA
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?b1d88a71-675f-67d4-e08f-e7356a0cd6f5>