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 03-03-2019, 04:58 AM   #16
igadoter
Senior Member
 
Registered: Sep 2006
Location: wroclaw, poland
Distribution: many, primary Slackware
Posts: 1,237
Blog Entries: 1

Rep: Reputation: Disabled

Here I gathered all information related to the subject
Code:
# lspci
00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and 945GT Express Memory Controller Hub (rev 03)
00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03)
00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03)
Code:
bash-4.3# ls -l /sys/class/drm/
total 0
lrwxrwxrwx 1 root root    0 Mar  3 10:55 card0 -> ../../devices/pci0000:00/0000:00:02.0/drm/card0
lrwxrwxrwx 1 root root    0 Mar  3 10:55 card0-LVDS-1 -> ../../devices/pci0000:00/0000:00:02.0/drm/card0/card0-LVDS-1
lrwxrwxrwx 1 root root    0 Mar  3 10:55 card0-SVIDEO-1 -> ../../devices/pci0000:00/0000:00:02.0/drm/card0/card0-SVIDEO-1
lrwxrwxrwx 1 root root    0 Mar  3 10:55 card0-VGA-1 -> ../../devices/pci0000:00/0000:00:02.0/drm/card0/card0-VGA-1
lrwxrwxrwx 1 root root    0 Mar  3 10:55 controlD64 -> ../../devices/pci0000:00/0000:00:02.0/drm/controlD64
lrwxrwxrwx 1 root root    0 Mar  3 10:55 renderD128 -> ../../devices/pci0000:00/0000:00:02.0/drm/renderD128
-r--r--r-- 1 root root 4096 Mar  3 11:06 version
Code:
bash-4.3# cat  /sys/class/drm/card0-LVDS-1/enabled 
enabled
bash-4.3# cat  /sys/class/drm/card0-VGA-1/enabled 
disabled
Code:
bash-4.3# cat  /sys/class/drm/card0-LVDS-1/dpms
On
bash-4.3# cat  /sys/class/drm/card0-VGA-1/dpms
Off
I have look at display controller
Code:
# cat /sys/class/drm/../../devices/pci0000:00/0000:00:02.1/power/control
on
also
Code:
bash-4.3# dmesg | grep 0000:00:02
[    0.323736] pci 0000:00:02.0: [8086:27a2] type 00 class 0x030000
[    0.323759] pci 0000:00:02.0: reg 0x10: [mem 0xf4400000-0xf447ffff]
[    0.323768] pci 0000:00:02.0: reg 0x14: [io  0x4000-0x4007]
[    0.323778] pci 0000:00:02.0: reg 0x18: [mem 0xe0000000-0xefffffff pref]
[    0.323787] pci 0000:00:02.0: reg 0x1c: [mem 0xf4480000-0xf44bffff]
[    0.323951] pci 0000:00:02.1: [8086:27a6] type 00 class 0x038000
[    0.324012] pci 0000:00:02.1: reg 0x10: [mem 0xf4500000-0xf457ffff]
[    0.339083] vgaarb: setting as boot device: PCI:0000:00:02.0
[    0.339113] vgaarb: device added: PCI:0000:00:02.0,decodes=io+mem,owns=io+mem,locks=none
[    0.339362] vgaarb: bridge control possible 0000:00:02.0
[    0.413544] pci 0000:00:02.0: Video device with shadowed ROM
[    8.616900] vgaarb: device changed decodes: PCI:0000:00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
[    8.897041] [drm] Initialized i915 1.6.0 20151010 for 0000:00:02.0 on minor 0
[    9.851126] i915 0000:00:02.0: fb0: inteldrmfb frame buffer device
 
Old 03-03-2019, 10:12 AM   #17
baumei
LQ Newbie
 
Registered: Feb 2019
Location: USA; North Carolina
Distribution: Slackware!
Posts: 20

Original Poster
Rep: Reputation: 9
Thank you "idagoter". Here is the similar output from my ASUS Eee PC.
Code:
[email protected]:~# lspci
00:00.0 Host bridge: Intel Corporation Mobile 945GSE Express Memory Controller Hub (rev 03)
00:02.0 VGA compatible controller: Intel Corporation Mobile 945GSE Express Integrated Graphics Controller (rev 03)
00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03)
I notice the above three lines for my computer are quite similar to yours, but not identical.

