kld_list="i915kms" does not stick on /etc/rc.conf at all.

I'm looking at this post for cross-reference. You have several syntax problems in your configuration files. I can help with some of these problems - maybe not all, but at least some of them.
  1. In /etc/sysctl.conf delete the line that says kld_list="i915kms" and add the lines net.link.tap.up_on_open=1 and net.inet.ip.forwarding=1
  2. In /etc/rc.conf keep the line kld_list="i915kms"[/cmd] - this is the correct file for this line.
  3. In /boot/loader.conf change fuse_load="YES" to fusefs_load="YES"
  4. In /boot/loader.conf delete the lines net.link.tap.up_on_open: 1 -> 1 and net.inet.ip.forwarding: 1 -> 1
Then reboot and see if that helps.
 
1) SirDice told me to remove net.inet.ip.forwarding=1 from /etc/sysctl.conf and I haven't the parameter kld_list="i915kms" there. it was a typo.

2) ok

3) in my case on /boot/loader.conf fuse_load="YES" works great

4) in /boot/loader.conf I haven't any net.* and so on. It was a typo. sorry for these typos.

as a result the problem persists.
 
I consolidated my post in that thread, where he does have his /etc/rc.conf posted.
He states above that his post in that thread contains typos. Frankly I'm more than a little bit baffled; perhaps things work differently on his arm64 system than they do on my amd64 system? For example, I can no longer use fuse_load="YES" and for some time now have had to use fusefs_load="YES" instead.

Edited to add reference: https://forums.freebsd.org/threads/how-do-i-load-fuse-properly-and-persistently.79738/
 
He's got more than typos going on in his /etc/rc.conf, but I wasn't aware til you mentioned it that it was an arm64 system.
 
He's got more than typos going on in his /etc/rc.conf, but I wasn't aware til you mentioned it that it was an arm64 system.
He stated previously he's running arm64 on a Jetson Nano. I'm unfamiliar with arm64 and starting to think that, without doing more research, might not be knowledgeable enough to troubleshoot.
 
In the recent past I made two kinds of questions. The first one is related to arm64 and the second one to amd64. I've been able to emulate freebsd arm64 on the jetson nano,even if not totally. Xorg and the desktop manager don't work,but I have configured X + ssh forwarding and I can run the Freebsd applications that need the graphical interface on the host system,even the whole desktop manager can be forwarded as u know. At the moment I have some problems to configure correctly Freebsd on amd64. Two problems. The first one is that kld_list="i915kms" seem to be not recognized by the rc.conf file and Xorg does not work if I don't write kldload i915kms before to write "startx" ; and the second one is related to Linux emulated with bhyve (without vm-bhyve) ; in short terms Linux can't connect to internet. It worked for sometime when SirDice suggested to remove the line "net.inet.ip.forwarding=1" from the file /etc/sysctl.conf and to add "gateway_enable="YES" to /etc/rc.conf ; but when I have rebooted,the problem comes out again. This is the rc.conf file that works (except for the ntpd ; the i915kms problem and the linux / bhyve problems)

/etc/rc.conf

sendmail_enable="NO"
hostname="marietto"
keymap="it.kbd"
ifconfig_em0="DHCP"
local_unbound_enable="YES"
sshd_enable="YES"
moused_enable="YES"
ntpdate_enable="YES"
ntpd_enable="YES"
powerd_enable="YES"
dumpdev="AUTO"
dbus_enable="YES"
hald_enable="YES"
slim_enable="YES"
sound_load="YES"
snd_hda_load="YES"
kld_list="i915kms"
libvirt_enable="YES"
linux_enable="YES"
zfs_enable="YES"
linux_mounts_enable="YES"
gateway_enable="YES"

/etc/sysctl.conf :

net.link.tap.up_on_open=1

/boot/loader.conf

vmm_load="YES"
nmdm_load="YES"
if_tap_load="YES"
if_bridge_load="YES"
fuse_load="YES"


/etc/resolv.conf
search homenet.telecomitalia.it
#nameserver 192.168.1.1
nameserver 127.0.0.1
options edns0

I've fixed the ntpd problem removing my lines and adding these :

ntpd_enable="YES"
ntpd_sync_on_start="YES"

I can start Xorg by writing kldload i915kms before to write "startx" ; but it's annoying ; the linux / bhyve problem is unresolved.
 
Much of this is beyond my experience. I would try running dmesg -a > dmesg.txt as root and then search the text file dmesg.txt for some indication of why the system fails to load i915kms.ko - your /etc/rc.conf looks okay to me as far as I can see. Thanks.
 
Could you please also post output of pciconf -lv > pciconf.txt and /var/log/Xorg.0.log, and also /var/log/Xorg.1.log if that file exists? Thanks.
 
-snip-

... You might find that the start of SLiM will trigger a load of the Intel-specific module.
His system is starting lightdm at line 395 in his dmesg.txt log / Pastebin link, but for some reason I don't see lightdm_enable="YES" in his /etc/rc.conf file?

Please notice that everything in dmesg.txt after line 400 happens after lightdm starts, and everything before line 401 does not.

Edited to add:

@ grahamperrin - My amd64 13.0-RELEASE-p3 system has /boot/modules/fusefs.ko but does not have fuse.ko anywhere. Very strange.

@ ziomario - You might benefit from freebsd-update fetch && freebsd-update install
 
I'm using kld_list="zfs i915kms" in /etc/rc.conf and it works fine! So it is supposed to work for him as well. Since it works to load the module manually.
Though I boot that laptop using GRUB, not UEFI (old model there). And I don't boot into X directly but start X after login. But yes, in the middle of the booting process i915kms is loaded and fb is started (shows up in the boot message feed).
 
