# nvidia-modeset problems at boot



## complexnumber (Jan 3, 2022)

Hi,

I am running FreeBSD 13.0-RELEASE on an AMD64 system. The Machine is an MSI GF63-Thin-8RCS laptop and has dual graphics, an intel GPU and an Nvidia GTX1050 mobile GPU.

I've been following the instructions online and I have the following in my /boot/loader.conf


```
security.bsd.allow_destructive_dtrace=0
kern.vty=vt
cuse_load="YES"
nvidia-modeset_load="YES"
```

When I boot my machine, I get the following;

Photo_1

photo_2

I've been using FreeBSD for awhile but have never had this issue before.


----------



## SirDice (Jan 3, 2022)

The efi framebuffer still has issues sometimes. Try a CSM boot, see if that works better.

You can remove the `kern.vty=vt`, it's the default. No need to explicitly set this.


----------



## mer (Jan 3, 2022)

Remove the nvidia-modeset line from loader.conf and put the following in /etc/rc.conf:
kld_list="/boot/modules/nvidia-modeset.ko /boot/modules/nvidia.ko"


----------



## grahamperrin@ (Jan 3, 2022)

FreeBSD bug 255073 – boot (UEFI): loader: copy_staging: no progress beyond EFI framebuffer information



complexnumber said:


> 13.0-RELEASE



complexnumber hi, the title of the bug report describes what's in your second photograph.

Attention to graphics might be a waste of time if (unrelated to graphics) FreeBSD 13.0-RELEASE simply _can not boot_ computers such as yours.

Short story (without wading through the various bug reports): a fix for 255073, and other bugs, is in the pipeline but not yet _released_. Affected users have the following choices:

install FreeBSD 14.0-CURRENT with the understanding that it's not supported (in the usual way) and with readiness to build the operating sytem from source whenever an update is appropriate or required
install FreeBSD 13.0-STABLE with a similar understanding, but there's greater support
await FreeBSD 13.1-RELEASE.
<https://forums.freebsd.org/threads/freebsd-release-engineering.83057/>

Postscript

Please see below, it seems that I drew a false conclusion. Sorry.


----------



## SirDice (Jan 3, 2022)

EFI framebuffer borks on 14-CURRENT on my system. No luck on 13.0-RELEASE or 13-STABLE either. While it doesn't _show_ anything on the console, it does boot. And once X is loaded (and x11/nvidia-driver is active) the system works just fine. I can even CTRL-ALT-F1..F8 back to the console. CSM boot works as expected. Screen is readable during boot and on the console. The only thing that doesn't work correctly is the EFI framebuffer when UEFI booting the machine. I either get no picture at all or the resolution is weird and the screen is garbled.

There's no difference in loading the NVidia driver from loader.conf or rc.conf. Both have the exact same result.


----------



## complexnumber (Jan 3, 2022)

grahamperrin said:


> install FreeBSD 13.0-STABLE with a similar understanding, but there's greater support


I plan on upgrading to 13.0-STABLE. I'm not experienced enough to run CURRENT. I will just use the intel driver which works on my laptop. I have xorg and Xfce4 setup and running with the intel driver. I'm reading Absolute FreeBSD 3rd Edition by Michael Lucas at the moment as well.


----------



## grahamperrin@ (Jan 3, 2022)

SirDice FYI <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255073#h19> ▶

FreeBSD bug 260735 – 1b33aa1f5f99e1270d526ffa5b652250ec80a7ef (amd64 UEFI loader: stop copying staging area to 2M physical) maybe not effective in some cases Video/graphics: no visible progress beyond EFI framebuffer information (non-related to the 2M staging copy bug)
Speed-reading your post #5 here, I wonder whether your case falls under the umbrella of 260735.

Whilst I _do_ lean towards Ed Maste's analysis at the foot of his comment 3, I have not yet edited the summary line of the report, which currently includes the Git hash of the commit relating to _2M staging copy_.

Do you agree that 260735 is the umbrella for yours?

If it becomes _certain_ that 260735 is non-related to `1b33aa1f5f99e1270d526ffa5b652250ec80a7ef`, I can de-link things and make the summary line more self-explanatory.

Thanks


----------



## SirDice (Jan 3, 2022)

