LinuxQuestions.org
Latest LQ Deal: Latest LQ Deals
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 06-22-2019, 03:26 PM   #1
badbetty
Member
 
Registered: Jan 2014
Posts: 130

Rep: Reputation: Disabled
kernels since 4.4.157 cause the screen to go blank during boot...


Hello all

Slackware 14.2 64 on asus 1225b. Since upgrading the kernel from 4.4.157 to the next one when it was released, rather oddly during boot, the screen goes blank/gets turned off during boot just after the boot text starts scrolling; it never did previously. It has remained like this even at 4.4.182.

I'm left wondering what changed - or how I could track it down [gulp] please ?

I can press the function screen off/on key and that appears to restore normal order, so its not a major deal. I ended up building a kernel based on 4.4.157 to get it all working as it did...so I use that for now. Just tried 4.4.182 and the same problem exists as mentioned.

Thank you.
 
Old 06-22-2019, 03:54 PM   #2
Didier Spaier
LQ Addict
 
Registered: Nov 2008
Location: Paris, France
Distribution: Slint64-14.2.1.2 on Lenovo Thinkpad W520
Posts: 8,882

Rep: Reputation: Disabled
As usual to investigate such an issue you should check the output of dmesg or the content of /var/log/messages as root.

Also making an Internet search mentioning the vendor an product Id if your video card could bring some useful information.

To get these information use this command as root:
Code:
lspci -knn|grep -iA3 VGA
Anyway running a kernel that has known security issues just for that is not a wise choice in my opinion.
 
1 members found this post helpful.
Old 06-23-2019, 01:03 AM   #3
badbetty
Member
 
Registered: Jan 2014
Posts: 130

Original Poster
Rep: Reputation: Disabled
@didier

One old machine (it has hd3200 radeon graphics onboard) cannot stop kernel development, just in case that needs saying before the next statement, but it is frustrating when something just stops working that has worked without issue since the dawn of time for that machine so to speak.

Whilst it is minor issue as I acknowledged, it is not ideal and takes a bit of pfaffing to get it back in order. Oh woe is me !

I do try to check logs and search internet you know :-) I dont just jump on here straight from the off. :-)

My 'moan' out of the way...

"...Anyway running a kernel that has known security issues just for that is not a wise choice in my opinion. ..."

That makes sense, of course. It might help having it though, for comparison.

What would you suggest I might look for in finer detail in 'dmesg' (or other logs) that could give a clue to this 'problem' ?

As I have a working kernel as such with regard to this issue, what would you suggest to look for in a comparison/difference check ?

Thanks for your input - it is appreciated.
 
Old 06-28-2019, 02:17 AM   #4
badbetty
Member
 
Registered: Jan 2014
Posts: 130

Original Poster
Rep: Reputation: Disabled
Brief update - I am still ploughing through logs etc trying to understand why the kernel update has seemingly created this problem. I have not spotted anything yet. Will keep reading the help and other reports on the internet.

Whilst I am doing that, on another machine I have noted the previously working USB bluetooth adapter does not work; oddly when sending files to it. Switch back to previous kernel before update and all is ok. Nothing else but kernel changed as far as I am concerned/aware.

Just musing here: running older kernels may be risky as @didier pointed out with "...Anyway running a kernel that has known security issues just for that is not a wise choice in my opinion.". However, as time moves on, it may be that newer kernels etc create issues for older machines and where fixes are hard to come by let's just say (or if one is not a uber-techie able to dig in deep and fix), then that may be the only way to keep a functioning machine with accepted risk - or time to upgrade...which might be a shame !

Last edited by badbetty; 06-28-2019 at 02:19 AM.
 
Old 06-28-2019, 03:44 AM   #5
Labinnah
Member
 
Registered: May 2014
Location: Łódź, Poland
Distribution: Slackware-current
Posts: 79

Rep: Reputation: 37
Quote:
Originally Posted by badbetty View Post
I'm left wondering what changed - or how I could track it down [gulp] please ?
You will not like solution. It requires lots of time and compiling.

In short you need whole git kernel source repository and use git "bisect" tool. You mark 4.4.157 as good 4.4.182 as bad, "bisect" selects something in between - you compile it, test it, and mark is good or bad. Repeat this until found single git commit causing problem.

Example more detailed description: https://www.kernel.org/doc/html/late...ug-bisect.html , however you can find more of them in the net.
 
