With the commit of r335510 releng/11.2 switched to -RELEASE. So I updated one of my home server from 11.1-RELEASE-p11 to 11.2-RELEASE. But when I rebooted I found OS boot messages are not displayed on console while OS itself has booted successfully. To be exact, 1. BIOS message are displayed. 2. Boot menu of FreeBSD is displayed. 3. Kernel boot starts but after 'Booting...' no following messages are displayed. 4. After OS has booted console stays unusable. Kernel configuration is as follwing. ---------------------------------------------------------------------- yasu@maybe[2006]% uname -a ~ FreeBSD maybe.home.utahime.org 11.2-RELEASE FreeBSD 11.2-RELEASE #0 r335513: Fri Jun 22 16:12:12 JST 2018 rootz@maybe.home.utahime.org:/usr0/freebsd/base/obj/usr0/freebsd/base/releng/11.2/sys/MAYBE amd64 yasu@maybe[2007]% cat /usr/src/sys/amd64/conf/MAYBE ~ # # MAYBE -- Local kernel configuration file of maybe for FreeBSD/amd64 # # For more information on this file, please read the config(5) manual page, # and/or the handbook section on Kernel Configuration Files: # # http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the ../../conf/NOTES and NOTES files. # If you are in doubt as to the purpose or necessity of a line, check first # in NOTES. # # $FreeBSD$ include GENERIC ident MAYBE # ZFS support options ZFS # PF support device pf #PF OpenBSD packet-filter firewall device pflog #logging support interface for PF # # Temperature sensors: # # coretemp: on-die sensor on Intel Core and newer CPUs # device coretemp yasu@maybe[2008]% ---------------------------------------------------------------------- I tried GENERIC kernel but the problem still happened. HWs are, M/B: ASUS N3150I-C (https://www.asus.com/us/Motherboards/N3150IC/) Display: EIZO FlexScan L565 (http://www.eizoglobal.com/support/db/products/model/L565) M/B and display are connected with analog VGA. I have another 11.1-RELEASE-p11 amd64 environment working as guest of VirtualBox whose host is 64bit Windows 10. So I updated it to 11.2-RELEASE like my home server in question. But in this case console worked fine just as it was 11.1-RELEASE-p11. So the problem seems to be hardwear dependent. I added above lines to /boot/loader.conf and rebooted system. Then all boot messages are displayed and console works fine. ---------------------------------------------------------------------- # Load SysCons driver kern.vty=sc ---------------------------------------------------------------------- So I'm certain somthing is wrong with vt(4) of 11.2-RELEASE.
I see something similar when running a fairly recent head, where the SVGA screen is blank. In my case, power cycling the monitor would bring things up until I switched virtual consoles. Using "sc" I don't see the problem, so I switched my kernel config to it, since I got tired of power cycling the monitor. In this case, my hardware is old P4 stuff (it just says vgapci0: VGA-compatible-display in dmesg when I boot with "sc").
The same is also often true for Nvidia cards -- no matter the age. So as a rule I _always_ include sc(4) in my KERNCONF. I'm also not terribly excited about the overall output/capabilities of vt(4) aside from the more easily achieved resolution, and refresh rates. It doesn't play well with my editor(s), nor can I copy/paste. The buffering is lacking... But I have nothing to bring to the table to improve things. So I can't *really* complain. I just use sc(4). :-) I might also add; I applaud the efforts to accomplish as much as *was* accomplished with vt(4). It isn't an easy task. --Chris
From the output of following commands, svn log https://svn.freebsd.org/base/releng/11.2/sys/dev/vt svn log https://svn.freebsd.org/base/releng/11.1/sys/dev/vt svn log https://svn.freebsd.org/base/stable/11/sys/dev/vt Graph can be made about update of /usr/src/sys/dev/vt and branch of releng/11.1 and releng/11.2 as following. stable/11 releng/11.1 releng/11.2 | r318506 | +---------------(r320486) | | r321087 | | | r321199 | | | r326543 | | | r329283 | | | r329305 | | | r330641 | | | r330642 | | | r330897 | | | r316019 | | | r315480 | | | r330916 | | | r330917 | | | r330921 | | | r331722 | | | r331982 | | | | r331984 | | r332643 | r332744 | +-------------------------------(r334459) | | So I used binary search algorithm to find which commit is the cause of vt(4) breakage and got following result. (2) r318506 vt(4) works fine r321087 r321199 r326543 r329283 r329305 r330641 r330642 (4) r330897 vt(4) works fine (3) r316019 'make buildkernel' fails r315480 (6) r330916 vt(4) works fine (7) r330917 vt(4) works fine (8) (r330920) vt(4) works fine (5) r330921 vt(4) is broken r331722 r331982 r332643 r332744 (1) r334459 vt(4) is broken (1),(2),(3),... are order of search. According to the result above the source of problem is base r330921. Commit messages of this commit says as following. ---------------------------------------------------------------------- r330921 | eadler | 2018-03-14 17:27:05 +0900 (2018/03/14 (水)) | 7 lines MFC r330834: vt_vga: check if VGA is available from ACPI FADT table On x86 the IA-PC Boot Flags in the FADT can signal whether VGA is available or not. ---------------------------------------------------------------------- So I guess something is wrong with way to check availability of VGA. Or there may be bug about IA-PC Boot Flags in the ACPI FADT table.
+ base r330834 author
Hello Eitan, As is explained in comment #0 and comment #3, there is vt(4) breakage under some hardware environment in 11.2-RELEASE. And I found it happens after base r330921 you committed on March 14. Do you have any idea what is wrong and/or how this problem can be investigated further?
(In reply to Yasuhiro KIMURA from comment #5) Oops, I overlooked base r330921 is MFC of base r330834. So I should have ask author of original commit. And Andriy has already added him to CC. I'm sorry for bothering you but would you please remove yourself from CC?
Sorry, I'm currently away until Monday. Can you attach the output of 'acpidump - t' on the affected machine?
Created attachment 194555 [details] Output of 'acpidump -t' on ASUS N3150-C box (In reply to Roger Pau Monné from comment #7) Attached file is output of 'acpidump -t' on my home server in question.
(In reply to Yasuhiro KIMURA from comment #8) Thanks. The following: IAPC_BOOT_ARCH={LEGACY_DEVICES,8042,NO_VGA} Is what causes this issue, and AFAICT it's a firmware bug. I can add flag to ignore the ACPI FADT NO_VGA flag, but you will have to set it in the loader in order to workaround the bug. Let me prepare a patch.
Created attachment 194623 [details] proposed patch #1 Can you please try the attached patch setting: hw.vga.acpi_ignore_no_vga=1 In loader.conf.
(In reply to Roger Pau Monné from comment #9) It's quite acceptable for me that source of this problem is firmware bug of motherboard. ASUS N3150I-C is fairly buggy. I have experienced following problems since I bought it. 1. If system is up for more than about 1 week, then 'shutdown -r' doesn't work as is expected. System itself is shut down successfully but final reset is not triggered. 2. Suddenly 'maybe kernel: re0: watchdog timeout' message is displayed several times and then NIC gets unavailable. Only way to make NIC available again is to reboot system.
(In reply to Yasuhiro KIMURA from comment #11) Have you checked if there are firmware updates on the vendor site? Sometimes those issues are solved by updating to a newer version of the firmware.
(In reply to Roger Pau Monné from comment #12) Yes, I checked support page of vendor site. But sadly firmware version of mine is already latest one.
(In reply to Roger Pau Monné from comment #10) Thank you for patch. I applied it to base r335578 of releng/11.2 and confirmed vt(4) works fine by setting 'hw.vga.acpi_ignore_no_vga=1' in /boot/loader.conf.
Fix/workaround committed as r335629. eadler do you want to MFC it? (since you MFC'ed the original commit) I think waiting 3 days should be enough given this is a workaround and doesn't change existing behaviour.
I'd be happy to MFC if the original author doesn't. It may take longer than 3 days due to time constraints though.
A commit references this bug: Author: eadler Date: Sat Jul 28 07:37:02 UTC 2018 New revision: 336805 URL: https://svnweb.freebsd.org/changeset/base/336805 Log: MFC r335629: vt: add option to ignore NO_VGA flag in ACPI To workaround buggy firmware that sets this flag when there's actually a VGA present. Ref D16003 PR: 229235 Changes: _U stable/11/ stable/11/share/man/man4/vt.4 stable/11/sys/dev/vt/hw/vga/vt_vga.c
A commit references this bug: Author: eadler Date: Sun Jul 29 05:14:27 UTC 2018 New revision: 336858 URL: https://svnweb.freebsd.org/changeset/base/336858 Log: MFC r335631: Always initialize the ignore local variable. PR: 229235 Changes: _U stable/11/ stable/11/sys/dev/vt/hw/vga/vt_vga.c
(In reply to Yasuhiro KIMURA from comment #11) With regard to the re0 watchdog timeout, it's a known issue with the built-in FreeBSD driver. I compiled the latest Realtek driver (1.95) for the pfSense project's 2.4.4 release (based on FreeBSD 11.2-RELEASE-p3) which works fine. If you're interested, I posted the binary here: https://forum.netgate.com/topic/135850/official-realtek-driver-binary-1-95-for-2-4-4-release Instructions for how to use it are here: https://forum.netgate.com/topic/133536/official-realtek-driver-v1-95-binary