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.

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:Anyway running a kernel that has known security issues just for that is not a wise choice in my opinion.

@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.

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 !

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.

@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.

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 :D.

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... :-)

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.

@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.

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.

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).

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.

@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.

Hi "badbetty", does your computer have more than one video port or card? Do you suppose that the new kernel is choosing to put the display output on the port/card to which no monitor is attached?

Does your computer have an LCD display? Back when I was investigating the trouble with my ASUS computer I came across mention that for some hardware the backlight 'brightness' control is inverted. (This was not the trouble in my case.)

Latest findings might suggest it is an issue between whatever has changed in the kernel with respect to ACPI.

There are quite a few [old and newer] reports across distros on the internet about this type of issue.

In respect of this I added "acpi=off" in to the append attribute in the lilo.conf and behold, it booted up seemingly fine. Of course, this is not ideal, but it does help narrow down the issue. I will keep pursuing this angle and see how far I get, though not sure just yet where to look next on this kernel/acpi connection.

Something has gone awry between the working kernel and the updated kernel with respec to ACPI it would seem at the moment.

...
acpi=off appears to boot without issue (but not good for anything else in respect of acpi being permanently off once booted)

acpi=noirq issue persists

pci=noacpi kernel panics and wont boot at all.


now then, on to "how do I best 'bisect'" knowing it might be acpi related (just as @baumei hinted at to be fair).

I do wish these kernel-dev folk would check first before making changes - haha (only kidding)

aha... so after many many hours of learning to bisect, I found out that the 'screen blanking' issue seemingly starts to occur somewhere in 4.4.171... and then eventually refined that to:

bad: [0c4a25cc6f2934f3aa99a0bbfd20b71949bcad25] platform/x86: asus-wmi: Tell the EC the OS will handle the display off hotkey

What that means I have no idea or what to do next please ?... but its now clear (I think haha) as all is fine before this version.


Phew it was a laborious effort I tell you :-~

Fill bug report in https://bugzilla.kernel.org/. Tell there about your findings and tell exactly what type of Asus laptop you have. Google search reveals some problem with this commit already (see https://lore.kernel.org/patchwork/patch/1087451/). They just add your laptop type to quirks and problem will be fixed in some future (maybe next) kernel release.

I will follow the link to bugzilla and see what's what there.

Quickly, as this OP was not about it, I will see if I can drum up enough enthusiasm to go through the same process for the bluetooth usb adapter issue I briefly mentioned (lots of reports of bluetooth issues following kernel upgrades too). This particular one, quite specific perhaps, is noticed to be that after the 4.4.157 where everything is fine, bluetooth sending (to the computer with the usb adapter) fails but all other functions are fine...rather odd it is.... just the 'sending to' part.

edit: oh and bluetooth audio sink not working too - forgot.

marking as solved from my perspective as its (poss. bug) going somewhere else now. thank you all.

Hi "badbetty", if you have not tried it yet, I think it would be interesting to see what the following commands do for your display: On my ASUS Eee PC HA1005 running 4.19.26, and on various other computers I have owned which ran Slackware, the above commands reliably turned the display ON or OFF.

Back when I was investigating my problem with kernel 4.4.172smp 32-bit, I used ssh to login to my Eee PC, switched to root, and ran the commands --> and as I recollect the commands did not do anything useful. I gather you are running 4.4.172 64-bit on different hardware; it may be the commands work in your case.

If the vbetool command works on your computer, it may be easily possible to use the command as a line in "/etc/rc.d/rc.local" to turn the display ON during boot-up. Or, perhaps to write a 'stanza' for your ACPI code which toggles between the two states (or some such thing).

@baumei

I will try them. Do they do a similar thing as the Fn + 'screen on/off' key that originally mentioned ?

Hi "badbetty", yes, when 'vbetool dpms' is able to function, its effect which the user can see is similar to the effect of <Fn> + 'screen on/off'. From what I have read, the manner by which vbetool does its work is different from the way the OS does it (I do not personally know).

If I understand correctly, your computer starts the boot process with the display functioning, and then part way through boot-up the display goes off --- and after boot-up your <Fn> + 'screen on/off' functions.

If 'vbetool dpms' is able to function on your machine with 4.4.182, then I would try putting "vbetool dpms on" in your "/etc/rc.d/rc.local" file, and reboot. What I would hope/expect to see from this is: when the boot-up process runs rc.local that the display would turn back ON.

Hi "badbetty",

Back in June you wrote:
I mentioned to LQ member 0XBF that you had found the 64-bit 4.19.56 kernel set had the black screen problem.

OXBF reported finding out from the maintainers of asus-wmi that a fix for the problem was developed, but the fix was not put into any kernel series older than 4.19.x, and that it was introduced into the series starting with the 4.19.58 kernel set. Also, the fix was put into the newer kernel series, beginning with whatever kernel was being published around the time of 4.19.58.
https://www.linuxquestions.org/quest...6/#post6061298

I gather the maintainers are considering backporting the patch to the other kernel series which are still supported.

@baumei

hi, thank you for that update.

Perhaps a case of 'watch this space'.

Much appreciated. Regards
Habs