Solved SLiM startup very slow

Monti · Oct 25, 2015

Hi,

I have installed x11/mate-desktop and x11/slim with FreeBSD 10.2 and 10.1 on two different computers and experience that SLiM is starting up very slow with both installations. Meaning the screen is black for a long time before login manager appears. Is it possible to change this?

The configuration is:

/etc/rc.conf :

Code:

dbus_enable="YES"
hald_enable="YES"
slim_enable="YES"
avahi_daemon_enable="NO"
avahi_dnsconfd_enable="NO"

~/.xinitrc

Code:

exec mate-session

Last. I have read that it is not possible to use /etc/ttys anymore with the current NVIDIA drivers. Is this true?

I do not use any xorg.conf file like /usr/local/etc/X11/xorg.conf or /etc/X11/xorg.conf

Thanks.

sidetone · Oct 25, 2015

.xinitrc needs

Code:

#!/bin/sh

at the beginning, and

Code:

exec $1

at the end of the file.
Another way to choose the window manager is to make a *.desktop files in /usr/local/share/xsessions/

Code:

[Desktop Entry]
Name=ANYNAME
Exec=sessionmanagercommand

It looks like it spends time searching, because it's not set up properly, but it just has enough to start it.

Monti · Oct 26, 2015

Thanks a lot for your reply sidetone . I really appreciate the additional configuration lines and the info about *.desktop. The additional lines in ~/.xinitrc are entered

I'm not sure if I'm understanding you correctly, or if you misunderstood my text, but regarding very slow x11/slim startup it is happening before the x11/slim login dialog. I'm under the impression that ~/.xinitrc is initialized after login credentials are entered, and that the, in my case, slow SLiM startup is initialized by the slim_enable="YES" in /etc/rc.conf . To be sure I rebooted after entering the new lines in ~/.xinitrc to see if x11/slim was still having a slow startup. Which it has.

Thanks.

sidetone · Oct 26, 2015

Sorry, I did misunderstand, you said before, and I was thinking after.

Does the boot up show the loading of configuration? or Is there a pause after it shows the configuration text is shown loading?

It could be how the driver is loaded, ie usually video drivers shouldn't be compiled in the kernel, nor configured in /etc/loader.conf. When it's not compiled in the kernel, nor loaded through loader.conf, FreeBSD automatically loads it without user intervention. kldstat normally tells you which drivers to load through loader.conf, but loading it through loader.conf usually breaks the video drivers' functionality. This wouldn't omit the possibility of a bad video driver, unless it works on other people's FreeBSD installations.

It could a different configuration error. In this case, is there any particular device initialization that pauses, even if other processes move on. It could also be a slim configuration error.

Normally slim is enabled through /etc/ttys instead of /etc/rc.conf, but I noticed you asked if Nvidia is incompatible with it. You can try running it through /etc/ttys instead of /etc/rc.conf to see for yourself. It may take some troubleshooting. If you get stuck, boot into single user mode, and type

Code:

mount -u /

to be able to edit configuration from the console.

Monti · Oct 27, 2015

Again thank you very much sidetone .

I'm now using /etc/ttys and it is working fine

:

Code:

ttyv9   "/usr/local/bin/slim"       xterm   on  secure

slim_enable="YES" line in /etc/rc.conf is removed.

Regarding loading of configuration it seems like everything is just fine where I also can see the /etc/rc.conf lines being initiated. It ends with the terminal login prompt for a few seconds before it automatically goes long time blank before the x11/slim login screen.

I forgot to mention that the long delay before x11/slim login screen also appears when logging out from a user account back to the login screen again.

You mention that it could be how the driver is loaded. Since it behaves the same with two computers where both has NVIDIA drivers maybe there is something to it. One has x11/nvidia-driver-304 and the other x11/nvidia-driver-340 . The difference in behavior is that with the x11/nvidia-driver-304 it is showing a NVIDIA logo screen before it goes blank.

It is interesting to read that usually video drivers shouldn't be compiled in the kernel, and that loading it through loader.conf usually breaks the video drivers' functionality. This is also new to me. I ran kldstat and nvidia.ko is there. It is also showing up in the beginning of bootup. If this is the issue or a part of it, it would have been interesting to know how to have the NVIDIA driver not compiled in the kernel. At the moment /boot/loader.conf and /usr/local/etc/X11/xorg.conf.d/10-nvidia.conf are being used.

