The memstick boots, and prints information about the EFI frame buffer: EFI framebuffer information: addr, size 0x90020000, 0x1c20000 dimensions 2880 x 1800 stride 4096 masks 0x00ff0000, 0x0000ff00, 0x000000ff, 0xff000000 Environment: memstick: FreeBSD-11.0-CURRENT-amd64-20150421-r281832-memstick.img Machine: MacBook Pro mid-2012 EFI version: 1.0 EFI Firmware: Apple (rev 1.10) MacBookPro10,1 ROM Version MBP101.00EE.B07 SMC Version 2.3f36 How-To-Repeat: dd the memstick snapshot image to a USB thumb drive, try to boot the machine and watch it hang... Fix: unknown
Can confirm that this issue affects my machine as well. Machine: MacBook5,1 (late-2008 aluminum)
Perhaps related to https://forums.freebsd.org/threads/system-hangs-at-uefi-boot-on-nvidia-ko.48963/
Can confirm this occurring on my Macbook 5.1 (late 2008 aluminum). Perhaps related to https://forums.freebsd.org/threads/system-hangs-at-uefi-boot-on-nvidia-ko.48963/ Please update this bug ticket to include : See Also: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193646
I have tried the Aug 4th snapshot on a early-2015 13" MBP which reports: addr, size 0xb0000000, 0x1437000 dimensions 2880 x 1800 stride 2944 masks 0x00ff0000, 0x0000ff00, 0x000000ff, 0xff000000 I'm a bit puzzled by the dimensions, as wikipedia says that the resolution is 2560x1600... The mid-2012 reports the same as in the original report... But appears to boot as the USB still gets accessed and I can push the power button, and it will turn off... My mid-2015 15" MBP reports: addr, size 0x80180000, 0x13c6800 dimensions 2880 x 1800 stride 2880 masks 0x00ff0000, 0x0000ff00, 0x000000ff, 0xff000000 This appears not to boot as the USB drive turns off and stays off, and a short press of the power button does not do anything...
Ok, on my mid-2015 15" MBP, if I set kern.vty=sc at boot loader prompt, then the machine boots (I can shut it down w/ the power key), but the console does not work.. So, it looks like vt is doing some thing on the mid-2015 15" MBP that causes the machine to crash early on...
*** This bug has been marked as a duplicate of bug 193745 ***