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.

1 members found this post helpful.

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

2 members found this post helpful.

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

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.

1 members found this post helpful.

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