/boot/loader.conf :

Code:

nvidia_load="YES"

/usr/local/etc/X11/xorg.conf.d/10-nvidia.conf :

Code:

Section "Device"
    Identifier "NVIDIA Card"
    VendorName "NVIDIA Corporation"
    Driver "nvidia"
EndSection

Thanks

sidetone · Oct 27, 2015

If nvidia.ko is there, it's not compiled in the kernel. Anything compiled in the kernel doesn't show, it would be in kernel.ko. The only way I know how to check if a module is already loaded in the kernel, is to kldload it, and it tells me, it's already loaded in the kernel.

Kernel configuration files are in /usr/src/sys/[architecture]/conf/ . You'd have to copy GENERIC to a custom file to be used. grep -i -n [I]searchstring[/I] [I]path/file[/I] is a quick way to check. It might also work by loading it through the kernel, or through boot.conf.

I understand the problem of the delay before the login screen is still there. You'll have to check your file configuration settings, maybe even /usr/local/etc/slim.conf for hints. Sometimes, one configuration error in a line will cause a problem like that, causing a delay or functionality half of the time. Reinstalling Slim, might fix the problem, for one, it may overwrite some files with the proper content. Someone else may be better able to help propose a solution, or you may just have to keep researching.

tobik@ · Oct 27, 2015

Monti said:
I forgot to mention that the long delay before x11/slim login screen also appears when logging out from a user account back to the login screen again.

Do you see anything noteworthy in /var/log/Xorg.0.log?

Monti · Oct 27, 2015

Thank you sidetone for the clarification and additional thoughts. Appreciate it.

And thanks for your reply tobik . I have added the output of var/log/Xorg.0.log below. Please take a look.

Thanks.

Code:

[    14.674] 
X.Org X Server 1.14.7
Release Date: 2014-06-05
[    14.674] X Protocol Version 11, Revision 0
[    14.674] Build Operating System: FreeBSD 10.1-RELEASE-p22 amd64 
[    14.674] Current Operating System: FreeBSD computer 10.2-RELEASE FreeBSD 10.2-RELEASE #0 r286666: Wed Aug 12 15:26:37 UTC 2015     root@releng1.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64
[    14.675] Build Date: 20 October 2015  03:54:14AM
[    14.675]  
[    14.675] Current version of pixman: 0.32.6
[    14.675]     Before reporting problems, check http://wiki.x.org
    to make sure that you have the latest version.
