Hi Folks,

I run Slackware 14.2, either 64-bit or 32-bit as appropriate for the hardware. I use the kernel package sets which are released by Mr. Volkerding.

There is a display problem came to be with one of the kernels between 4.4.157 and 4.4.172. According to the investigation by "badbetty", in kernel 4.4.171.

In 2019/Feb I reported finding a computer which worked fine with kernel 4.4.157-smp (32-bit) --- but with kernel 4.4.172-smp (32-bit) the screen would go black when the console switched from 'normal' to 'frame-buffer'. This computer is an ASUS Eee PC 1005HAB. [I did find a work-around, which is to run a 4.19.x kernel.]
https://www.linuxquestions.org/quest...ch-4175649029/

In 2019/Jun "badbetty" reported the same problem, but with the 64-bit kernels in Slackware64 14.2, on an ASUS Eee PC 1225b. She used "bisect": found that for the 64bit kernels the problem came to be in kernel 4.4.171, and is related to something between the kernel and the asus-wmi module. I gather she was going to attempt to report the problem upstream, but I do not know whether she was able to do so. [I suggested my work-around to her, but in her case it did not help.]
https://www.linuxquestions.org/quest...ot-4175656203/

In 2019/Oct "poetgrant" reported the same problem, also on an ASUS Eee PC 1005HAB. [I suggested my work-around, and in this instance it was successful.]
https://www.linuxquestions.org/quest...te-4175663138/

In 2019/Nov I found this problem also exists on an ASUS Eee PC 1025c. The 1025c is about two years newer than the 1005HA, and it has: a different chipset, a different video 'card', and a different BIOS. [I applied my work-around, and in this instance it also worked.]

My work-around is to replace the 4.4.x-smp kernel with the 4.19.x-smp kernel. For the 32-bit 4.19.x-smp kernels which I have tried, I have found no display problem. However, "badbetty" found the 64-bit 4.19.56 kernel did not in her instance avoid the display problem.

Does anyone know of other models of computer which exhibit this problem?

----

LQ member "abga" has an Acer Aspire One, the hardware of which is quite similar to the ASUS Eee PC 1005HAB, and the video "works flawless".
https://www.linuxquestions.org/quest...ml#post6052409

And nobody reports a solution to the problem? Full marks on the homework, btw.

You should compare the logs in the earlier & later kernels. You may not be able to use a distro kernel, but may need your own, compiled for your box For instance, on some useless m/b, I had to remove generic PCI and compile in my own. If I had left generic PCI, my own would have never been used.

So far, it appears there is no solution.

Now that I have found the problem which I saw in the 1005HAB also exists with the 1025c, and re-read what "badbetty" reported, I think it highly likely the problem is related to one or more of: the asus-wmi module, the 4.4.x-smp kernel, and the 'embedded controller'.

Today, I downloaded the 32-bit 5.4.0-rc7-smp package set, and installed it into Slackware 14.2 (32-bit) on my 1025c. It boots to the console; no black screen problem.

Not long ago I saw a post by Mr. Volkerding which hinted that the next version Slackware was waiting on the next kernel with long-term support. I gather this 5.4.0 kernel will be the next one with long-term support after Mr. Volkerding's hint.

If the next version of Slackware uses 5.4.0, and 5.4.0 and its modules do not become broken, then I will be able to run the next version of Slackware on all the computers I have in active use. After which, it will be moot whether the 4.4.x kernel series works with asus-wmi and the hardware.

Ok. Slackware-14.2 was released a while ago. It's hardly current.

No half decent pc should be using framebuffer in the 21st century unless your resurrecting the last millennium.

I would expect that if you had the kernel module, no sort.conf settings, no framebuffer/Vesa etc. but do have the the X driver, things should work. It should crank up the max resolution possible Anne probably a good refresh rate.

Take one of your pcs, that you can transfer the fixes from. Let's discuss that. We solve technical problems based on technical input from you. Let's get to that. Error snippets from/var/log/Xorg 0.log, kernel module, X driver.

Hi "business kid",

As I understand things, the i915 module is appropriate for the GMA950 video 'card', and that the i915 module is part of what provides a frame-buffer to the system.
Do you think my understanding is not correct about i915 and frame-buffer?

For the particular laptop from which the snippets above are taken, it will be good enough if the console works well at 128x37, and X never functions. Of course, it would be nice if X functions, but X is not necessary.

The problem about which I was writing is that when the 4.4.172-smp (or higher) kernel switched from 'normal' mode to the "colour frame buffer device 128x37" the screen would go black --- and continue booting. After the booting was complete, I could login using ssh. The logfile had no error messages --> apparently the kernel had no idea the display was off (and I mean 'off', as to opposed to no backlight).