Code:
[email protected]:~# ls -l /sys/class/drm/
total 0
lrwxrwxrwx 1 root root    0 Mar  3 01:08 card0 -> ../../devices/pci0000:00/0000:00:02.0/drm/card0/
lrwxrwxrwx 1 root root    0 Mar  3 01:08 card0-LVDS-1 -> ../../devices/pci0000:00/0000:00:02.0/drm/card0/card0-LVDS-1/
lrwxrwxrwx 1 root root    0 Mar  3 01:08 card0-VGA-1 -> ../../devices/pci0000:00/0000:00:02.0/drm/card0/card0-VGA-1/
lrwxrwxrwx 1 root root    0 Mar  3 01:08 controlD64 -> ../../devices/pci0000:00/0000:00:02.0/drm/controlD64/
lrwxrwxrwx 1 root root    0 Mar  3 01:08 renderD128 -> ../../devices/pci0000:00/0000:00:02.0/drm/renderD128/
-r--r--r-- 1 root root 4096 Mar  3 01:08 version
The only difference I notice between yours and mine is: yours has an Svideo output, and mine does not.

Code:
[email protected]:~# cat /sys/class/drm/card0-LVDS-1/enabled 
enabled
[email protected]:~# cat /sys/class/drm/card0-VGA-1/enabled 
disabled
Matches

Code:
[email protected]:~# cat /sys/class/drm/card0-LVDS-1/dpms 
On
[email protected]:~# cat /sys/class/drm/card0-VGA-1/dpms 
Off
Matches

Code:
[email protected]:~# cat /sys/class/drm/../../devices/pci0000\:00/0000\:00\:02.1/power/control 
on
Matches

Code:
[email protected]:~# dmesg | grep 0000:00:02
[    0.279641] pci 0000:00:02.0: [8086:27ae] type 00 class 0x030000
[    0.279668] pci 0000:00:02.0: reg 0x10: [mem 0xf7e00000-0xf7e7ffff]
[    0.279680] pci 0000:00:02.0: reg 0x14: [io  0xdc00-0xdc07]
[    0.279692] pci 0000:00:02.0: reg 0x18: [mem 0xd0000000-0xdfffffff pref]
[    0.279704] pci 0000:00:02.0: reg 0x1c: [mem 0xf7dc0000-0xf7dfffff]
[    0.279989] pci 0000:00:02.1: [8086:27a6] type 00 class 0x038000
[    0.280023] pci 0000:00:02.1: reg 0x10: [mem 0xf7e80000-0xf7efffff]
[    0.301231] vgaarb: setting as boot device: PCI:0000:00:02.0
[    0.301231] vgaarb: device added: PCI:0000:00:02.0,decodes=io+mem,owns=io+mem,locks=none
[    0.301454] vgaarb: bridge control possible 0000:00:02.0
[    0.372972] pci 0000:00:02.0: Video device with shadowed ROM
[   11.033441] vgaarb: device changed decodes: PCI:0000:00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
[   11.105783] [drm] Initialized i915 1.6.0 20151010 for 0000:00:02.0 on minor 0
[   12.056549] i915 0000:00:02.0: fb0: inteldrmfb frame buffer device
I notice the above lines for my computer are quite similar to yours, differing mainly in the memory locations.

