Solved Black Screen on Intel HD Graphics 530

I

iskander

Hello everyone.
The problem is that I get a black screen with my Intel Core i5-6400 CPU's integrated graphics chip.
Steps to reproduce:
  1. FreeBSD 14.2-RELEASE clean install.
  2. On one of the latest bsdinstall menus I am asked to install the following firmware package: gpu-firmware-intel-kmod-skylake. I agree.
  3. pkg install drm-kmod.
  4. sysrc kld_list+=i915kms.
  5. Reboot.
On the next boot, the screen goes black after a line drm[something] appears. See the complete dmesg in the drm-kmod.txt attachment.
The screen does not go black if skip step 3. The complete dmesg of that case is in the gpu-firmware-intel-kmod-skylake.txt attachment.
Could someone please help me to solve the problem? The CPU is definitely not bleeding-edge, and so I am much surprised by the presence of the problem. My motherboard does not have any graphics output other than DVI-D, so I am using it. The cable is DVI-D to HDMI.
Thank you.
 

Attachments

Why I install the drm-kmod package in the first place: if I don't do it,
  • xrandr tells: Can't open display.
  • the Wayfire tells me it did not found a GPU on startup.
Also, installing the package is a step in The Handbook anyway.
 
Thank you. I am labeling the thread as solved now. I indeed did a poor homework before posting. The better prompt for a search engine to find more information on the issue is: drm-kmod freebsd blackscreen. There is also a note on the issue on the errata page of the release.

P.S. Never installed a single port. I thought it would be as easy as The Handbook says:
  1. cd /usr/ports/graphics/drm-kmod.
  2. make install.
But it failed with errors. So I am just going to install FreeBSD 14.1-RELEASE.
 
Holger said:
When you say “compile from ports”, which branch should one take (quaterly, latest, master, etc.)?
Click to expand...
Just my opinion. No intention to force anyone else.
  • For servers at datacenters or cloud-based, quarterly.
  • For servers on-premise with /usr/local on non-ZFS, quarterly.
  • For anything else, latest.

This is because servers on datacenters can be (physically) accessed only by quite limited and authorized admins, so safety on upgrade is the maximum concern.

And the admins MUST be quite well experienced, skilled and sane. So delays of updates merely matters (they can [at least expected to] find workaround and apply it just in time, if none, temporarily cherry pick fixed version and create patch for minimizing incompatibilities quickly).

And on-premise servers can be accessed much easier than in datacenters. More admins would be able to help/co-work to minimize mistakes.
Here, if the system filesystem (at least /usr/local, /var/db) is on ZFS, it can be quite easily rolled back to working state when something went wrong on upgrades IF SNAPSHOTS ARE TAKEN BEFORE STARTING UPGRADES.
So safety on upgrade less matters.
But if the filesystem is NOT ZFS, safety on upgrade matters, thus, quarterly should be preferred, with the needs for workarounds.

For anything else, especially clients / independent PCs, latest softwares are often required (for anything depending on LinuxKPI, almost mandated), thus, no way for quarterly.

Note that latest == main == master.
Latest is the name of official pkgs built with main branch of ports tree.
And master is the name of main branch on github mirror.
Thus, all 3 are exactly the same.
 
You must log in or register to reply here.
Back
Top