Booting works. I used CSM boot to install an initial system. Updated the sources, built everything, etc. Then set up EUFI boot (with rEFInd) to use the already existing Windows EFI partition. Besides the issues with the EFI framebuffer the system boots just fine. On the loader prompt I can `gop mode 0` and the resolution does switch to 2560x1440 but the image is "squashed" vertically, it only uses about half of the screen. Continue booting would then show _some_ readable text but there's something off about the size calculation, it now looks 'stretched' (about twice the screen size and it looks "rasterized"). Using any of the other resolutions like 1920x1080 has similar results, so I've settled for no picture during boot at all.

Like I said, once SLiM loads and X kicks in everything returns to normal. Even switching back and forth between the console and X works (in both UEFI and CSM boot cases), which is known to not work with the NVidia driver on a lot of systems.

To help the OP, I would suggest trying a CSM boot, see if that works. If you get a good console picture then use that to install an initial system. If you go with the automatic ZFS install there is an option to install _both_ EUFI and BIOS boots. Make sure to pick that. Then you can easily switch back and forth between CSM and UEFI boot as the system will be capable of booting both ways.


----------



## complexnumber (Jan 6, 2022)

SirDice said:


> I would suggest trying a CSM boot, see if that works.


I tried CSM boot and same thing. I'll wait for 13.1-RELEASE


----------



## shkhln (Jan 7, 2022)

complexnumber said:


> photo_2


This is a pesky issue (https://github.com/freebsd/freebsd-src/commit/94e8f7c65f1580210bb4e95738fe72c3ddc7eb1e, https://github.com/freebsd/freebsd-src/commit/4d6047edb675e52b8fad57135ab3ded8e66d0dac) FreeBSD devs didn't manage to fix (yet?). This is easy to avoid by moving nvidia-modeset into kld_list in /etc/rc.conf just like the installation message for the driver package suggests.

(CSM boot also works if you do it _properly_.)


----------



## SirDice (Jan 7, 2022)

complexnumber said:


> I tried CSM boot and same thing.


It can't be the same thing. CSM boot doesn't use the EFI framebuffer, so you can't get an EFI framebuffer related issue.


----------



## grahamperrin@ (Jan 8, 2022)

> (photo_2) … (https://github.com/freebsd/freebsd-src/commit/94e8f7c65f1580210bb4e95738fe72c3ddc7eb1e, https://github.com/freebsd/freebsd-src/commit/4d6047edb675e52b8fad57135ab3ded8e66d0dac) FreeBSD devs didn't manage to fix (yet?).



All indications are that it _is_ fixed. Simply not yet released. *PS*:

I mean, the fix in stable/13 (not in 13.0-RELEASE) for what's pictured at <https://bz-attachments.freebsd.org/attachment.cgi?id=224721> _boot (UEFI): loader: copy_staging: no progress beyond EFI framebuffer information_
<https://forums.freebsd.org/posts/549867> includes a cropped view of the `photo_2` that was provided by complexnumber –_no progress beyond EFI framebuffer information_. *PS*: 

until yesterday, I associated the _no progress_ symptom solely with bug 255073 (now a duplicate of fixed 209821)
now I might better understand that the symptom can also/alternatively occur with 13.0-RELEASE with *a different bug*.
I don't understand how a graphics-related change, alone, can work around a what might be a bug that is *not* related to graphics.

<https://cgit.freebsd.org/src/commit/?id=94e8f7c65f1580210bb4e95738fe72c3ddc7eb1e> was committed in 2019. Released.

<https://cgit.freebsd.org/src/commit/?id=4d6047edb675e52b8fad57135ab3ded8e66d0dac> was committed in 2020. Released, and:

for _VMware_ (virtualised, not physical hardware).
Related:

FreeBSD bug 251866 – Because the loader.efi modified the size of EFI_STAGING_SIZE, vmware could not start the system above FreeBSD 12.2
– whilst there _is_ a mention of NVIDIA (hardware), and my own hardware case (not NVIDIA) was initially steered to VMware-oriented bug 251866, (comment 30) Warner Losh was wary of conflation. So (comment 31) we *separated the hardware cases from the VMware-oriented bug*.


----------



## grahamperrin@ (Jan 9, 2022)

The FreeBSD Handbook, and package messages

FreeBSD bug 258264 – Following handbook on nvidia drivers makes system get stuck on boot.


----------