In the Slackware x86 ChangeLogs, I see:
Code:
Wed Jan 30 23:29:59 UTC 2019
patches/packages/linux-4.4.172/*: Upgraded.
       These updates fix various bugs and many (mostly minor) security issues.
Well, Mr. Volkerding does not say this upgrade fixes any severe bugs, so I suppose I could revert to the previous kernel, but that goes against the grain.

I see DUSK has 4.4.175-smp available. I am tempted to try it, in order to see whether the problem has already been fixed.

Any suggestions for how to proceed? Anyone?
 
Old 03-03-2019, 03:12 PM   #18
baumei
LQ Newbie
 
Registered: Feb 2019
Location: USA; North Carolina
Distribution: Slackware!
Posts: 20

Original Poster
Rep: Reputation: 9
So, I downloaded the DUSK kernel-set of 4.4.175-smp, and installed it. Then, ran mkinitrd and lilo, and halted the computer.

I started the computer. The display came on, and showed the normal stuff, until the kernel-mode-switch, after which the screen blanked. The computer continued booting.

Used SSH to login, and to look at things --> same as I reported above.

Whatever is the problem, it is not related only to kernel 4.4.172-smp.

Does anyone have information regarding the compatibility of 32bit Slackware 14.2 with the newer kernel series, such as 4.9.y or 4.14.y?
 
Old 03-03-2019, 10:01 PM   #19
baumei
LQ Newbie
 
Registered: Feb 2019
Location: USA; North Carolina
Distribution: Slackware!
Posts: 20

Original Poster
Rep: Reputation: 9
Well, I found a work-around for my problem.

After I tried DUSK's 4.4.175-smp kernel set, and found it had the same problem as the 4.4.172-smp kernel set, I thought to try a somewhat newer kernel to see: a) would 14.2 boot with it, and b) was the display problem fixed.

So, I looked at "https://www.kernel.org/" to see what the choices might be. I found several kernel series: 4.9.y, 4.14.y, 4.19.y, 4.20.y, and 5.0-rc8. I did a lot of reading, and decided a kernel in the 4.9.y or 4.14.y series might be not so foreign as to be incompatible with Slackware 14.2. I began looking around for a Slackware package of any kernel in either of these two series --- and found not even one package set!

On a wild guess I went to one of the Slackware mirrors: downloaded the 4.19.26 kernel set out of Slackware-current, installed it, ran mkinitrd, ran lilo, and shutdown. Turned the computer back on ---> lo and behold, the system will boot with the new kernel, and the display works!

So far, the little computer seems to be running well. I wonder if I will find things which do not work properly?

I have read where some people are guessing Slackware v15.0 may be getting 'close'. If this is the case, then perhaps Slackware-current is in 'release candidate' stage, as opposed to being on the bleeding edge --- and perhaps it would be reasonable for use in 'production' (not a testing computer).
 
Old 03-04-2019, 04:22 AM   #20
igadoter
Senior Member
 
Registered: Sep 2006
Location: wroclaw, poland
Distribution: many, primary Slackware
Posts: 1,237
Blog Entries: 1

Rep: Reputation: Disabled
I would keep 4.4.x - its EOL is 2022. There is new 4.4.176 version. I hope it will be soon in updates.
 
Old 03-04-2019, 07:54 AM   #21
allend
LQ 5k Club
 
Registered: Oct 2003
Location: Melbourne
Distribution: Slackware-current
Posts: 5,160

Rep: Reputation: 1833Reputation: 1833Reputation: 1833Reputation: 1833Reputation: 1833Reputation: 1833Reputation: 1833Reputation: 1833Reputation: 1833Reputation: 1833Reputation: 1833
Quote:
So far, the little computer seems to be running well. I wonder if I will find things which do not work properly?
I would be interested to know if you can get your computer to successfully resume from suspend to disk. This stopped working for me a while back. Suspend to RAM has always worked.
Quote:
I have read where some people are guessing Slackware v15.0 may be getting 'close'. If this is the case, then perhaps Slackware-current is in 'release candidate' stage, as opposed to being on the bleeding edge --- and perhaps it would be reasonable for use in 'production' (not a testing computer).
People have been guessing that for about two years. Don't hold your breath.
If you want to run -current, I suggest a second install on another partition with a multi-boot setup. That way, if you have a task you need to get done, you can boot to a working setup. Be warned, tracking -current on this low end hardware is time consuming. Also, if you use third party software, changes in -current may require that the software be recompiled.
 
1 members found this post helpful.
Old 03-04-2019, 10:30 AM   #22
baumei
LQ Newbie
 
Registered: Feb 2019
Location: USA; North Carolina
Distribution: Slackware!
Posts: 20

Original Poster
Rep: Reputation: 9
Hi 'allend', I went to your thread, and read of your experience with hibernation running kernel 4.14.62 on your computer.

So, I tested suspend-to-RAM and suspend-to-disk (hibernate) on my computer running kernel 4.19.26-smp in Slackware 14.2 (32bit). As with yours: suspend-to-RAM works, and suspend-to-disk fails. The resuming from suspend-to-disk seemed to work properly, until it put on the display something about 'no available console' --- followed by a full reboot. (I looked in "/var/log/messages" so that I could read the messages, but it appears none of the messages from the resume-attempt made it into the log; I see entries from the previous run, and the subsequent run.)
 
1 members found this post helpful.
Old 03-04-2019, 04:03 PM   #23
allend
LQ 5k Club
 
Registered: Oct 2003
Location: Melbourne
Distribution: Slackware-current
Posts: 5,160

Rep: Reputation: 1833Reputation: 1833Reputation: 1833Reputation: 1833Reputation: 1833Reputation: 1833Reputation: 1833Reputation: 1833Reputation: 1833Reputation: 1833Reputation: 1833
Thanks for the report. The message following the restoration of the image appears to arise from this section of printk.c
Code:
/**
 * suspend_console - suspend the console subsystem
 *
 * This disables printk() while we go into suspend states
 */