As I have mentioned earlier, I did find a work-around to this problem, which is to instead install kernels from the 4.19.x series.

Apparently, someone figured out what the fix is --> and this fix is incorporated into the 32-bit line of the 4.19.x series. In my opinion, it would be a good idea for this fix to also be incorporated into the 4.4.x series, and into the 64-bit line of the 4.19.x series. I hope neither line in the 5.4.x kernel series has this problem.

According to the investigation by "badbetty" the breakage in the 4.4.x series occurred with kernel 4.4.171, because kernels before this worked fine. As I recollect, several months ago "badbetty" was going to report the issue to someone; I do not know any more about this.

What's this about? 128x37 is the size of a matchbox. Are you using a matchbox sized screen? Framebuffer in technology from the last millennium and I never use it. Load the module, provide the driver, and X will figure out the rest. I don't instatt framebuffer or vesa.- ever. Not for 10 years.

It means that in text mode there are 128 columns and 37 rows of characters.

1 members found this post helpful.

Hi "baumei",

I have an Eee PC 1000H model laptop with very similar specs as the ones you have listed. However, it has been running the latest 4.4.199-smp, and 4.4.201-smp kernels with no problems, as I discussed in poetgrant's post. After reading your new post here I decided to do some further testing and managed to break my system, and fix it, somewhat. I would like to report my findings here. Hopefully it will help us figure out the core issue to this problem.

State of Eee 1000H, running stock 14.2, kernel 4.4.201-smp, prior to breakage:
BIOS version was running at 1803 (2009/03/09), this will be different on your model, but for the record this is an older version.
You mentioned the asus-wmi module loaded. In this older BIOS setup, asus-wmi is not loaded, and eeepc_laptop has taken it's place. From what I gather online, the eeepc_laptop was an older module that was superseded by asus-wmi. I guess since I had the older bios, the kernel loaded the older module. I assumed that this would change if I did a bios upgrade, so I downloaded and flashed the bios with the "latest" update.

State of Eee 1000H, running stock 14.2, kernel 4.4.201-smp, now broken:
BIOS version is updated to 2204 (2009/10/26), the latest update available to my model. After booting and initrd loading, the modeset occurs, screen is resized, and then shortly after goes black, as you have experienced, with no way to switch out. SSH works fine from another computer. I tried issuing a reboot and the screen stayed black throughout the entire process, back to where I could ssh back in again. A shutdown -hP to off and restarting does allow the screen to come back on at power on, only to shut off at the same point in boot. From my ssh session I also see that asus-wmi is loaded, eeepc_laptop is not. Also there is eeepc_wmi as well when not working.

After messing around with the broken laptop for a while I found two methods to get the system to boot without the screen shutting off.

Appending acpi_backlight=vendor to the kernel command line gets the boot through and the console is workable. However pressing any brightness keys instantly hung the system so I scrapped that.

Appending acpi_osi=Linux also gets the boot through and the brightness hotkeys are functional. lsmod also reports both asus-wmi, and eeepc_laptop loaded. Everything is working so far, but I do get the following error in dmesg:
Also here's some diffs from lsmod:

Old BIOS:
New BIOS, blank screen:
New BIOS, working with acpi_osi=Linux
So the old bios worked with just eeepc_laptop. The screen stops working with asus_wmi and eeepc_wmi, and it works again with asus_wmi and eeepc_laptop. Note that eeepc_wmi doesn't load in the "fixed" system.

I am not too experienced with the differences between these modules so I have further reading to do. Perhaps in the meantime this information may be of use to you or someone else who can see the issue here. I have had enough troubleshooting for tonight so I will pick it up another time.

Ps. Sorry for the long read. Just wanted to share my notes

1 members found this post helpful.

Hi OXBF,

Thank you for writing out a description of your experimentation on your ASUS Eee PC 1000H, and the results. I am glad your report is long. :-)

Based on your experimentation and the previous data points, it appears to me the trouble is that one or more of the various BIOS codes published by ASUS are not compatible with one or more of the asus_wmi, eeepc_wmi, and eeepc_laptop modules. I guess the next step is to try communicating with whoever maintains the asus_wmi, eeepc_wmi, and eeepc_laptop modules, and inform them of the troubles the users of these modules are having.

What do you think?

I've been digging through the kernel change logs trying to narrow this down. Based on my comparisons between the 4.4.y branch and 4.19.y branch, the likely culprit is the asus_wmi module, since it is the one that has been modified in the time frame of kernels 4.4.157 and 4.4.172.