Unfortunately these parameters don't fix the problem : xorg starts only loading the i915kms driver manually.

hostname="marietto"
keymap="it.kbd"
ifconfig_em0="DHCP"
local_unbound_enable="YES"
sshd_enable="YES"
powerd_enable="YES"
ntpdate_enable="YES"
ntpd_enable="YES"
ntpd_sync_on_start="YES"
dumpdev="NO"
dbus_enable="YES"
#hald_enable="YES"
slim_enable="YES"
sound_load="YES"
snd_hda_load="YES"
#kld_list="i915kms"
kld_list="drm"
#moused_enable="YES"
libvirt_enable="YES"
linux_enable="YES"
#zfs_enable="YES"
linux_mounts_enable="YES"
gateway_enable="YES"
kld_list="fusefs"
vm_enable="YES"
vm_dir="/vms/os/linux"
lightdm_enable="YES"
sendmail_enable="NO"
microcode_update_enable="YES"

pciconf -lv > pciconf.txt ---> https://pastebin.ubuntu.com/p/swthzwFCrB/
var/log/Xorg.0.log ---> https://pastebin.ubuntu.com/p/CMJyTStn7F/
/var/log/Xorg.1.log = 1
 
#kld_list="i915kms"
kld_list="drm"
[...]
kld_list="fusefs"
You have a lot in there so it is hard to notice but can you see you set kld_list twice? The second one replaces the original one.

So make sure you only have *one* kld_list line:

Code:
kld_list="fusefs i915kms"

Note, I am not sure what the drm module is. None of the docs mention it so I am inclined to believe it is a typo.
 
You have a lot in there so it is hard to notice but can you see you set kld_list twice? The second one replaces the original one.

So make sure you only have *one* kld_list line:

Code:
kld_list="fusefs i915kms"

Note, I am not sure what the drm module is. None of the docs mention it so I am inclined to believe it is a typo.
My system has /boot/kernel/drm.ko which I believe probably comes from the drm-kmod port.

Good spotting - you're right, there must be only one kld_list statement in /etc/rc.conf, thanks.
 
According to pciconf -lv output, and this thread: Thread no-devices-detected.80899, OP has a built-in "Intel Corporation CoffeeLake-S GT2 [UHD Graphics 630] (rev 02)" onboard video controller, but, in June, was trying to configure it to work with an NVIDEA card, and installed this proprietary closed-source Nvidia driver, which, according to SirDice in this post, may have overwritten some of the xorg libraries.

I recommend that ziomario should:
  1. Double-check his BIOS setting to make sure that it is NOT using the Nvidia setting, and IS using the Intel setting.
  2. Re-install the xorg libraries.
I'm not at all sure how complicated reinstalling the xorg libraries might be. It might be as simple as pkg install -f xorg but then again, it might be as complicated as:
pkg delete xorg
pkg autoremove
pkg install xorg

The way I normally do things, I would probably do a complete reinstall of the system, just to be sure I had removed all traces of the NIVIDEA configuration, but that might not be the best option for OP - it's his decision whether or not he might want to do that. First I would probably try the less drastic pkg install -f xorg just to see if it worked.
 
I have to set this one to "Discreet" in the BIOS to get it to use Nivida on Optimus. Intel would be the other choice for a set driver on mine.

And I don't boot into X directly but start X after login
I always use startx, too.
 
When you type df -g on the command line, is there anything particular about the partition that holds the directory /etc or /?
 
From <https://forums.FreeBSD.org/threads/81340/post-524303> under another post, I assume that it's FreeBSD 13.0-RELEASE-p3 in this post.

zfs_enable="YES"

This is correct. From rc.conf(5):

Code:
     zfs_enable  (bool) If set to “YES”, /etc/rc.d/zfs will attempt to
                 automatically mount ZFS file systems and initialize ZFS
                 volumes (ZVOLs).

kld_list="zfs i915kms"

It's unusual to have zfs in that context (instead of zfs_enable), any special reason?

Code:
     kld_list    (str) A whitespace-separated list of kernel modules to load
                 right after the local disks are mounted, without any .ko
                 extension or path.  Loading modules at this point in the boot
                 process is much faster than doing it via /boot/loader.conf
                 for those modules not necessary for mounting local disks.
 
My system has /boot/kernel/drm.ko which I believe probably comes from the drm-kmod port.

Not directly.

For your AMD64 13.0-RELEASE-p3:

<https://cgit.freebsd.org/ports/tree...d=a7c4491bdcd6398146b8c05a361f02c6ac93c5c7#n2>

Here:

Code:
% uname -KorU
FreeBSD 14.0-CURRENT 1400026 1400026
% file /boot/kernel/drm.ko
/boot/kernel/drm.ko: cannot open `/boot/kernel/drm.ko' (No such file or directory)
% pkg provides boot/kernel/drm.ko
% pkg provides drm.ko
Name    : drm-devel-kmod-5.5.19.g20210709
Desc    : DRM modules for the linuxkpi-based KMS components (development version)
Repo    : FreeBSD
Filename: boot/modules/drm.ko

Name    : drm-current-kmod-5.4.92.g20210526
Desc    : DRM modules for the linuxkpi-based KMS components
Repo    : FreeBSD
Filename: boot/modules/drm.ko
%

Note to self:

Code:
% pkg query '%o %v %R' drm-current-kmod
graphics/drm-current-kmod 5.4.92.g20210526 FreeBSD
%

– more properly, I should have built and installed the module when I built the system. I'll build the module now.
 
Back
Top