void suspend_console(void)
{
        if (!console_suspend_enabled)
                return;
        pr_info("Suspending console(s) (use no_console_suspend to debug)\n");
        console_lock();
        console_suspended = 1;
        up_console_sem();
}
But why go into a suspend state on resume? I suspect the issue is with the i915 kernel driver.

Last edited by allend; 03-04-2019 at 04:05 PM.
 
Old 03-04-2019, 04:37 PM   #24
baumei
LQ Newbie
 
Registered: Feb 2019
Location: USA; North Carolina
Distribution: Slackware!
Posts: 20

Original Poster
Rep: Reputation: 9
Hi "allend", late this afternoon I did a little looking about the hibernation problem. I came across where a fellow had written the problem is because of a conflict between the 32-bit kernel and kASLR [1]. To stop the conflict, he said to send the kernel the boot option "nokaslr". I tested this on my Eee PC, and now it can resume from hibernation. :-)

If you try the "nokaslr" boot option on your computer, I would be pleased to hear how it does.

1. "https://en.wikipedia.org/wiki/Address_space_layout_randomization"

Last edited by baumei; 03-05-2019 at 12:38 AM.
 
1 members found this post helpful.
Old 03-05-2019, 12:47 AM   #25
allend
LQ 5k Club
 
Registered: Oct 2003
Location: Melbourne
Distribution: Slackware-current
Posts: 5,160

Rep: Reputation: 1833Reputation: 1833Reputation: 1833Reputation: 1833Reputation: 1833Reputation: 1833Reputation: 1833Reputation: 1833Reputation: 1833Reputation: 1833Reputation: 1833
Yay - It also works for me. Much thanks!!
 
Old 03-18-2019, 08:22 PM   #26
shelldweller
LQ Newbie
 
Registered: Mar 2019
Location: Albuquerque, NM, USA
Distribution: Freenix & Slarm64
Posts: 4

Rep: Reputation: Disabled
Same issue on Asus EEE PC 1025C

Wow, I am glad I found this thread. I ran into the same issue on an Asus EEE PC 1025C. I compiled a few different kernels myself to see what was going on. Things were just fine up until 4.4.171, which I am still currently running. The problems start with 4.4.172.

I have this computer hooked up to an external VGA monitor about 90% of the time, and I boot it that way, so I actually ran kernel 4.4.172 for about a week before I noticed the issue. Then I took the laptop to work with me and I got the black screen after the kernel switch during boot. External VGA worked fine there at work also, but that kinda defeated the purpose.

A bit of digging around, I found this in the changelog for 4.4.172:

Code:
commit 0c4a25cc6f2934f3aa99a0bbfd20b71949bcad25
Author: Joćo Paulo Rechi Vita <[email protected]>
Date:   Wed Oct 31 17:21:26 2018 -0700

    platform/x86: asus-wmi: Tell the EC the OS will handle the display off hotkey
    
    [ Upstream commit 78f3ac76d9e5219589718b9e4733bee21627b3f5 ]
    
    In the past, Asus firmwares would change the panel backlight directly
    through the EC when the display off hotkey (Fn+F7) was pressed, and
    only notify the OS of such change, with 0x33 when the LCD was ON and
    0x34 when the LCD was OFF. These are currently mapped to
    KEY_DISPLAYTOGGLE and KEY_DISPLAY_OFF, respectively.
    
    Most recently the EC on Asus most machines lost ability to toggle the
    LCD backlight directly, but unless the OS informs the firmware it is
    going to handle the display toggle hotkey events, the firmware still
    tries change the brightness through the EC, to no effect. The end result
    is a long list (at Endless we counted 11) of Asus laptop models where
    the display toggle hotkey does not perform any action. Our firmware
    engineers contacts at Asus were surprised that there were still machines
    out there with the old behavior.
    
    Calling WMNB(ASUS_WMI_DEVID_BACKLIGHT==0x00050011, 2) on the _WDG device
    tells the firmware that it should let the OS handle the display toggle
    event, in which case it will simply notify the OS of a key press with
    0x35, as shown by the DSDT excerpts bellow.
    
     Scope (_SB)
     {
         (...)
    
         Device (ATKD)
         {
             (...)
    
             Name (_WDG, Buffer (0x28)
             {
                 /* 0000 */  0xD0, 0x5E, 0x84, 0x97, 0x6D, 0x4E, 0xDE, 0x11,
                 /* 0008 */  0x8A, 0x39, 0x08, 0x00, 0x20, 0x0C, 0x9A, 0x66,
                 /* 0010 */  0x4E, 0x42, 0x01, 0x02, 0x35, 0xBB, 0x3C, 0x0B,
                 /* 0018 */  0xC2, 0xE3, 0xED, 0x45, 0x91, 0xC2, 0x4C, 0x5A,
                 /* 0020 */  0x6D, 0x19, 0x5D, 0x1C, 0xFF, 0x00, 0x01, 0x08
             })
             Method (WMNB, 3, Serialized)
             {
                 CreateDWordField (Arg2, Zero, IIA0)
                 CreateDWordField (Arg2, 0x04, IIA1)
                 Local0 = (Arg1 & 0xFFFFFFFF)
    
                 (...)
    
                 If ((Local0 == 0x53564544))
                 {
                     (...)
    
                     If ((IIA0 == 0x00050011))
                     {
                         If ((IIA1 == 0x02))
                         {
                             ^^PCI0.SBRG.EC0.SPIN (0x72, One)
                             ^^PCI0.SBRG.EC0.BLCT = One
                         }
    
                         Return (One)
                     }
                 }
                 (...)
             }
             (...)
         }
         (...)
     }
     (...)
    
     Scope (_SB.PCI0.SBRG.EC0)
     {
         (...)
    
         Name (BLCT, Zero)
    
         (...)
    
         Method (_Q10, 0, NotSerialized)  // _Qxx: EC Query
         {
             If ((BLCT == Zero))
             {
                 Local0 = One
                 Local0 = RPIN (0x72)
                 Local0 ^= One
                 SPIN (0x72, Local0)
                 If (ATKP)
                 {
                     Local0 = (0x34 - Local0)
                     ^^^^ATKD.IANE (Local0)
                 }
             }
             ElseIf ((BLCT == One))
             {
                 If (ATKP)
                 {
                     ^^^^ATKD.IANE (0x35)
                 }
             }
         }
         (...)
     }
    
    Signed-off-by: Joćo Paulo Rechi Vita <[email protected]>
    Signed-off-by: Andy Shevchenko <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>
