LinuxQuestions.org
Latest LQ Deal: Linux Power User Bundle
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Reply
  Search this Thread
Old 04-18-2017, 09:24 AM   #1
burdi01
Member
 
Registered: Dec 2010
Location: The Netherlands
Distribution: Slackware, Xubuntu
Posts: 195

Rep: Reputation: 28
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 ...

Last edited by burdi01; 04-20-2017 at 04:57 AM.
 
Old 04-18-2017, 11:07 AM   #2
orbea
Member
 
Registered: Feb 2015
Distribution: Slackware64-current
Posts: 714

Rep: Reputation: Disabled
Try using the modesetting ddx included with the xorg-server instead of xf86-video-intel.
 
Old 04-19-2017, 10:19 AM   #3
burdi01
Member
 
Registered: Dec 2010
Location: The Netherlands
Distribution: Slackware, Xubuntu
Posts: 195

Original Poster
Rep: Reputation: 28
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.

Last edited by burdi01; 04-19-2017 at 10:41 AM.
 
Old 04-19-2017, 10:55 AM   #4
orbea
Member
 
Registered: Feb 2015
Distribution: Slackware64-current
Posts: 714

Rep: Reputation: Disabled
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.
 
Old 04-19-2017, 01:38 PM   #5
burdi01
Member
 
Registered: Dec 2010
Location: The Netherlands
Distribution: Slackware, Xubuntu
Posts: 195

Original Poster
Rep: Reputation: 28
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.

Last edited by burdi01; 04-19-2017 at 02:53 PM.
 
Old 04-20-2017, 12:12 AM   #6
ppencho
Member
 
Registered: Jan 2004
Location: Bulgaria
Distribution: Slackware64-current
Posts: 93

Rep: Reputation: Disabled
Quote:
Originally Posted by burdi01 View Post
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.
 
Old 04-20-2017, 10:53 AM   #7
burdi01
Member
 
Registered: Dec 2010
Location: The Netherlands
Distribution: Slackware, Xubuntu
Posts: 195

Original Poster
Rep: Reputation: 28
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.
 
Old 05-02-2017, 06:52 AM   #8
burdi01
Member
 
Registered: Dec 2010
Location: The Netherlands
Distribution: Slackware, Xubuntu
Posts: 195

Original Poster
Rep: Reputation: 28
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:
Quote:
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.

Last edited by burdi01; 05-02-2017 at 07:24 AM.
 
4 members found this post helpful.
Old 05-02-2017, 11:44 AM   #9
bassmadrigal
Senior Member
 
Registered: Nov 2003
Location: Newport News, VA
Distribution: Slackware
Posts: 4,223

Rep: Reputation: 2181Reputation: 2181Reputation: 2181Reputation: 2181Reputation: 2181Reputation: 2181Reputation: 2181Reputation: 2181Reputation: 2181Reputation: 2181Reputation: 2181
Quote:
Originally Posted by burdi01 View Post
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...
 
Old 05-03-2017, 05:31 AM   #10
burdi01
Member
 
Registered: Dec 2010
Location: The Netherlands
Distribution: Slackware, Xubuntu
Posts: 195

Original Poster
Rep: Reputation: 28
Quote:
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.

Last edited by burdi01; 05-03-2017 at 06:10 AM.
 
Old 05-03-2017, 08:42 AM   #11
bassmadrigal
Senior Member
 
Registered: Nov 2003
Location: Newport News, VA
Distribution: Slackware
Posts: 4,223

Rep: Reputation: 2181Reputation: 2181Reputation: 2181Reputation: 2181Reputation: 2181Reputation: 2181Reputation: 2181Reputation: 2181Reputation: 2181Reputation: 2181Reputation: 2181
Quote:
Originally Posted by burdi01 View Post
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

Quote:
Originally Posted by burdi01 View Post
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
 
Old 05-04-2017, 04:30 AM   #12
burdi01
Member
 
Registered: Dec 2010
Location: The Netherlands
Distribution: Slackware, Xubuntu
Posts: 195

Original Poster
Rep: Reputation: 28
Quote:
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.
 
1 members found this post helpful.
  


Reply

Tags
current nomodeset


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
[SOLVED] Anyone having problems with the 3.6.0-rc7 kernel? Rupadhya Linux - Kernel 8 10-04-2012 03:35 PM
[SOLVED] slack64 -current: "random" screensaver produces kernel panic the_penguinator Slackware 4 11-25-2011 09:43 AM
-current users with 2.6.33+ and nVidia GPU : nomodeset can avoid you a blank screen Didier Spaier Slackware 2 04-08-2010 02:07 PM
kernel 2.6.24 in -current requires NVIDIA driver update TNWestTex Slackware 4 03-12-2008 02:04 PM
Smoothwall 2.0 & DFE-530 TX REV A wburquhart Linux - Hardware 1 01-29-2004 04:57 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 04:15 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration