Bug 229235
| Summary: | vt(4) of 11.2-RELEASE is broken with hardware dependent problem. | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Base System | Reporter: | Yasuhiro Kimura <yasu> | ||||||
| Component: | kern | Assignee: | freebsd-bugs (Nobody) <bugs> | ||||||
| Status: | Closed FIXED | ||||||||
| Severity: | Affects Some People | CC: | admin, eadler, freebsd, pi, portmaster, rmacklem, royger | ||||||
| Priority: | --- | ||||||||
| Version: | 11.2-RELEASE | ||||||||
| Hardware: | amd64 | ||||||||
| OS: | Any | ||||||||
| See Also: | https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230172 | ||||||||
| Attachments: |
|
||||||||
|
Description
Yasuhiro Kimura
2018-06-22 18:18:53 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"). 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 |