Bug 229235 - vt(4) of 11.2-RELEASE is broken with hardware dependent problem.
Summary: vt(4) of 11.2-RELEASE is broken with hardware dependent problem.
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 11.2-RELEASE
Hardware: amd64 Any
: --- Affects Some People
Assignee: freebsd-bugs mailing list
Depends on:
Reported: 2018-06-22 18:18 UTC by Yasuhiro KIMURA
Modified: 2019-03-16 19:51 UTC (History)
7 users (show)

See Also:

Output of 'acpidump -t' on ASUS N3150-C box (3.89 KB, text/plain)
2018-06-24 10:41 UTC, Yasuhiro KIMURA
no flags Details
proposed patch #1 (1.27 KB, patch)
2018-06-25 07:05 UTC, Roger Pau Monné
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Yasuhiro KIMURA 2018-06-22 18:18:53 UTC
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

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

So I'm certain somthing is wrong with vt(4) of 11.2-RELEASE.
Comment 1 Rick Macklem freebsd_committer 2018-06-22 20:35:50 UTC
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").
Comment 2 Chris Hutchinson 2018-06-22 20:58:42 UTC
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.

Comment 3 Yasuhiro KIMURA 2018-06-23 20:11:55 UTC
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
|               |
r321087         |
|               |
r321199         |
|               |
r326543         |
|               |
r329283         |
|               |
r329305         |
|               |
r330641         |
|               |
r330642         |
|               |
r330897         |
|               |
r316019         |
|               |
r315480         |
|               |
r330916         |
|               |
r330917         |
|               |
r330921         |
|               |
r331722         |
|               |
r331982         |
|               |
|               r331984
|               |
|                               |

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
(4)  r330897  vt(4) works fine
(3)  r316019 'make buildkernel' fails
(6)  r330916  vt(4) works fine
(7)  r330917  vt(4) works fine
(8) (r330920) vt(4) works fine
(5)  r330921  vt(4) is broken
(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.
Comment 4 Andriy Gapon freebsd_committer 2018-06-23 20:29:00 UTC
+ base r330834 author
Comment 5 Yasuhiro KIMURA 2018-06-23 20:37:13 UTC
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?
Comment 6 Yasuhiro KIMURA 2018-06-23 21:07:45 UTC
(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?
Comment 7 Roger Pau Monné freebsd_committer 2018-06-24 10:19:01 UTC
Sorry, I'm currently away until Monday. Can you attach the output of 'acpidump - t' on the affected machine?
Comment 8 Yasuhiro KIMURA 2018-06-24 10:41:23 UTC
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.
Comment 9 Roger Pau Monné freebsd_committer 2018-06-25 06:49:43 UTC
(In reply to Yasuhiro KIMURA from comment #8)
Thanks. The following:


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.
Comment 10 Roger Pau Monné freebsd_committer 2018-06-25 07:05:54 UTC
Created attachment 194623 [details]
proposed patch #1

Can you please try the attached patch setting:


In loader.conf.
Comment 11 Yasuhiro KIMURA 2018-06-25 07:41:10 UTC
(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.
Comment 12 Roger Pau Monné freebsd_committer 2018-06-25 07:43:30 UTC
(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.
Comment 13 Yasuhiro KIMURA 2018-06-25 08:04:49 UTC
(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.
Comment 14 Yasuhiro KIMURA 2018-06-25 08:11:01 UTC
(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.
Comment 15 Roger Pau Monné freebsd_committer 2018-06-25 09:43:36 UTC
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.
Comment 16 Eitan Adler freebsd_committer freebsd_triage 2018-06-25 10:37:02 UTC
I'd be happy to MFC if the original author doesn't. It may take longer than 3 days due to time constraints though.
Comment 17 commit-hook freebsd_committer 2018-07-28 07:37:31 UTC
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

  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

_U  stable/11/
Comment 18 commit-hook freebsd_committer 2018-07-29 05:15:26 UTC
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

  MFC r335631:

  Always initialize the ignore local variable.
  PR:		229235

_U  stable/11/
Comment 19 freebsd 2018-09-25 20:48:48 UTC
(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:

Instructions for how to use it are here: