building my own kernel: no video output during boot on notebook LCD

Hello Everyone,

I have a ThinPad T430 ( http://www.thinkwiki.org/wiki/Category:T430 ), which I use in pure UEFI mode.

About the system:
It has NVIDIA NVS 5400M GPU, which is set to native mode, so Optimus is not enabled in the UEFI firmware setup. It also has an integrated Intel GPU, that is disabled from UEFI. (You can only choose either the Intel or the NVidia one, or to enable Optimus.)
I have installed Slackware64 14.2 and updated the system with the most recent packages.
All seems okay and working with the 4.4.74 distribution kernel. (It uses the nouveau driver.)

I use LVM, therefore I have to use an (xz compressed) initrd. How it has to be used was described to be by AlienBob ( http://www.linuxquestions.org/questions/slackware-installation-40/booting-with-xz-compressed-initrd-4175599273/ )

The problem is, that with the kernel (4.9.34) I configured, there is no graphics output during the boot process. The display is only initialized when X starts, and even then, there is nothing displayed when switching back to the text console. (The console actually works even though nothing is displayed.)
I disabled the nouveau, and nvidiafb drivers, because I installed the proprietary NVidia driver (375.66). I put the driver into the initrd (nvidia.ko, nvidia-drm.ko, nvidia-kms.ko), because I have to use an initrd due to the LVM I use.

I would like to be able to use a high resolution text console, and also use X.

I have also left the intel vga driver compiled in, so that in case I change my mind, I won’t need to recompile my kernel.
The high resolution console works fine with the intel driver, and even with nouveau.

What may I be missing?
I can provide the kernel configuration and dmesg output if that helps.
The original LinuxQuestions thread can be found here: http://www.linuxquestions.org/questions/slackware-14/building-my-own-kernel-no-video-output-on-notebook-lcd-4175608827/

During the weekend I had some time and have upgraded my 14.2 installation to -current.
Then I went on and recompiled my kernel config with the latest 4.9.38 version.
The next step was taking the version 4.9.37 kernel-generic kernel, disabling nouveau with modprobe.conf, and adding the NVidia kernel driver.
I have packaged it to initrd, and the result is the following:
At boot, efifb is activated, and stays active, until X starts. Then the NVidia driver seems to become active, and the text consoles become invisible. When hitting Ctrl+Alt+F1, I only see a blank black screen without anything on it.

So this behavior is not related to my config, as I haven’t changed the config of the OS-shipped -generic kernel image.

Is this still a problem with 384.47?

Dear Aaron,

I can confirm, the behavior is the same with the beta driver.
Do you need me to gather any outputs like dmesg, or something?

Please run nvidia-bug-report.sh and attach the resulting nvidia-bug-report.log.gz file.

If I understand your first post at linuxquestions.org, everything works correctly with the stock kernel and only fails with your custom kernel, but you also disabled nouveau in your custom kernel. Does the nvidia driver work with the stock kernel if you blacklist nouveau?

Dear Aaron,

At first I tried to troubleshoot my custom kernel config, because I thought I made a mistake.
After several failed attempts, I was suggested to reproduce the problem with the stock distibution kernel.
In case of Slackware this is the kernel-generic kernel.

The problem is still occurring with this one. My latest desription about efifb being available first, and the console “disappearing” after X is started is about the -generic kernel.
All I did to that kernel, was blacklisting the nouveau driver via modprobe.d, and then running the NVidia driver installer. Once the driver was built, I put nvidia.ko, nvidia-kms.ko and nvidia-drm.ko into my initrd file, via the following script:

#!/bin/bash
mkinitrd -L -f ext4 -r /dev/rootvg/root-lv -m ext4:usbhid:ehci-hcd:uhci-hcd:xhci-hcd:nvidia:nvidia-drm:nvidia-modeset -h /dev/rootvg/swap-lv -k 4.9.37 -o initrd.gz
rm initrd.xz initrd 2>&-
gunzip initrd.gz
xz --check=crc32 initrd

I will shortly attach the bug report log bundle.
I hope it helps.

Thank you!
nvidia-bug-report.log.gz (72.3 KB)

From your LQ thread I think you’re using LILO as bootloader? Please post your lilo.conf, mabe there’s some relevant info.

Dear generix,

I use elilo, because the machine is in UEFI mode.
The kernel command line looks like the following:

BOOT_IMAGE=dev000:\EFI\Slackware\vmlinuz-generic  root=/dev/rootvg/root-lv vga=normal vt.default_utf8=1 ipv6.disable=1 thinkpad-acpi.brightness-enable=1 ro ro

Apart from that, there is pretty little you can set up in elilo.conf (apart from the paths of kernel and initrd images, menu style, delay, default boot entry.)

PS: Tomorrow I’m heading off to a week-long vacation, so I won’t be able to test anything, nor to answer any questions.

I’m back. Please let me know if you need anything else for the investigation!

Today, I installed the latest nvidia driver version of 384.59 onto the latest distribution kernel of 4.9.38 remotely. I will check the results in the evening when I get home.

You could check if adding either
nomodeset
or
nvidia-drm.modeset=1
to your kernel command line changes anything. Either or, not both.

I tried the new version of the driver with both with nomodeset and nvidia-drm.modeset=1 one at a time.
With nomodeset, the behavior was exactly the same as before:
efifb console worked fine, until X is started, then nothing afterwards on the physical consoles.

With nvidia-drm.modeset=1 the situation was a bit different:
efifb console worked fine at the beginning, then once during the boot, a graphical glitch appeared: in a wider horizontal area around the center of the LCD screen, some garbled artifacts were displayed (the rest of the screen stopped being updated), and the output changed within the area as the boot progressed, but it was unusable, as no readable information was displayed within the area.
In the end, when X was started, the graphical display returned to normal, but the consoles were blank again, when I changed to them. :(

If you’re still running the generic kernel, please post the output of lsmod to see if any unusual modules are loaded.

Just as a sidenot, did you ever try to replace efifb with simplefb?

Yes, I am still running the distribution’s generic kernel (the original binary image - I haven’t recompiled it), so I have little means to influence which framebuffer driver gets loaded. By default efifb is loaded during boot.

I have attached the output of lsmod, and an nvidia bugreport log.
generic-lsmod.txt (4.08 KB)
nvidia-bug-report.log.gz (73.4 KB)

Somehow the framebuffer gets always lost on the way. Can you please remove all the kernel options related to video, especially the vga=normal and nvidia-drm.modeset=1 or nomodeset and replace it with video=efifb ?
Unfortunately, the generic slackware kernel does not include the other two options for an efi boot simplefb or uvesafb, so to replace efifb with those you would have to compile your own kernel.

I tried removing all video related kernel parameters, and adding video=efifb, but the result remained the same as when using the nomodeset option: efifb console worked fine, until X is started, then nothing showed afterwards on the physical consoles.

Are there any further suggestions, or further inquiries regarding the bug report?

Since there are no errors, just doesn’t work it’s hard to come up with something new.
So options left are compiling your own kernel and try simplefb or uvesafb instead of efifb.
Something unlikely but at least I suffered from this some time ago:
Whenever I switched consoles, screen went black. Took me a week to notice it was a kernel bug just setting the brightness to 0. Are your brightness controls properly working? Is the backlight on or off when at text console? Can you log in blindly and ‘touch IAMHERE’ to see if the file gets created?

So you are saying that I can use video=simplefb or video=uvesafb to select which frame buffer driver I wish to load for my console? Until now it seemed that the kernel chooses one in a kind-of fixed order, and that’s it. I compiled in vesafb on my own kernel, but it did not get loaded automatically.
There, I did not use any video= kernel parameters.

I tried checking out the backlight topic too:
I connected a monitor over the mini-DVI port, and nothing showed there, (on the built-in LCD the console was okay) until X started, then the external monitor initialized too. Then I switched back to console, and on the built-in LCD screen there was nothing, while external monitor went to sleep, as - I assume - it did not get any signal.

I remember logging in, and rebooting the machine, so the console is actually working and responding to user input.