[SOLVED] Kernel 4.11.0-rc7 - Slack64 Current - i6700 Graphics 530 (rev 06) - requires nomodeset

Anyone running kernel 4.11.0-rc7 on Slack64 Current on an intel i7/6700 with onboard Graphics 530 (rev 06)? For me it requires the nomodeset kernel boot parameter.
Funny thing is that the same kernel on the same hardware but with a 32-bit 14.2-like userland (PartedMagic) runs ok without the nomodeset.
As the xf86-video-intel versions differ (PM git_20170228 vs Slack git_20170313) I built the PM one for Slack64, but to no avail ...

Try using the modesetting ddx included with the xorg-server instead of xf86-video-intel.

I experimented with the modesetting ddx (/usr/lib64/xorg/modules/drivers/modesetting_drv.{la,so}) via an entry in /etc/X11/xorg.conf.d, but to no avail ...
For as far as I am aware this replaces the *xorg* driver, but the black screen occurs when eudev makes the *kernel* do the mode switch, so much earlier. Actually I boot into level 3, so no X initially.


As an aside: returning from a suspend does not work either.

Yea, the modesetting ddx tends to be (Sometimes?) better supported upstream than the various individual xorg ddx drivers. Though I guess we know what the issue is not then.

What was the last working kernel for you? I guess you could ask the intel devs directly in #intel-gfx @ freenode.

The 4.10.11 kernel works without a hitch (no nomodeset, return from suspend ok) for me.
When scanning the DRM/Intel Bug List at Freedesktop.org (google for "intel i915 drm bug") for 4.11 I found "Bug 100383 - [i915][BYT] Black screen in mainstream kernel 4.11.rc3 on Toshiba LX0W-C64", which looks like my problem - though that is an atom instead of my i7. Alas no resolution as of yet.
If things come to the worst I can always skip the 4.11 kernel.

Originally Posted by burdi01 Anyone running kernel 4.11.0-rc7 on Slack64 Current on an intel i6700 with onboard Graphics 530 (rev 06)? For me it requires the nomodeset kernel boot parameter.

Slackware64-current, 4.11.0-rc7, 6700K with onboard Graphics 530, dual monitors.

Both runlevels 3 and 4 work fine, w/o nomodeset boot parameter. For X I use the modesetting driver.

Mine is a i7/6700 (w/o the "K") with a single monitor.
I also tested the Slack64 image on my other desktop and laptops - all of them with older intel onboard graphics: no nomodeset required and return from suspend ok.

With kernel 4.11 as released I had an other "go" at the problem.

On my i7-6700 with onboard Graphics 530 (rev 06), when booting Current64 the screen turns black at the modeswitch as triggered by the udev invocation rather early in the boot sequence. With kernels before 4.11 the screen comes back in about one second, with the 4.11 kernel it stays black. The "nomodeset" kernel boot parameter inhibits the modeswitch and hence the black screen. Also with the 4.11 kernel a suspend either fails (no blinking power led) or succeeds (blinking power led) but fails to awaken afterwards.

To check whether the black screen is caused by a crash or is just a black screen while the system continues to boot I accessed the system from an other box. As I could access the box the latter is the case. To my very surprise the screen then came back after some two minutes! I have been rebooting the box too early all of the time.
Acessing the logs now was easy. At first I did not see anything out of the ordinary in /var/log/messages. The complaints about bluetooth and cgroups were there as usual. As an experiment I enabled them, but to no avail.

But then I saw:

May 1 11:51:52 riposo kernel: [ 2.686181] i915 0000:00:02.0: Direct firmware load for i915/skl_huc_ver01_07_1398.bin failed with error -2 May 1 11:51:52 riposo kernel: [ 2.686195] i915 0000:00:02.0: Falling back to user helper May 1 11:51:52 riposo kernel: [ 2.688591] [drm] Finished loading DMC firmware i915/skl_dmc_ver1_26.bin (v1.26)

Maybe this was the culprit. Some googling gave https://01.org/linuxgraphics/downloads/ > Skylake HUC - 1.07 > sklhucver01071398.tar.bz2. The install.sh script therein is very Ubuntu/Fedora-minded, but it installed the skl_huc_ver01_07_1398.bin file in my /lib/firmware/i915 directory.
A reboot proved this to be the resolution.

Also the suspend and its come back turned out to be resolved. Obviously the VESA driver as loaded because of the nomodeset is not suspend-friendly, but the intel/i915 driver as loaded now is.

Originally Posted by burdi01 But then I saw: Maybe this was the culprit. Some googling gave https://01.org/linuxgraphics/downloads/ > Skylake HUC - 1.07 > sklhucver01071398.tar.bz2. The install.sh script therein is very Ubuntu/Fedora-minded, but it installed the skl_huc_ver01_07_1398.bin file in my /lib/firmware/i915 directory. A reboot proved this to be the resolution. Also the suspend and its come back turned out to be resolved. Obviously the VESA driver as loaded because of the nomodeset is not suspend-friendly, but the intel/i915 driver as loaded now is.

Great sleuthing!

I can't check right now (because kernel.org is blocked at my work), but I wonder if this updated firmware is already included in the latest kernel firmware from kernel.org. You could try removing the skl_huc_ver01_07_1398.bin file and then run the kernel-headers.SlackBuild linked below. It will get the latest version from kernel.org's git and compile it into a Slackware package. You can then just run upgradepkg with the updated package. (Make sure you also grab the slack-desc file so it can have that for the package creation.)

https://slackbuilds.org/mirror/slack...rnel-firmware/

It'd be interesting to see if the kernel's firmware matches what the latest kernel itself requires...

It'd be interesting to see if the kernel's firmware matches what the latest kernel itself requires...

I did download and install the firmware a few days ago, so not knowing what (if any) missing firmware might be the culprit. It did not resolve my problem then.
I did things again today and yes, the /lib/firmware/i915/skl_huc_ver01_07_1398.bin is there.
Either it was added very recently, or I did something wrong that few days ago.
Thank you for responding.


PS: Current's firmware is from 20161211, so an upgrade might be a good thing.

Originally Posted by burdi01 I did download and install the firmware a few days ago, so not knowing what (if any) missing firmware might be the culprit. It did not resolve my problem then. I did things again today and yes, the /lib/firmware/i915/skl_huc_ver01_07_1398.bin is there. Either it was added very recently, or I did something wrong that few days ago.

Looking at their git, it seems this firmware was added back in February.

https://git.kernel.org/pub/scm/linux...01_07_1398.bin

Originally Posted by burdi01 PS: Current's firmware is from 20161211, so an upgrade might be a good thing.

It probably will be once Pat switches to a more recent kernel. Keep in mind, -current still uses the 4.4 series, which would not benefit from this newer firmware. When running a kernel series that is newer than what Pat provides, there's bound to be some additional work you may need to do. Ensuring your firmware matches what the kernel expects is one of them

When running a kernel series that is newer than what Pat provides, there's bound to be some additional work you may need to do. Ensuring your firmware matches what the kernel expects is one of them

I have been running the latest and greatest kernels on Current for years now and this is the first time the firmware "bit" me.
Nevertheless keeping the firmware up-to-date too is a good idea.
Thanks again.