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

grahamperrin said:
Not a typo. Intentional.
Click to expand...
Does just drm work on your machine rather than i915kms?

I suspect drm.ko is a dependency of i915kms.ko and gets automatically added. However the reverse is not true and i915kms *still* needs to be there explicitly.

The Linux kpi stuff has weak documentation. I don't suppose you can point towards anything?
 
kpedersen said:
Does just drm work on your machine
Click to expand...

Yes.

With FreeBSD 14.0-CURRENT on an HP EliteBook 8570p, necessarily ignoring the recommendation to specify radeonkms:

Code: 
% sysrc kld_list sddm_enable
kld_list: fusefs usbhid drm
sddm_enable: YES
%

Result:

Code: 
% kldstat | grep -i radeon
58    1 0xffffffff83c44000   150c80 radeonkms.ko
60    1 0xffffffff83da4000     3258 radeon_TURKS_pfp_bin.ko
61    1 0xffffffff83da8000     3658 radeon_TURKS_me_bin.ko
62    1 0xffffffff83dac000     2cd8 radeon_BTC_rlc_bin.ko
63    1 0xffffffff83daf000     7ef8 radeon_TURKS_mc_bin.ko
64    1 0xffffffff83db7000     8138 radeon_TURKS_smc_bin.ko
65    1 0xffffffff83dc0000    341f0 radeon_SUMO_uvd_bin.ko
%

kpedersen said:
… and i915kms *still* needs to be there explicitly. …
Click to expand...

Yes and no.

With FreeBSD 14.0-CURRENT on an HP ZBook 17 G2:

Code: 
% sysrc kld_list sddm_enable
kld_list: drm
sddm_enable: YES
%

Result: SDDM starts, albeit not at the resolution that's proper for the display. It does not tolerate a subsequent load of i915kms …

… however for now, for the purpose of diagnosing things for ziomario I'll be interested to know whether LightDM or SLiM – whatever is in his rc.conf at the time – can start automatically (compared to the opening post).
 
no. with LightDM or Slim declared as YES on the rc.conf file xorg does not start automatically. You gave me the idea to disable them and let's see if I have to load the i915kms driver manually or not this time.

UPDATE : with these changes,the problem is still present :


slim_enable="NO"
kld_list="i915kms"
lightdm_enable="NO"

Actually I launch Xorg invoking this little sh script :

i915.sh

kldload i915kms
startx
Click to expand...

the previous installation of FreeBSD was done with GRUB and I didn't see this problem. Now I'm using EFI and I see it. Maybe this is the reason...
 
According to both your dmesg log and your Xorg.0.log, your system detects 3 video devices, which seems to cause the system some confusion and conflict. You can see this in the dmesg log at lines 73, 82, and 84:
Code: 
73 vgapci0: <VGA-compatible display> port 0x4000-0x407f mem 0x96000000-0x96ffffff,0x60000000-0x6fffffff,0x94000000-0x95ffffff irq 16 at device 0.0 on pci1
74 hdac0: <NVIDIA (0x10f7) HDA Controller> mem 0x97080000-0x97083fff irq 17 at device 0.1 on pci1
...
82 vgapci1: <VGA-compatible display> port 0x3000-0x307f mem 0x92000000-0x92ffffff,0x80000000-0x8fffffff,0x90000000-0x91ffffff irq 17 at device 0.0 on pci2
83 hdac1: <NVIDIA (0x10f1) HDA Controller> mem 0x93080000-0x93083fff irq 18 at device 0.1 on pci2
84 vgapci2: <VGA-compatible display> port 0x5000-0x503f mem 0x98000000-0x98ffffff,0x40000000-0x5fffffff irq 16 at device 2.0 on pci0
85 vgapci2: Boot video device
... and in Xorg.0.log at lines 43 through 47:
Code: 
43 [   122.262] (!!) More than one possible primary device found
44 [   122.262] (!!) More than one possible primary device found
45 [   122.262] (--) PCI:*(0@0:2:0) 8086:3e98:1458:d000 rev 2, Mem @ 0x98000000/16777216, 0x40000000/536870912, I/O @ 0x00005000/64, BIOS @ 0x????????/65536
46 [   122.262] (--) PCI: (1@0:0:0) 10de:1e04:19da:2503 rev 161, Mem @ 0x96000000/16777216, 0x60000000/268435456, 0x94000000/33554432, I/O @ 0x00004000/128, BIOS @ 0x????????/65536
47 [   122.262] (--) PCI: (2@0:0:0) 10de:1c02:19da:2438 rev 161, Mem @ 0x92000000/16777216, 0x80000000/268435456, 0x90000000/33554432, I/O @ 0x00003000/128, BIOS @ 0x????????/65536
For comparison, my system only detects 1 video device, which dmesg reports as vgapci0.