2 members found this post helpful.
Old 06-28-2019, 04:02 AM   #6
badbetty
Member
 
Registered: Jan 2014
Posts: 130

Original Poster
Rep: Reputation: Disabled
@labinnah "...You will not like solution. It requires lots of time and compiling. ..."

you are right - I don't :-) ! Thank you, I will have a look at that. I am hoping it (the screen blank issue) is just a setting/switch somewhere that can be easily worked.

the boot text displays and scroll initially and then after some point (I haven't captured it yet), it goes blank and stays that way. Pressing the Fn + 'screen on/off' key does seem to restore the display - so as accepted originally, its not unusable...just annoying and frustrating given it all worked fine. I wonder if its a screen resolution switching during boot somewhere or a default module setting kicking in.
 
Old 06-28-2019, 04:24 AM   #7
Labinnah
Member
 
Registered: May 2014
Location: Łódź, Poland
Distribution: Slackware-current
Posts: 79

Rep: Reputation: 37
Quote:
Originally Posted by badbetty View Post
I wonder if its a screen resolution switching during boot somewhere or a default module setting kicking in.
Probably they are. A the beginning kernel use VGA/VESA driver but in some point it switch to native one. It is often noticeable, but in most cases doesn't cause trouble.


However bisecting ins't in real so scary as it looks at the beginning. And in case you hit real bug in kernel, developers almost for sure ask you to bisect problem, so maybe it's worth do test run in this case .
 
Old 06-28-2019, 08:34 AM   #8
badbetty
Member
 
Registered: Jan 2014
Posts: 130

Original Poster
Rep: Reputation: Disabled
perhaps i should add that I am not on my own, though no solution or comfort, in that other folk (with other distros too) appear to be having or have similar screen (and bluetooth) issues from kernel upgrades, where previous kernel worked. I have seen bug reports (only in passing so no quotes/links) relating to bluez where responses have identified kernel changes as the issue (not that the kernel changes are not for the 'right' reasons of course - I wouldn't know yet!). There are similar previous reports regarding blanking screens too. It does appear that kernel changes are a cause and it is whether it is 'wrong' from the kernel change, or 'wrong' in that the application drivers etc are now not up to compatibility standards, that may drive where the fix should be sought. Whatever the rationale, it leaves end-users with some [minor to major depending on point of view] headaches... and that's shame as not all end users are 'expert' techies...especially if thinking of increased take-up of gnu-linux platforms over others. Again, just musing... :-)
 
Old 06-28-2019, 09:37 PM   #9
baumei
LQ Newbie
 
Registered: Feb 2019
Location: USA; North Carolina
Distribution: Slackware!
Posts: 29

Rep: Reputation: 14
Hi "badbetty", the trouble you describe with your ASUS 1225b sounds rather similar to the trouble I had with my ASUS Eee PC 1005HA. My little computer had Slackware 14.2, and it ran nicely with kernel 4.4.157, but with 4.4.172 there was a problem with the display: very shortly after the 'kernel mode switch' occurred, the screen would go blank. (Other than a blank screen the computer ran fine, and I was able to login by using SSH across the network.) (My little computer is 32 bit; I gather yours is 64 bit.)

I tried quite a few things to get the display to work properly with 4.4.172. None worked. However, I did get the idea that the problem was in some way related to ACPI.

Before long I hit upon the idea to try a newer kernel. I downloaded the DUSK 4.4.175 kernel package set (which at the time was the latest in the 4.4.y series), installed it, and found the same problem. Next, I searched for any Slackware kernel package set in the 4.9.y series, or in the 4.14.y series --- I found none.

So, on a lark, I downloaded the 4.19.26 kernel package set out of Slackware-current (which at the time was the most recent in Slackware-current), installed it into 14.2, and rebooted. I was a bit surprised that the little computer even booted, and was pleased to see the screen worked. After exercising the machine a bit, I was even more surprised to find that 14.2 had no apparent difficulty of any kind with the much newer kernel!

It was back in 2019/March that I installed the 4.19.26 kernel. Since then, I have been using the computer every day and the computer works quite well. In addition, I have found that the <Fn> key combinations work better with 4.19.26 than they did with 4.4.157.
 
1 members found this post helpful.
Old 06-29-2019, 02:17 AM   #10
badbetty
Member
 
Registered: Jan 2014
Posts: 130

Original Poster
Rep: Reputation: Disabled
@baumei - many thanks for your input and that is hopeful to know - I will try a newer kernel as you suggest and see what happens (keeping the current ones available of course just in case) for this Asus I have.
 
Old 06-29-2019, 11:40 AM   #11
dr.s
Member
 
Registered: Feb 2010
Distribution: Slackware64-14.2
Posts: 218

Rep: Reputation: 58
Quote:
Originally Posted by badbetty View Post
...Whilst I am doing that, on another machine I have noted the previously working USB bluetooth adapter does not work; oddly when sending files to it. Switch back to previous kernel before update and all is ok. Nothing else but kernel changed as far as I am concerned/aware.

Just musing here: running older kernels may be risky as @didier pointed out with "...Anyway running a kernel that has known security issues just for that is not a wise choice in my opinion.". However, as time moves on, it may be that newer kernels etc create issues for older machines and where fixes are hard to come by let's just say (or if one is not a uber-techie able to dig in deep and fix), then that may be the only way to keep a functioning machine with accepted risk - or time to upgrade...which might be a shame !
A newer kernel is more likely to fix issues, at least in my experience. I've had a few machines (mainly laptops) with boot, graphics or hardware issues that got fixed simply by rebooting with the latest kernels, and had no issues recently running Slackware14.2 with 4.19.x and 5.x kernels. An early 5.0 kernel seemed to introduce a bug with a laptop's volume or brightness key (F key) but that was it iirc.
 
Old 07-01-2019, 05:17 AM   #12
badbetty
Member
 
Registered: Jan 2014
Posts: 130

Original Poster
Rep: Reputation: Disabled
ahhh well...i tried 4.19.56 and it did not fix my recent experiences. I suspect it is some other setting during the boot sequence that I will need to track down (or get into bisecting [gulp] as suggested above when I get chance).
 
Old 07-01-2019, 03:54 PM   #13
enorbet
Senior Member
 
Registered: Jun 2003
Location: Virginia
Distribution: Slackware = Main OpSys for decades while testing others to keep up
Posts: 2,262

Rep: Reputation: 2283Reputation: 2283Reputation: 2283Reputation: 2283Reputation: 2283Reputation: 2283Reputation: 2283Reputation: 2283Reputation: 2283Reputation: 2283Reputation: 2283
It may be a "worth a shot" workaround to disable modesetting in your bootloader. I often see problems where a monitor and video card do not find matching resolutions and either exceed the screen size or go blank. It is a pita but disabling modesetting and sometimes disabling "EdidDpi" in xorg.conf for X fixes it.
 
Old 07-02-2019, 06:24 AM   #14
badbetty
Member
 
Registered: Jan 2014
Posts: 130

Original Poster
Rep: Reputation: Disabled
@enorbet - i will check it out, thank you. Caused by a kernel update from what was working previously...pita..yes indeed :-) !
 