[    14.675] Markers: (--) probed, (**) from config file, (==) default setting,
    (++) from command line, (!!) notice, (II) informational,
    (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[    14.675] (==) Log file: "/var/log/Xorg.0.log", Time: Tue Oct 27 14:02:29 2015
[    14.728] (==) Using config directory: "/usr/local/etc/X11/xorg.conf.d"
[    14.741] (==) No Layout section.  Using the first Screen section.
[    14.741] (==) No screen section available. Using defaults.
[    14.741] (**) |-->Screen "Default Screen Section" (0)
[    14.741] (**) |   |-->Monitor "<default monitor>"
[    14.755] (==) No device specified for screen "Default Screen Section".
    Using the first device section listed.
[    14.755] (**) |   |-->Device "NVIDIA Card"
[    14.755] (==) No monitor specified for screen "Default Screen Section".
    Using a default monitor configuration.
[    14.755] (==) Automatically adding devices
[    14.755] (==) Automatically enabling devices
[    14.755] (==) Not automatically adding GPU devices
[    14.827] (==) FontPath set to:
    /usr/local/share/fonts/misc/,
    /usr/local/share/fonts/TTF/,
    /usr/local/share/fonts/OTF/,
    /usr/local/share/fonts/Type1/,
    /usr/local/share/fonts/100dpi/,
    /usr/local/share/fonts/75dpi/
[    14.827] (==) ModulePath set to "/usr/local/lib/xorg/modules"
[    14.827] (II) The server relies on devd to provide the list of input devices.
    If no devices become available, reconfigure devd or disable AutoAddDevices.
[    14.827] (II) Loader magic: 0x7f9af0
[    14.827] (II) Module ABI versions:
[    14.827]     X.Org ANSI C Emulation: 0.4
[    14.827]     X.Org Video Driver: 14.1
[    14.827]     X.Org XInput driver : 19.1
[    14.827]     X.Org Server Extension : 7.0
[    14.827] (--) PCI:*(0:1:0:0) 10de:0622:1682:2365 rev 161, Mem @ 0xfa000000/16777216, 0xd0000000/268435456, 0xf8000000/33554432, I/O @ 0x0000dc00/128, BIOS @ 0x????????/65536
[    14.827] Initializing built-in extension Generic Event Extension
[    14.827] Initializing built-in extension SHAPE
[    14.827] Initializing built-in extension MIT-SHM
[    14.827] Initializing built-in extension XInputExtension
[    14.827] Initializing built-in extension XTEST
[    14.827] Initializing built-in extension BIG-REQUESTS
[    14.827] Initializing built-in extension SYNC
[    14.827] Initializing built-in extension XKEYBOARD
[    14.827] Initializing built-in extension XC-MISC
[    14.827] Initializing built-in extension XINERAMA
[    14.827] Initializing built-in extension XFIXES
[    14.827] Initializing built-in extension RENDER
[    14.827] Initializing built-in extension RANDR
[    14.827] Initializing built-in extension COMPOSITE
[    14.827] Initializing built-in extension DAMAGE
[    14.827] Initializing built-in extension MIT-SCREEN-SAVER
[    14.827] Initializing built-in extension DOUBLE-BUFFER
[    14.827] Initializing built-in extension RECORD
[    14.827] Initializing built-in extension DPMS
[    14.827] Initializing built-in extension X-Resource
[    14.827] Initializing built-in extension XVideo
[    14.827] Initializing built-in extension XVideo-MotionCompensation
[    14.827] Initializing built-in extension XFree86-VidModeExtension
[    14.827] Initializing built-in extension XFree86-DGA
[    14.827] Initializing built-in extension XFree86-DRI
[    14.827] Initializing built-in extension DRI2
[    14.827] (II) LoadModule: "glx"
[    14.839] (II) Loading /usr/local/lib/xorg/modules/extensions/libglx.so
[    15.751] (II) Module glx: vendor="NVIDIA Corporation"
[    15.751]     compiled for 4.0.2, module version = 1.0.0
[    15.751]     Module class: X.Org Server Extension
[    15.751] (II) NVIDIA GLX Module  340.93  Wed Aug 19 16:20:38 PDT 2015
[    15.766] Loading extension GLX
[    15.766] (II) LoadModule: "nvidia"
[    15.790] (II) Loading /usr/local/lib/xorg/modules/drivers/nvidia_drv.so
[    15.857] (II) Module nvidia: vendor="NVIDIA Corporation"
[    15.857]     compiled for 4.0.2, module version = 1.0.0
[    15.857]     Module class: X.Org Video Driver
[    15.873] (II) NVIDIA dlloader X Driver  340.93  Wed Aug 19 16:00:14 PDT 2015
[    15.873] (II) NVIDIA Unified Driver for all Supported NVIDIA GPUs
[    15.875] (--) Using syscons driver with X support (version 134217730.0)
[    15.876] (++) using VT number 9

[    15.882] (II) Loading sub module "fb"
[    15.882] (II) LoadModule: "fb"
[    15.882] (II) Loading /usr/local/lib/xorg/modules/libfb.so
[    15.892] (II) Module fb: vendor="X.Org Foundation"
[    15.892]     compiled for 1.14.7, module version = 1.0.0
[    15.892]     ABI class: X.Org ANSI C Emulation, version 0.4
[    15.892] (WW) Unresolved symbol: fbGetGCPrivateKey
[    15.892] (II) Loading sub module "wfb"
[    15.892] (II) LoadModule: "wfb"
[    15.892] (II) Loading /usr/local/lib/xorg/modules/libwfb.so
[    15.903] (II) Module wfb: vendor="X.Org Foundation"
[    15.903]     compiled for 1.14.7, module version = 1.0.0
[    15.903]     ABI class: X.Org ANSI C Emulation, version 0.4
[    15.903] (II) Loading sub module "ramdac"
[    15.903] (II) LoadModule: "ramdac"
[    15.903] (II) Module "ramdac" already built-in
[    15.926] (WW) VGA arbiter: cannot open kernel arbiter, no multi-card support
[    15.926] (II) NVIDIA(0): Creating default Display subsection in Screen section
    "Default Screen Section" for depth/fbbpp 24/32
[    15.926] (==) NVIDIA(0): Depth 24, (==) framebuffer bpp 32
[    15.926] (==) NVIDIA(0): RGB weight 888
[    15.926] (==) NVIDIA(0): Default visual is TrueColor
[    15.926] (==) NVIDIA(0): Using gamma correction (1.0, 1.0, 1.0)
[    15.928] (**) NVIDIA(0): Enabling 2D acceleration
[    17.139] (II) NVIDIA(0): NVIDIA GPU GeForce 9600 GT (G94) at PCI:1:0:0 (GPU-0)
[    17.139] (--) NVIDIA(0): Memory: 524288 kBytes
[    17.139] (--) NVIDIA(0): VideoBIOS: 62.94.21.00.80
[    17.139] (II) NVIDIA(0): Detected PCI Express Link width: 16X
[    17.142] (--) NVIDIA(0): Valid display device(s) on GeForce 9600 GT at PCI:1:0:0
[    17.142] (--) NVIDIA(0):     CRT-0
[    17.142] (--) NVIDIA(0):     CRT-1
[    17.142] (--) NVIDIA(0):     TV-0
[    17.142] (--) NVIDIA(0):     Samsung SyncMaster (DFP-0) (boot, connected)
[    17.142] (--) NVIDIA(0):     DFP-1
[    17.142] (--) NVIDIA(GPU-0): CRT-0: 400.0 MHz maximum pixel clock
[    17.142] (--) NVIDIA(GPU-0): CRT-1: 400.0 MHz maximum pixel clock
[    17.142] (--) NVIDIA(GPU-0): TV-0: 400.0 MHz maximum pixel clock
[    17.142] (--) NVIDIA(0): Samsung SyncMaster (DFP-0): Internal TMDS
[    17.142] (--) NVIDIA(GPU-0): Samsung SyncMaster (DFP-0): 330.0 MHz maximum pixel clock
[    17.142] (--) NVIDIA(0): DFP-1: Internal TMDS
[    17.142] (--) NVIDIA(GPU-0): DFP-1: 330.0 MHz maximum pixel clock
[    17.142] (**) NVIDIA(0): Using HorizSync/VertRefresh ranges from the EDID for display
[    17.142] (**) NVIDIA(0):     device Samsung SyncMaster (DFP-0) (Using EDID frequencies
[    17.142] (**) NVIDIA(0):     has been enabled on all display devices.)
[    17.144] (==) NVIDIA(0): 
[    17.144] (==) NVIDIA(0): No modes were requested; the default mode "nvidia-auto-select"
[    17.144] (==) NVIDIA(0):     will be used as the requested mode.
[    17.144] (==) NVIDIA(0): 
[    17.144] (II) NVIDIA(0): Validated MetaModes:
[    17.144] (II) NVIDIA(0):     "DFP-0:nvidia-auto-select"
[    17.144] (II) NVIDIA(0): Virtual screen size determined to be 1680 x 1050
[    17.173] (--) NVIDIA(0): DPI set to (90, 88); computed from "UseEdidDpi" X config
[    17.173] (--) NVIDIA(0):     option
[    17.173] (--) Depth 24 pixmap format is 32 bpp
[    17.173] (II) NVIDIA: Reserving 768.00 MB of virtual memory for indirect memory
[    17.173] (II) NVIDIA:     access.
[    17.179] (II) NVIDIA(0): Setting mode "DFP-0:nvidia-auto-select"
[    17.241] Loading extension NV-GLX
[    17.280] (==) NVIDIA(0): Disabling shared memory pixmaps
[    17.280] (==) NVIDIA(0): Backing store disabled
[    17.280] (==) NVIDIA(0): Silken mouse enabled
[    17.281] (==) NVIDIA(0): DPMS enabled
[    17.281] Loading extension NV-CONTROL
[    17.281] Loading extension XINERAMA
[    17.281] (II) Loading sub module "dri2"
[    17.281] (II) LoadModule: "dri2"
[    17.281] (II) Module "dri2" already built-in
[    17.284] (II) NVIDIA(0): [DRI2] Setup complete
[    17.284] (II) NVIDIA(0): [DRI2]   VDPAU driver: nvidia
[    17.285] (--) RandR disabled
[    17.314] (II) Initializing extension GLX
[    17.866] (II) config/devd: probing input devices...
[    17.866] (II) config/devd: adding input device (null) (/dev/kbdmux)
[    17.866] (II) LoadModule: "kbd"
[    17.878] (II) Loading /usr/local/lib/xorg/modules/input/kbd_drv.so
[    17.880] (II) Module kbd: vendor="X.Org Foundation"
[    17.880]     compiled for 1.14.7, module version = 1.8.0
[    17.880]     Module class: X.Org XInput Driver
[    17.880]     ABI class: X.Org XInput driver, version 19.1
[    17.880] (II) Using input driver 'kbd' for 'kbdmux'
[    17.880] (**) kbdmux: always reports core events
[    17.880] (**) kbdmux: always reports core events
[    17.880] (**) Option "Protocol" "standard"
[    17.880] (**) Option "XkbRules" "base"
[    17.880] (**) Option "XkbModel" "pc105"
[    17.880] (**) Option "XkbLayout" "us"
[    17.880] (**) Option "config_info" "devd:kbdmux"
[    17.880] (II) XINPUT: Adding extended input device "kbdmux" (type: KEYBOARD, id 6)
[    17.880] (II) config/devd: kbdmux is enabled, ignoring device ukbd0
[    17.880] (II) config/devd: kbdmux is enabled, ignoring device atkbd0
[    17.881] (II) config/devd: adding input device (null) (/dev/sysmouse)
[    17.881] (II) LoadModule: "mouse"
[    17.881] (II) Loading /usr/local/lib/xorg/modules/input/mouse_drv.so
[    17.888] (II) Module mouse: vendor="X.Org Foundation"
[    17.888]     compiled for 1.14.7, module version = 1.9.1
[    17.888]     Module class: X.Org XInput Driver
[    17.888]     ABI class: X.Org XInput driver, version 19.1
[    17.888] (II) Using input driver 'mouse' for 'sysmouse'
[    17.888] (**) sysmouse: always reports core events
[    17.888] (**) Option "Device" "/dev/sysmouse"
[    17.888] (==) sysmouse: Protocol: "Auto"
[    17.888] (**) sysmouse: always reports core events
[    17.888] (==) sysmouse: Emulate3Buttons, Emulate3Timeout: 50
[    17.888] (**) sysmouse: ZAxisMapping: buttons 4 and 5
[    17.889] (**) sysmouse: Buttons: 5
[    17.889] (**) Option "config_info" "devd:sysmouse"
[    17.889] (II) XINPUT: Adding extended input device "sysmouse" (type: MOUSE, id 7)
[    17.889] (**) sysmouse: (accel) keeping acceleration scheme 1
[    17.889] (**) sysmouse: (accel) acceleration profile 0
[    17.889] (**) sysmouse: (accel) acceleration factor: 2.000
[    17.889] (**) sysmouse: (accel) acceleration threshold: 4
[    17.889] (II) sysmouse: SetupAuto: hw.iftype is 4, hw.model is 0
[    17.889] (II) sysmouse: SetupAuto: protocol is SysMouse
[    17.889] (II) config/devd: device /dev/ums0 already opened

Monti · Oct 29, 2015

sidetone , just a question about loading of video driver without breaking the video drivers' functionality.

Would using /etc/rc.config using the command below load the driver without breaking functionality?

Code:

kld_list="nvidia.ko"

Thanks

tobik@ · Oct 29, 2015

I'm not sidetone, but yes. I do the same. Using just kld_list="nvidia" in /etc/rc.conf would work too.

How long is the screen blank anyway? I recently used an older LCD monitor and the delay when switching resolutions was > 10 s, so very noticeable.

sidetone · Oct 29, 2015

I haven't heard of the video driver being loaded through rc.conf. Try with and without it.

Looking at the var/log/Xorg.0.log output that tobik asked for, I thought I saw something, but then my output was similar. It gave me an idea. Check anything in your configuration or modules that contains "drm", or "kms". Check that those aren't loaded twice. Try removing all of that from custom start up configurations, and let that auto-load. Maybe a module is loaded in a way that doesn't work, then after that long time, it finds the proper way to load.

What are the lines in kldstat containing "drm", "kms", "dri" or "nvidia"?

Also, using hdmi or dvi might make a difference, depending on if a card is supported, but Nvidia cards typically have full support.

ivosevb · Oct 29, 2015

Maybe is a DNS and network problem. Try to resolve some dns names at the console while waiting for Slim to start

sidetone · Oct 30, 2015

Perhaps Thread howto-setup-xorg-with-nvidias-driver.52311?

Monti · Oct 31, 2015

Thanks guys!

tobik , including the NVIDIA logo screen that is up for about half a second I timed the black screen for 1 min and 18 sec.

sidetone . Yesterday I remembered that when installing FreeBSD 10.1 on the first computer I did not have this issue, this I am sure of, but then doing a port or system upgrade it started happening. (Edit: it was after restarting the machine after adding rules to /etc/pf.conf and pf_enable="YES" to /etc/rc.conf) The first thing I thought of was that I had just put the line linux_enable="YES" in /boot/loader.conf , but removing it did not make any difference. So I presumed that it was not the cause. I have not done this at all with the second computer, meaning not in /etc/rc.conf either.

With the second computer version 10.2 was installed from start, and if I do not remember wrong the first thing I did after installing x11/mate-desktop and x11/slim was to install the NVIDIA driver, where I experienced the issue at first reboot. That said, I might be wrong about not installing any apps before first boot with x11/slim and the x11/nvidia-driver-340 . If apps or utils matters I do not know. If I will not find any modules that are loaded twice, I will do a fresh install on the first computer with 10.1 installed using 10.2, and then carefully notice every step I am doing.

kldstat are showing "nvidia.ko". None of the others that you mentioned. Only DVI are being used.

Monti · Oct 31, 2015

ivosevb said:
Maybe is a DNS and network problem. Try to resolve some dns names at the console while waiting for Slim to start

Thank you for your reply ivosevb . I have not had any network/DNS problems, so I do not suspect it to be an issue. Regarding using console waiting for x11/slim I am not sure if I understand you correctly. The screen is completely blank without any console during the waiting time.

Monti · Oct 31, 2015

sidetone said:
Perhaps Thread howto-setup-xorg-with-nvidias-driver.52311?

Thanks sidetone. I read this guide right after my first FreeBSD installation, but I did not understand the sysrc kld_list+=nvidia command, so I used the nvidia_load="YES" in /boot/loader.conf instead.

protocelt · Oct 31, 2015

All sysrc kld_list+=nvidia does in general is add kld_list+=nvidia to /etc/rc.conf and load the Nvidia kernel driver later in the startup process. There have been problems in the past adding nvidia_load="YES" to /boot/loader.conf so doing it this way bypasses that problem if it comes up again. It also cuts your boot time down(quite a bit when using ZFS) as the driver is loaded faster.

tobik@ · Oct 31, 2015

Monti said:
Thanks sidetone. I read this guide right after my first FreeBSD installation, but I did not understand the sysrc kld_list+=nvidia command, so I used the nvidia_load="YES" in /boot/loader.conf instead.

Monti, I've just edited the howto to better explain what sysrc(8) does. Take a look and let me know what else I can clarify there.

Monti · Oct 31, 2015

protocelt said:
All sysrc kld_list+=nvidia does in general is add kld_list+=nvidia to /etc/rc.conf and load the Nvidia kernel driver later in the startup process. There have been problems in the past adding nvidia_load="YES" to /boot/loader.conf so doing it this way bypasses that problem if it comes up again. It also cuts your boot time down(quite a bit when using ZFS) as the driver is loaded faster.

Thanks protocelt for your input. Good to know. Regarding your comment in tobik's HOWTO thread:

....Just checked and linux.ko is loaded automatically as a dependent module at boot but if installing x11/nvidia-driver from ports it will need to be loaded as a prerequisite to installing the port unless the Linux compatibility option is turned off.

Do I understand you correctly when saying that linux_load="YES" should specifically be added to /boot/loader.conf before x11/nvidia-driver is installed and not linux_enable="YES" with /etc/rc.conf? I am asking, because I am going to do a fresh install noticing when my issues is appearing, so would like to do it "by the book"

protocelt · Oct 31, 2015

It can be added to either rc.conf or in loader.conf. Either way will work as long as it's loaded before installing the x11/nvidia-driver port. This only holds true if you use the default options when installing the x11/nvidia-driver port. If you turn the Linux compatibility option off in the port before installing it, the Linux kernel module no longer needs to be loaded before or even at all as a prerequisite.

Personally I use rc.conf to load both. I have the following in my rc.conf file:

Code:

kld_list+="linux nvidia etc etc etc"

ivosevb · Oct 31, 2015

Monti said:
Thank you for your reply ivosevb . I have not had any network/DNS problems, so I do not suspect it to be an issue. Regarding using console waiting for x11/slim I am not sure if I understand you correctly. The screen is completely blank without any console during the waiting time.

I mean Ctrl+Alt+F2 while the screen is blank, login and try to ping something ... www.FreeBSD.org for example. I had similar problem and my /etc/resolv.conf was wrong.

Monti · Oct 31, 2015

protocelt , super! Love it

wblock@ · Oct 31, 2015

This really does sound like DNS timeouts when trying to resolve the local host name. That is not a network configuration problem, it is a DNS configuration problem. Test it. Use hostname to get the name, then try to ping it: ping `hostname`. If that does not work, the hostname needs to be added to /etc/hosts.

Monti · Nov 3, 2015

Thank you very much for your reply wblock@ . I have checked with hostname and ping 'hostname' and it is working well with both "computer.my.domain" and just "computer". I have used two configurations where I have the x11/slim waiting issue with both. I have listed both configurations below. At the moment I am using the latter. I have also listed the rest of my configurations concerning x11/nvidia-driver and x11/slim .

My /etc/hosts file had and has the following configurations:

Code:

::1                localhost localhost.mydomain.com computer computer.mydomain.com
127.0.0.1        localhost localhost.mydomain.com computer computer.mydomain.com

---

::1             computer.my.domain computer
127.0.0.1       computer.my.domain computer

My /etc/ttys file has for x11/slim:

Code:

# Virtual terminals
ttyv1    "/usr/libexec/getty Pc"        xterm    on  secure
ttyv2    "/usr/libexec/getty Pc"        xterm    on  secure
ttyv3    "/usr/libexec/getty Pc"        xterm    on  secure
ttyv4    "/usr/libexec/getty Pc"        xterm    on  secure
ttyv5    "/usr/libexec/getty Pc"        xterm    on  secure
ttyv6    "/usr/libexec/getty Pc"        xterm    on  secure
ttyv7    "/usr/libexec/getty Pc"        xterm    on  secure
# ttyv8    "/usr/local/bin/xdm -nodaemon"    xterm    off secure
ttyv8   "/usr/local/bin/slim"       xterm   on  secure

And my etc/rc.conf has (some default entries excluded):

Code:

powerd_enable="YES"
linux_enable="YES"
kld_list="nvidia"
hostname="computer.mydomain.com"
ifconfig_re0="DHCP"
moused_enable="NO"
dbus_enable="YES"
hald_enable="YES"
avahi_daemon_enable="NO"
avahi_dnsconfd_enable="NO"

With X11 for x11/nvidia-driver-340 I have in /usr/local/etc/X11/xorg.conf.d/10-nvidia.conf:

Code:

Section "Device"
    Identifier "NVIDIA Card"
    VendorName "NVIDIA Corporation"
    Driver "nvidia"
EndSection

Monti · Nov 6, 2015

Found the cause by accident, but why it's the reason beats me.... It was the /etc/pf.conf firewall configuration.

When I started with FreeBSD I just wanted a basic configuration until the time for a more in depth pf firewall study. The reason for pf is that I would also like to learn OpenBSD at a later point.

I got the basic configuration from the FreeBSD handbook page http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/firewalls-pf.html

Code:

block in all
pass out all keep state

So this configuration is the reason for the "waiting" issue with x11/slim.

Since I didn't like the weakness with the configuration above I found yesterday another configuration over at http://daemonforums.org/showthread.php?t=4187 .

Code:

ext_if="nfe0"

tcp_services = "{ssh, imaps, smtp, 587, domain, ntp, www, https}"
udp_services= "{domain, ntp}"


set skip on lo
set loginterface $ext_if

scrub in all random-id fragment reassemble

block return in log all
block out all

antispoof quick for $ext_if


pass out quick on $ext_if proto tcp to any port $tcp_services
pass out quick on $ext_if proto udp to any port $udp_services

So when restarting the machines x11/slim login screen is now up and running within a couple of seconds. If someone have an explanation for this, I would be greatful to read it.

Thanks.