My system uses the radeon video driver, from installed software xf86-video-ati, along with the radeonkms.ko kernel modesetting module, from installed software drm.kmod.

Your system is trying to use the intel video driver along with the i915kms.ko kernel modesetting module, but the intel driver is failing to load, which you can see in Xorg.0.log at lines 58 through 60:
Code: 
58 [   122.263] (II) LoadModule: "intel"
59 [   122.263] (WW) Warning, couldn't open module intel
60 [   122.263] (EE) Failed to load module "intel" (module does not exist, 0)
I don't know exactly why this is failing. Your Xorg.log.0 appears to use modeset(0) (vgapci2) as its primary device, whereas mine uses RADEON(0) (vgapci0) as its primary device.

My system has an external monitor attached, which it configures as VGA-0, but I can find no similar external device configuration in your logs. My primary

Maybe someone using the intel driver can provide a better analysis by comparing your logs with their own system logs.
 
ziomario said:
Hello.

I've added this parameter to /etc/rc.conf :

kld_list="i915kms"

adding it on the rc.conf file should make the setting permanently,right ? But why,everytime I reboot the PC and I come back to FreeBSD,I should write "kldload i915kms",otherwise Xorg does not start,causing the error "cannot run in framebuffer mode. Please specify busIDs" ?
Click to expand...
for use intel driver you need install... kms pakage first... and make sure your graphic driver is intel not nvidia... or another
 
ziomario said:
Hello.

I've added this parameter to /etc/rc.conf :

kld_list="i915kms"

adding it on the rc.conf file should make the setting permanently,right ? But why,everytime I reboot the PC and I come back to FreeBSD,I should write "kldload i915kms",otherwise Xorg does not start,causing the error "cannot run in framebuffer mode. Please specify busIDs" ?
Click to expand...
Would the following in /etc/rc.conf be any help?
kld_list="boot/modules/i915kms.ko"
I was told that sometimes freebsd requires the full path for i915kms.
 
orhankur said:
I was told that sometimes freebsd requires the full path for i915kms.
Click to expand...
Only on 11.x and 12.x because there's an existing module that comes with the OS. On 13.x and higher this isn't needed because the old i915kms driver that came with FreeBSD was removed. So there's no ambiguity anymore.
 
grahamperrin said:
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.



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).



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.
Click to expand...
Well, as I read in your own quotation of man, zfs_enable "will attempt to automatically mount" ZFS filesystems. That is, I suppose, such ZFS filesystems that are set to mount automatically (zfs setting canmount=auto + have mountpoint other than legacy), right?. Mine, however, are all of legacy type, get mounted via /etc/fstab, so, this won't work. the module has to be preloaded, unless I'm very much mistaken.

Additionally, zfs.ko module must be loaded anyway. Now UEFI or other type of FreeBSD loader reads info about loaded modules from /boot/loader.conf. But since my system boots via GRUB (old laptop + dual-boot with other OSs), it doesn't know how to use that file (and GRUB cannot boot /boot/loader any more). However, booting modules via GRUB command line (i.e., kFreeBSD_module_elf /boot/modules/zfs.ko ) doesn't work well with all modules. Then again, with zfs.ko NOT loaded at boot time, zfs_eanble cannot possibly work at all.

And in particular, i915kms.ko ONLY works (last revisions, at least) when loaded using kld_list option in /etc/rc.conf. And, into the bargain, saves GRUB command line typing trouble :))). I assume it to be good style to keep grub.cfg as short as possible where native OS mechanisms can be safely used instead.
 