Old 07-02-2019, 07:42 AM   #15
enorbet
Senior Member
 
Registered: Jun 2003
Location: Virginia
Distribution: Slackware = Main OpSys for decades while testing others to keep up
Posts: 2,262

Rep: Reputation: 2283Reputation: 2283Reputation: 2283Reputation: 2283Reputation: 2283Reputation: 2283Reputation: 2283Reputation: 2283Reputation: 2283Reputation: 2283Reputation: 2283
Quote:
Originally Posted by badbetty View Post
@enorbet - i will check it out, thank you. Caused by a kernel update from what was working previously...pita..yes indeed :-) !
One of the user friendly features in Slackware LILO is all the information and commented out options for /etc/lilo.conf. Just setting "vga = normal" can work wonders, assuming you use LILO. There are similar features in grub but I don't recall them offhand since I avoid grub whenever I can. If you use grub a simple web search for "grub2 vga settings" should provide you with syntax.
 
  


Reply


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] "DEBUG kernel" notice from dmesg output on Slackware64 14.2 with kernel 4.4.157 ekinakoglu Slackware 5 10-17-2018 01:31 AM
RHEL 6.8 & D-Link DWM-157 3g USB modem MaxW Linux - Networking 1 01-06-2017 12:46 PM
LXer: Softpedia Linux Weekly, Issue 157 LXer Syndicated Linux News 0 07-24-2011 02:40 PM
LXer: Downgrade udev 157->151 on opensuse 11.3 to bring back to life Xen 4.0 (2.6.34-12-xen) LXer Syndicated Linux News 0 07-26-2010 08:50 PM

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

All times are GMT -5. The time now is 11:48 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