There have been patches to the 4.19.y kernel branch that specifically address the problem of Eeepc laptop screens "going black". I tried applying some of the patches from 4.19.y to the code in 4.4.y and rebuilding the driver but I have had no luck yet. There are multiple differences between the versions, other than that particular "fix", so it's slow going trying to narrow it down. I also haven't delved into kernel troubleshooting before so I'm learning about it as I go. I'd like to try a few more things first to narrow down the bug report and suggest a fix. Either way a report for the 4.4 kernel series should be filed. I can get around to that after I'm done attempting to isolate the problem.

I was also wondering if you still have a 4.4 series kernel on your machine. Perhaps you could check if the acpi_osi=Linux workaround works in your case?

1 members found this post helpful.

Well the problem is definitely caused by the asus_wmi driver, specifically this commit to the code from 2019-01-26:

https://git.kernel.org/pub/scm/linux...20b71949bcad25

I removed the patch from the code in /usr/src/linux-4.4.202/drivers/platform/x86/asus-wmi.c and rebuilt the module. The system boots fine on 4.4.202-smp without a problem after that.

I'm still not sure what exactly has fixed the issue in the 4.19 kernel series. I have emailed the code maintainer, outlining the problem we have here. I'll keep this thread updated with anything I hear back from them.

1 members found this post helpful.

Hi OXBF,

Congratulations on finding the commit which caused the problem. :-) Someday, I would like to learn to do what you did.

My understanding is the 64-bit version of 4.19.x also has the blank screen problem; that it is only the 32-bit version of 4.19.x which works.

If the maintainer eventually needs patches tested on guinea pigs, I have two rather different Eee PC laptops

Well it looks like we might not be getting a patch to test out for the problem.

I had initially sent the report to the asus-wmi maintainer list and the response was that "they have little interest in debugging a driver for an old kernel when it's been fixed in the newer branch". They suggested I contact the stable branch maintainer instead and request that the bugged patch be reverted.

I have sent an email to the branch maintainers now with the request and bug details. If they do revert it then we should be able to use the 4.4 kernels again with the EeePC models affected by this.

1 members found this post helpful.

Hi OXBF,

Thank you for writing to the two maintainer-lists. For the 4.4.x series, I agree that it would be an improvement to take out the commit which instigated the problem.

I wonder which kernel-series it is which the asus-wmi group thinks has been fixed? The reason I ask this is because it is my understanding that "badbetty" has a 64-bit ASUS computer, and that she tried kernel-set 4.19.56, and it also has the black screen problem. https://www.linuxquestions.org/quest...3/#post6010786

As far as I know, it is only the 32-bit branches of the newer kernel-sets which do not have the black screen problem. (I have tested several sets in the 4.19.x series, and the 5.4.0-rc7 set.)

I have further updates on the progress of this but I can answer your question first now that I've perused all the different kernel archive lists at kernel.org trying to sort this out.

The general process here is that fixes are put into the current development branch, and then backported to older LTS kernels as the maintainers see fit.

In the case of our problem with the asus driver, the problematic commit to the code first entered on 2018-11-07, and went into the development kernel 4.20-rc2 and newer. This was then backported on 2019-01-26 into the 4.4, 4.9, 4.14, and 4.19 series kernels, so they will all have the bug in them after that date.

The fix to this bug then first showed up on 2019-06-12, which corresponds to kernel 5.2-rc5. This fix was backported only to the 4.19 LTS branch on 2019-07-10 for the 4.19.58 release.

Put it all together and you should find that the kernels without the problem are the currently available 5.x series, and anything 4.19.58 or newer (or anything older than 2019-01-26, but you should use newer kernels for security reasons). Therefore I think its not so much 32bit vs 64bit, as it is the changelog dates that explain the problem. Badbetty trying 4.19.56 would still have the bugged commit, with it being fixed shortly after on 4.19.58. The users with EeePC's are 32 bit, but its the fact they were using 14.2 which follows 4.4 bugged kernel that this came up.

I have had a little bit of dialog with the maintainers now so they are aware of the problem. It seems that the fix was only backported to 4.19 because the asus driver code is quite different going further back to older kernels, meaning the fix has to be tweaked to match each one a little differently. I have tested a patch that one of the guys on the maintainers list offered and it corrects the behavior for the 4.4 series. He offered to make patches for all the affected kernels so now we are just waiting on Greg Kroah-Hartman to approve or kibosh the proposal.

1 members found this post helpful.