grahamperrin said:
Some misunderstanding, see for example:
Click to expand...
Hm? How about Topics about unsupported FreeBSD versions? It says:
Click to expand...
 
grahamperrin said:
That was my experience, a few weeks ago. A few weeks previously someone found otherwise.
Click to expand...
I can safely confirm that this thing started precisely when 13.0 changed its status from CURRENT to RC. I had no reason to switch over to 14.0-CURRENT on my laptop, so I stuck with 13.0...
But then, the latest dev version of i915kms kmod I had used successfully (without kld_list stuff) could not be used with an RC release. It failed to build and urged me to switch over to older version or to use CURRENT.
And the older version only works though kld_list.
Can't say I'm any worse for the change, though -- in fact, it is even more neat that way, excluding module loading from grub.cfg.??
...So, I guess, whoever "found it otherwise" is using CURRENT -- and the latest dev version of i915kms kmod.
 
FWIW I've been using 13.0-RELEASE using drm-kmod, from quarterly packages only, since Q2, and it unfailingly loads drm.ko automatically as soon as I start X. I'm presently on 13.0-RELEASE-p3 and Q3 quarterly packages. This has been its consistent behavior since April if I leave kld_list empty. I've made this point repeatedly several times since then, in several different threads.

On my Lenovo laptop with Radeon graphics, it also automatically loads radeonkms.ko after loading drm.ko.

On my HP Stream laptop with Intel graphics, it automatically loads i915kms.ko instead of the Radeon graphics modules.

I'm guessing that the x11/xorg package is doing this automatically whenever X starts, because these modules don't get loaded until the moment I start X, either with startx, or by starting the x11/lightdm display manager.
 
Vull said:
FWIW I've been using 13.0-RELEASE using drm-kmod, from quarterly packages only, since Q2, and it unfailingly loads drm.ko automatically as soon as I start X. I'm presently on 13.0-RELEASE-p3 and Q3 quarterly packages. This has been its consistent behavior since April if I leave kld_list empty. I've made this point repeatedly several times since then, in several different threads.

On my Lenovo laptop with Radeon graphics, it also automatically loads radeonkms.ko after loading drm.ko.

On my HP Stream laptop with Intel graphics, it automatically loads i915kms.ko instead of the Radeon graphics modules.

I'm guessing that the x11/xorg package is doing this automatically whenever X starts, because these modules don't get loaded until the moment I start X, either with startx, or by starting the x11/lightdm display manager.
Click to expand...
Glad for you, really :)
And what I am NOT glad about is the fact that it works this way for you but does NOT work for me. Or do you have any "magic" settings that make this happen? C'mon, don't keep it secret from us friends here ;)

I mean, you're telling me that it "just works". And I have to reply that it doesn't. And I believe there MUST be a cause for the former and the latter.
Would be interesting to know how this is done.
 
free-and-bsd said:
Glad for you, really :)
And what I am NOT glad about is the fact that it works this way for you but does NOT work for me. Or do you have any "magic" settings that make this happen? C'mon, don't keep it secret from us friends here ;)

I mean, you're telling me that it "just works". And I have to reply that it doesn't. And I believe there MUST be a cause for the former and the latter.
Would be interesting to know how this is done.
Click to expand...
No magic settings, just plain vanilla configurations built from packages and the FreeBSD-13.0-RELEASE-amd64-memstick.img installer. Software configurations are as simple and straightforward as I can make them. Maybe it's specific to the hardware, I don't know, but maybe I finally just got lucky with my cheap hardware purchases. Lenovo G50-45 laptop and HP Stream 11-d010wm. I was not so lucky with my Acer Aspire a few years ago, and the HP Stream still has plenty of hardware glitches including an unsupported Realtek wifi chip. Two or three cheap laptops is not a statistically significant sample size but that's what I've got.

It's not really such a big deal is it? Would I sleep any better or worse if I had to put one extra token in my kld_list? I don't think so.
 
