Created attachment 150384 [details]
efifb driver issue in hyperv 2012R2
HyperV 2012R2 or VMWare 10.0 workstation
installation ISO: ftp://ftp.freebsd.org/pub/FreeBSD/releases/amd64/amd64/ISO-IMAGES/10.1/FreeBSD-10.1-RELEASE-amd64-uefi-dvd1.iso
From FreeBSD10.1, it claims that it would support UEFI.
In HyperV 2012R2, I tried to Create a Generation 2 VM (secure boot disabled), and then install from the above IOS. In the boot up, it would hang on the following:
VT: running with driver "efifb"
After code check, there is something wrong with efifb driver in FreeBSD 10.1. I tried same steps in VMWare 10.0, it has same issue.
If you try to repro this issue in VMWare 10.0, you should follow this link to enable UEFI:
Andy checked that below fix is in 10.1 release.
r268227 | emaste | 2014-07-03 10:53:28 -0700 (Thu, 03 Jul 2014) | 8 lines
Display efi framebuffer dimensions on boot
Created attachment 158812 [details]
Verbose mode in boot
boot in verbose mode gets "freez loop" at
"Calibrating TSC clock"
This is believed to be fixed for everybody in FreeBSD -current as of today (revision 286667). Please test at your earliest convenience.
Created attachment 160298 [details]
FreeBSD 11.0-CURRENT r286893
On Hyper-V 2012 R2 with FreeBSD 11.0-CURRENT r286893 still gets the same freeze loop.
(In reply to Przemysław Mika from comment #4)
Tou want to create a different bug for that. Your console obviously works, so that menas this bug is still resolved. Your hang seems to be related to calibrating the TSC and chances are slim that that will get resolved without a bug for it.
(In reply to Marcel Moolenaar from comment #5)
In my opinion Andy didn't have problem with display efi framebuffer
(I guess that he didn't type boot -v).
My png files only shows what's going wrong when kenrel boots in verbose mode.
If it's really needed to create new bug I will do this.
Thanks for Your hard job.
This bug is not the same as the EFI frame buffer problems that were fixed. Re-opening so that the issue can be looked into.
Created attachment 160616 [details]
Also hung at Calibrating TSC clock ...
Encountering the same issue with 10.2-RELEASE UEFI bootonly ISO in Hyper-V generation 2 vm. The machine with the Hyper-V role installed is running Windows 10 Professional. VM is configured with Dynamic Memory enabled and 4GB startup RAM with Minimum 512MB, and 4 virtual CPUs. All options are selected for Integration Services.
Please let me know if I can help with diagnosis/resolution.
(In reply to Chris Lee from comment #8)
Also tried without Dynamic Memory enabled, and with Integration Services disabled. Same effect.
(In reply to Chris Lee from comment #9)
it's no matter which settings you will set in VM and which version of FreeBSD will be used.
Andy Zhang also wrote he tried to run on VMWare 10.0 and it has same issue.
it's not working with UEFI:
- FreeBSD 10.1,
- FreeBSD 10.2,
- FreeBSD 11-CURRENT
- Hyper-V 2012 r2
- VMWare 10.0
Effect is allways the same "Calibrationg TSC clock"
I hope some one from Development Team will soon look closer to this issue.
I believe what is happening is the TSC calibration is dropping to the i8254 PIT to calibrate the TSC and I don't think the Generation 2 Hyper-V has that.
(In reply to Mark Trettin from comment #11)
You might be able to get some useful information from this URL:
I was able to get further set machdep.disable_tsc_calibration=1
Created attachment 160883 [details]
ACPI APIC Table hang
I also get farther with
but it still hangs.
Perhaps this bug should be retitled as it appears to have nothing to do with the efifb driver?
To be fair, FreeBSD is not officially supported in a Hyper-V Generation 2 virtual machine. I would, however, like to help change that.
(In reply to Mark Trettin from comment #11)
> I believe what is happening is the TSC calibration is dropping to the i8254 PIT to
> calibrate the TSC and I don't think the Generation 2 Hyper-V has that.
Hi Mark, you're right. In Hyper-V generation-2 Linux VM, the ACPI timer is used to calibrate TSC.
With "set machdep.disable_tsc_calibration=1", the bootup can go further but the VM still hangs later -- I guess this may be a bad side effect of disabling TSC calibration and I guess the TSC has to be calibrated here, e.g., by the ACPI timer?
> With "set machdep.disable_tsc_calibration=1", the bootup can go further but the
> VM still hangs later -- I guess this may be a bad side effect of disabling TSC
> calibration and I guess the TSC has to be calibrated here, e.g., by the ACPI
When machdep.disable_tsc_calibration=1 is set the TSC frequency should be determined from the CPU identification instead.
Are you able to try a verbose boot with machdep.disable_tsc_calibration=1 set, and attach the boot log?
(In reply to Ed Maste from comment #17)
> When machdep.disable_tsc_calibration=1 is set the TSC frequency should be
> determined from the CPU identification instead.
OK, got it.
> Are you able to try a verbose boot with machdep.disable_tsc_calibration=1 set, and
> attach the boot log
Chris Lee has attached the log/screen in Comment 14 when the kernel hangs. I got the same log. It looks the kernel is in some busy loop forever.
NB: I guess Chris uses SMP VM.
If I use only 1 vCPU, FreeBSD 10.2 VM's kernel can boot fine and it finally stops at the Welcome screen for the installation (I'll attach the screen) -- the (virtual) keyboard doesn't work, so we can't go further...
This is because Generation-2 Hyper-V VM doesn't have the legacy 8042 keyboard, so a driver for the Hyper-V synthetic keyboard device is required inside the FreeBSD VM (BTW, Linux already has the driver) -- a new TODO. :-)
Created attachment 163496 [details]
the installation welcome screen
FYI: in a Generation-1 Hyper-V FreeBSD 10.2 VM running on Hyper-V 2012 R2, the tsc calibration by PIT seems broken:
Calibrating TSC clock ... TSC clock: 1264483083 Hz
CPU: Intel(R) Xeon(R) CPU E5-2670 v2 @ 2.50GHz (1264.48-MHz K8-class CPU)
Origin="GenuineIntel" Id=0x306e4 Family=0x6 Model=0x3e Stepping=4
Features2=0xfe982203<SSE3,PCLMULQDQ,SSSE3,CX16,SSE4.1,SSE4.2,POPCNT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND,HV> AMD Features=0x20100800<SYSCALL,NX,LM>
Structured Extended Features=0x200<ERMS>
We can see the 2.50GHz CPU is detected as 1.26G... It looks i8254_delay() may not work properly somehow.
I tried to put "machdep.tsc_skip_calibration=1" in /boot/loader.conf, but it looks this doesn't take effect -- anyone knows which loader config file I should put the setting into?
(In reply to Przemysław Mika from comment #10)
11-CURRENT and stable/10 currently do work with vmware / UEFI.
(In reply to Ed Maste from comment #21)
It looks the i8254 PIT counter emulated by Hyper-V is not reliable and I made a workaround patch here:
(In reply to Dexuan Cui from comment #22)
The TSC calibration issue was fixed in Apr:
https://github.com/freebsd/freebsd/commit/cff47489671a6ec6470f706f530df99c158511b0 and the fix was merged into 10.3, stable/11 and 12.-CURRENT.
but unluckily today I found the I couldn't boot UEFI VM (i.e. Hyper-V Generation-2 VM) with the 10.3 uefi iso and 11-beta1 iso. :-(
The symptom is the same (it looks the kernel crashes at the very early point where the uefi fb driver fails to load?). I'll report a new bug.
(In reply to Dexuan Cui from comment #24)
I reported a new bug:
Bug 211746 - [Hyper-V] UEFI VM can't boot from the iso installation disk
It looks the uefi loaders in 10.3 and 11-alpha/beta fail to load the kernel.
Is this still happening in 12.x and, if it's possible to test with snapshot builds, 13.0-CURRENT?
(In reply to Li-Wen Hsu from comment #26)
I think we can close this bug, because I believe this bug was fixed in 2016 (please refer to Comment 24). This bug should not reproduce with 10.3+, 11.x, 12.x or 13.x and newer.
(In reply to Dexuan Cui from comment #27)
Thanks for the explanation. IIUC, the both problems in this and bug 211746 have been fixed. It just doesn't get final tests. Is anyone able to confirm that 12.2-RELEASE and -CURRENT can boot in the Hyper-V Generation-2 VM?
(In reply to Li-Wen Hsu from comment #28)
Yes, I believe both the problems are fixed.
I just created some Generation-2 32-CPU VMs on 2 different Hyper-V hosts (Build 17763, and 20195(internal build)) with these images and all of the VMs booted up successfully:
(In reply to Dexuan Cui from comment #29)
Thanks very much for confirming the fix!