nvidia-modeset problems at boot

complexnumber

complexnumber

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

Code: 
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.
 
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.
 
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"
 
FreeBSD bug 255073 – boot (UEFI): loader: copy_staging: no progress beyond EFI framebuffer information

complexnumber said:
13.0-RELEASE
Click to expand...

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.
 
Last edited:
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.
 
grahamperrin said:
install FreeBSD 13.0-STABLE with a similar understanding, but there's greater support
Click to expand...
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.
 
SirDice FYI <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255073#h19> ▶
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
 
Last edited:
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.
 
(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?).
Click to expand...

All indications are that it is fixed. Simply not yet released. PS:
<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:
– 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.
 
Last edited:
You must log in or register to reply here.
Back
Top