I haven't had time to investigate further. I would bet a dozen donuts that this commit is what caused the issue.

Interesting side note:

The external VGA monitor behavior also changed beteen 4.4.157 and 4.4.171. It used to be that when I booted with the VGA attached, the LCD monitor would be disabled on boot by default, and the only way to get it back would be to reboot without the cord attached. Seemed like a bug, but one that never really bothered me.

Now, with kernel 4.4.171, booting with the VGA attached results in a dual-screen situation, with the netbook's LCD screen permanently black but "active", with my desktop extended. So I have to manually de-activate it using randr to go back to only having the one external VGA display, which used to be the default.

I'm not exactly sure at what point that behvoir changed. I only tested a few kernels between 4.4.157 and 4.4.172 before I got curious enough to try 4.4.171.

Anyway, I wonder how much longer this Asus firmware will be supported. Someone got a 4.9.26 kernel working, did I read that right? I might just try a kernel from -current. I think I tried the latest 4.9.x and 4.14.x from kernel.org. I can't recall the results, I should try those again. If I recall correctly, the same issue was there, otherwise I probably would just be running one of those instead of 4.4.171.

Maybe in the next week or two I can try some fresh kernel sources, or just keep my eye on the changelogs.
 
2 members found this post helpful.
Old 03-19-2019, 05:11 PM   #27
baumei
LQ Newbie
 
Registered: Feb 2019
Location: USA; North Carolina
Distribution: Slackware!
Posts: 20

Original Poster
Rep: Reputation: 9
Yes, I found that the 32bit 4.19.26 kernel works with Slackware 14.2 32bit --- I did not have to make any changes to either. I got the set of 32bit 4.19.26 kernel related packages from Slackware-current, did an upgrade, ran mkinitrd, ran lilo, and rebooted.

Later, I was informed that to resume from hibernation would probably fail with 4.19.26. Indeed, I found this to be the case. After doing some reading on the Internet, I found it said that the "nokaslr" kernel option would fix this problem. I tried it, and the problem was fixed.
 
  


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
looking for i915 parameter document or Is i915 good for N10? kaz2100 Debian 6 07-10-2011 06:17 PM
Fedora 13 32bit and then Linux Mint 32bit and then Ubuntu 10.04 32bit ciao303 Linux - Newbie 3 08-09-2010 11:03 PM
Feisty + Intel i915 module on 915GEVL motherboard + Xorg = scrambled display devghai Ubuntu 4 08-31-2007 02:10 AM
Feisty + Intel i915 module on 915GEVL motherboard + Xorg = scrambled display devghai Ubuntu 2 08-25-2007 02:08 PM

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

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