LinuxQuestions.org
Review your favorite Linux distribution.
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 07-02-2019, 10:54 AM   #16
baumei
LQ Newbie
 
Registered: Feb 2019
Location: USA; North Carolina
Distribution: Slackware!
Posts: 29

Rep: Reputation: 14

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.)
 
Old 07-03-2019, 03:11 AM   #17
badbetty
Member
 
Registered: Jan 2014
Posts: 130

Original Poster
Rep: Reputation: Disabled
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.
 
Old 07-03-2019, 04:20 AM   #18
badbetty
Member
 
Registered: Jan 2014
Posts: 130

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

Last edited by badbetty; 07-03-2019 at 04:21 AM.
 
Old 07-04-2019, 12:11 PM   #19
badbetty
Member
 
Registered: Jan 2014
Posts: 130

Original Poster
Rep: Reputation: Disabled
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 :-~
 
Old 07-04-2019, 02:41 PM   #20
Labinnah
Member
 
Registered: May 2014
Location: Łódź, Poland
Distribution: Slackware-current
Posts: 81

Rep: Reputation: 38
Quote:
Originally Posted by badbetty View Post
What that means I have no idea or what to do next please ?
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.
 
1 members found this post helpful.
Old 07-05-2019, 03:28 AM   #21
badbetty
Member
 
Registered: Jan 2014
Posts: 130

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

Last edited by badbetty; 07-05-2019 at 04:56 AM.
 
Old 07-05-2019, 04:58 AM   #22
badbetty
Member
 
Registered: Jan 2014
Posts: 130

Original Poster
Rep: Reputation: Disabled
marking as solved from my perspective as its (poss. bug) going somewhere else now. thank you all.
 
Old 07-05-2019, 09:26 PM   #23
baumei
LQ Newbie
 
Registered: Feb 2019
Location: USA; North Carolina
Distribution: Slackware!
Posts: 29

Rep: Reputation: 14
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:
Code:
vbetool dpms on
vbetool dpms off
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).
 
Old 07-06-2019, 05:22 AM   #24
badbetty
Member
 
Registered: Jan 2014
Posts: 130

Original Poster
Rep: Reputation: Disabled
@baumei

I will try them. Do they do a similar thing as the Fn + 'screen on/off' key that originally mentioned ?
 
Old 07-06-2019, 08:51 AM   #25
baumei
LQ Newbie
 
Registered: Feb 2019
Location: USA; North Carolina
Distribution: Slackware!
Posts: 29

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


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 12:02 AM.

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