https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=297136
Tomoaki AOKI <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #3 from Tomoaki AOKI <[email protected]> --- If the issue is with screen configurations, and assuming UEFI boots without CSM, sc driver shouldn't work, as no physical or emulated text VRAM exists. If the issue is on screen resolution, loader variables to try would be: *efi_max_resolution *kern.vt.fb.default_mode Note that the latter needs screen depth, too, like "1920*1080x32". Available resolution and depth should be shown in `gop list` on loader command prompt. Choose one your monitor can handle. Maybe unlikely, but there can a bit of possibility that cache attribute for framebuffer matters. In this case, hw.efifb.cache_attr="uc" possibly help (default: "wc"). Anyway, if you're NOT loading NVIDIA related kmods via /boot/loader.conf, NVIDIA kmods related issues should happen much later, after devmatch, devd and devfs starts (means, kernel already kicks /sbin/init) and kld_list in /etc/rc.conf is started processing. So early kernel messages should be shown even if kmod are somehow problematic. If not screen related, what I can think of now are ACPI related (framebuffer and/or memmapped I/O is mapped to unusual address outside default address range of ACPI, for example) or vm.pmap related oddities. But not sure. -- You are receiving this mail because: You are the assignee for the bug.
