Date: Tue, 11 Nov 2014 09:57:49 -0800 From: Adrian Chadd <adrian@freebsd.org> To: Ed Maste <emaste@freebsd.org> Cc: FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: HEADS-UP: amd64 UEFI boot is broken Message-ID: <CAJ-Vmo=3dvPnGedmLCe4dDVBKBMPHA17rAjO8bOTZ4DuQ=tP4Q@mail.gmail.com> In-Reply-To: <CAPyFy2AcZFD6hE2LeHue3c0vvUGRGKBNBYB=7e5avqHRS2GQ4Q@mail.gmail.com> References: <CAPyFy2BHBGMU_eyBo8kHqtWHyQvhaKVJOHCTfT_h0yu%2BnPzExw@mail.gmail.com> <CAPyFy2AcZFD6hE2LeHue3c0vvUGRGKBNBYB=7e5avqHRS2GQ4Q@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 11 November 2014 07:12, Ed Maste <emaste@freebsd.org> wrote: > On 10 November 2014 20:17, Ed Maste <emaste@freebsd.org> wrote: >> UEFI booting is broken for amd64 as of r273582 (Oct 24). The symptom >> is an apparent hang after the loader transfers control to the kernel >> (no output from the kernel is observed). Until this is addressed you >> can checkout an earlier revision or revert r273582 locally. > > I have committed a workaround for this issue in r274382. The vt(4) EFI > framebuffer driver makes use of kernel infrastructure in a way that is > not correct, but works in practice, and this was caught by a new > assertion added in r273582. My change loosens the assertion to allow > efifb's use for now. > > We will need to fix the early framebuffer implementation in a subsequent change. Woo, thanks! -adrian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-Vmo=3dvPnGedmLCe4dDVBKBMPHA17rAjO8bOTZ4DuQ=tP4Q>