In another thread, there is some information from the OP that may change some of this.
The system in question, dmesg shows 3 vgapci devices, vgapci0 and vgapci1 being NVIDIA, vgapci2 being i915. BIOS setting is
such that the i915 is the default boot device but that does not explicitly disable the other 2 (pciconf -l and dmesg | grep vga shows 3 devices).
It is likely that having these three devices visible to the kernel is affecting the kldload i915 somehow.
 
I can't disable the nvidia graphic cards,because my next goal is to try to passtrough one of them or both in the bhyve virtual machine.
 
  • Like
Reactions: mer
Vull said:
... Maybe it's specific to the hardware, I don't know, but maybe I finally just got lucky with my cheap hardware purchases. ...
Click to expand...
It is this maybe which is killing me. OS and its components MUST NOT make any such difference.
It must be as simple as "I know this hardware, here is the driver for it. Let's load it then".
Vull said:
It's not really such a big deal is it?
Click to expand...
Not for YOU, I guess :D...
But generally, yes it is. Software can hardly be considered 100% stable and reliable if its behaviour becomes unpredictable.
If, on the other hand, this is KNOWN behaviour, why is it not documented?
 
free-and-bsd said:
It is this maybe which is killing me. OS and its components MUST NOT make any such difference.
It must be as simple as "I know this hardware, here is the driver for it. Let's load it then".

Not for YOU, I guess :D...
But generally, yes it is. Software can hardly be considered 100% stable and reliable if its behaviour becomes unpredictable.
If, on the other hand, this is KNOWN behaviour, why is it not documented?
Click to expand...
Did not mean to be dismissive of your pain. :D My machines have only one graphics device each, so that no doubt simplifies the problem for the software. Also I'm starting to guess that it might very well have something to do with:

xf86-video-intel -> i915kms.ko
xf86-video-ati -> radeonkms.ko
 
Vull said:
Did not mean to be dismissive of your pain. :D
Click to expand...
MY pain?? You must be kidding :D
OK, let me be more explicit. When you launch X, you can see in your Xorg.0.log something like this:
Code: 
[    73.968] (II) NVIDIA dlloader X Driver  390.143  Fri Mar 12 07:22:21 UTC 2021
[    73.968] (II) NVIDIA Unified Driver for all Supported NVIDIA GPUs
............
Formerly it would give off a full list of GPUs... So, do you see any reason why Xorg software should make difference and recognize automatically some of them but not others?

This isn't my pain at all, but a suggested behaviour of software.
What is the big deal, as you say?
OK, this very forum is one illustration. The OP friend here is in trouble and doesn't know what to think of his system which doesn't behave in a documented way. Now, we who have some experience tell him this and that.
Now if we CAN BE SURE about things, how much trouble would it save us and him? But if, on the other hand, it is like "oh, I don't know... it works fine for me, but have no idea why it doesn't for you..." That isn't very reassuring, you know ;) ;) ;)
 
free-and-bsd said:
MY pain?? You must be kidding :D
OK, let me be more explicit. When you launch X, you can see in your Xorg.0.log something like this:
Code: 
[    73.968] (II) NVIDIA dlloader X Driver  390.143  Fri Mar 12 07:22:21 UTC 2021
[    73.968] (II) NVIDIA Unified Driver for all Supported NVIDIA GPUs
............
Formerly it would give off a full list of GPUs... So, do you see any reason why Xorg software should make difference and recognize automatically some of them but not others?

This isn't my pain at all, but a suggested behaviour of software.
What is the big deal, as you say?
OK, this very forum is one illustration. The OP friend here is in trouble and doesn't know what to think of his system which doesn't behave in a documented way. Now, we who have some experience tell him this and that.
Now if we CAN BE SURE about things, how much trouble would it save us and him? But if, on the other hand, it is like "oh, I don't know... it works fine for me, but have no idea why it doesn't for you..." That isn't very reassuring, you know ;) ;) ;)
Click to expand...
I feel his pain too. Been there, done that. Wish I knew why software is still in its infancy after all of these decades of bitter struggle, disillusionment, and broken standards, but I don't. Skynet? The goddamn robots? "It's all about the money?" *sigh*
 
You must log in or register to reply here.
Back
Top