# System hangs at (UEFI) boot on nvidia.ko



## ucsdboy (Nov 14, 2014)

I tested the latest 10.1-RELEASE DVD (UEFI) and found that the system seems to hang when loading nvidia.ko after a reboot. It doesn't seem to matter whether I build it from ports or use the packaged version. loader.conf has 
	
	



```
"nvidia_load=YES"
```
 and rc.conf has 
	
	



```
"linux_enable=YES"
```
 f10 has also been installed.


----------



## user222 (Nov 14, 2014)

I encountered this as well.


----------



## ColdfireMC (Nov 14, 2014)

Note that FreeBSD is leaving emulators/linux-f10 support and migrating to emulators/linux-c6 . See updating notes .

UEFI loader is failing on load some kmods. Stay alert. In the meanwhile, load the Nvidia kmod once booted.


----------



## ucsdboy (Nov 15, 2014)

Thanks! I'll do that.


----------



## Juanitou (Nov 15, 2014)

At least some NVIDIA cards and the new vt(4) console, which is enabled automatically when booting via UEFI, seem to have issues working together: PR 194112, PR 193770.


----------



## ucsdboy (Nov 17, 2014)

Thanks, I'll try soft-linking my modules from /boot/modules to /boot/kernel.


----------



## ColdfireMC (Nov 17, 2014)

Juanitou said:


> At least some NVIDIA cards and the new vt(4) console, which is enabled automatically when booting via UEFI, seem to have issues working together: PR 194112, PR 193770.



The problem there is the efifb framebuffer console driver. Roughly UEFI does not define a specific type of text mode, it's based on hardware capabilities provided by video card firmware. If the video card firmware is a VBIOS, UEFI makes a legacy VESA framebuffer and uses it for framebuffer console modes, or uses the legacy EGA/VGA 80*25 text mode (using the same methods as BIOS). If the video card has a UEFI/EFI firmware, UEFI uses UEFI-GOP, and firmware puts the text as is (like a serial terminal), directly into the video card, and the video card shows a framebuffer console by its own way, not necessarily VESA modes. Sometimes using native 2D capabilities (like Apple's) and a variety of fonts, others using linear framebuffer modes, even worse than VESA modes. This UEFI GOP has a minimal feature set, I don't know exactly how it is, but is supposed that *.efi executables can detect them, but it seems that loader(8) is not doing it well. Besides, probably, nor Nvidia kmod nor radeon are prepared to pass from efifb to its own fb using legacy modes, and the UEFI-GOP situation might be even worse, because every manufacturer has its own firmware configurations.


----------



## Chris_H (Nov 18, 2014)

Greetings,

While I haven't _yet_ used UEFI. I _do_ use the various nVidia blobs on all the servers I maintain. FWIW I have found that vt(4), while _should_ be a really nice addition. Hasn't quite been kicked around the block enough. So it's caused me to have to shy away for awhile, on the nVidia blobs, at least. I have found that the sc(4) terminal still works fairly well. Things I've found I needed to do:
loader.conf(5)

```
kern.vty=sc
#kern.msgbufsize=98304
linux_load="YES"
nvidia_load="YES"
```
Now not having yet used UEFI, and knowing that it sets up its own environment. I don't know that any of that will help. But it might be possible to import some of those into that environment. Specifically; where the kern.vty is concerned. Also possibly the kern.msgbufsize
Just a thought.

--Chris


----------

