Bug 202276
| Summary: | Changes to vt(4) in r286667 makes FreeBSD unbootable in VirtualBox | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Base System | Reporter: | Ed Schouten <ed> | ||||||
| Component: | kern | Assignee: | Marcel Moolenaar <marcel> | ||||||
| Status: | Closed FIXED | ||||||||
| Severity: | Affects Some People | CC: | emaste, marcel | ||||||
| Priority: | --- | ||||||||
| Version: | CURRENT | ||||||||
| Hardware: | amd64 | ||||||||
| OS: | Any | ||||||||
| Attachments: |
|
||||||||
Any changes to device.hints or loader.conf? Anything significant about the VM configuration? To be precise about the VM configuration: do you have the extension pack and enabled settings that wouldn't otherwise be possible? It seems r286667 exposed a pre-existing bug in vt_vga(4). When selecting text mode, characters and attributes are written to the frame buffer at an offset of 0x18000. With the frame buffer at 0xA0000, this gives an effective address of 0xB8000 -- the beginning of the frame buffer in text mode. The bug is that we only map 64K. In other words: we access device memory outside of our mapped region. This bug went unnoticed due to the "kluge" mapping that was in place prior to r286667. Now that we properly map the frame buffer, an out of bounds access is fatal. A fix is being tested and will be attached shortly. Created attachment 159832 [details]
Proposed fix
Can you test the attached patch to make sure that this was indeed your problem?
Works for me. Thanks! A commit references this bug: Author: marcel Date: Thu Aug 13 14:43:12 UTC 2015 New revision: 286723 URL: https://svnweb.freebsd.org/changeset/base/286723 Log: Fix text mode operation. We first map 64KB at 0xA0000 and then determine whether to work in text or graphics mode. When graphics mode, the mapping is precisely what we need and everything is fine. But text mode, has the frame buffer relocated to 0xB8000. We didn't map that much to safely add 0x18000 bytes to the base address. Now we first check whether to work in text or graphics mode and then map the frame buffer at the right address and with the right size (0xA0000+64KB for graphics, 0xB8000+32KB for text). PR: 202276 Tested by: ed@ Changes: head/sys/dev/vt/hw/vga/vt_vga.c head/sys/dev/vt/hw/vga/vt_vga_reg.h A commit references this bug: Author: marcel Date: Tue Aug 25 14:39:44 UTC 2015 New revision: 287126 URL: https://svnweb.freebsd.org/changeset/base/287126 Log: MFC r286667 & r286723 Better support memory mapped console devices, such as VGA and EFI frame buffers and memory mapped UARTs. PR: 191564, 194952, 202276 Changes: _U stable/10/ stable/10/sys/amd64/amd64/machdep.c stable/10/sys/amd64/amd64/pmap.c stable/10/sys/conf/files.amd64 stable/10/sys/conf/files.i386 stable/10/sys/dev/vt/hw/efifb/efifb.c stable/10/sys/dev/vt/hw/vga/vt_vga.c stable/10/sys/dev/vt/hw/vga/vt_vga_reg.h stable/10/sys/i386/i386/machdep.c stable/10/sys/i386/i386/pmap.c stable/10/sys/x86/include/bus.h stable/10/sys/x86/x86/bus_machdep.c |
Created attachment 159818 [details] Screenshot of VirtualBox Attached is a screenshot of a GENERIC FreeBSD kernel at r286667 booting in VirtualBox 5.0.0. Almost immediately after starting the kernel, video gets corrupted and the system locks up. r286666 works properly. The same also happened with VirtualBox 4.3.28 and 4.3.30. I'm using the boot loader from FreeBSD 10.1. As far as I know, that shouldn't be an issue, right? We want FreeBSD 11.0 to be bootable from 10.